At 10:39 12/27/94, Michael Ferioli - D&D Consulting wrote:
>I have some questions about how one might go about doing mail routing
>on a network which has a single point of contact with the Internet.
>Let's say we have a company:
>
>1) Top level domain: acme.com
>2) The internet gateway (firewall) is called (among other names)
>mailhost.acme.com
>3) There are (at least) two subdomains: boston.acme.com and nyc.acme.com
>4) Both Boston and NYC have a single machine which they use as a mailhost:
> mailhost.boston.acme.com and mailhost.nyc.acme.com
>5) Mail desinted for boston should be addressed: user @
boston .
acme .
com
> and likewise for nyc.
>6) Mail should enter the network at mailhost.acme.com, then be forwarded
> to boston and nyc respectively.
>
>Both boston.acme.com and nyc.acme.com must be MX'd to mailhost.acme.com
>(obviously).
>
>Now, here's the questions:
>
>1) How do I implement such a setup?
>
>There are two equally non-eligant ways of doing this that I know of:
>1. Alias ALL of the users in Boston and NYC (very messy!)
>2. Use POP3 to poll the mailhost.acme.com mailboxes from both
> mailhost.boston.acme.com and mailhost.nyc.acme.com (better... but not
>quite)
>
>There MUST be a bette way of doing this! With all the firewalls out there,
>I cannot be the only one who is facing this challenge.
>
>ANY and ALL help would be appreciated. I'm familiar with both Sendmail
>and Smail.
I don't know Smail, but you can do all this with sendmail and DNS.
First step: publish DNS MX records to the world that cause all incoming mail
to come to mailhost.acme.com; i.e., publish something like this:
nyc IN MX 10 mailhost.acme.com.
boston IN MX 10 mailhost.acme.com.
>From there, you've got a couple of options. If you trust your version of
sendmail to handle DNS MX records properly (the latest versions from Berkeley
do, and the versions from Sun generally don't, for instance), you could add
two more records:
nyc IN MX 5 mailhost.nyc.acme.com.
boston IN MX 5 mailhost.boston.acme.com.
These records, in conjunction with the above records, should cause the outside
world to attempt to deliver mail for "nyc.acme.com" to "mailhost.nyc.acme.com";
when that fails (and it will, because mailhost.nyc.acme.com is unreachable
from the outside, right?), the outside world will fall back to
mailhost.acme.com (the higher-numbered MX record). Once the mail gets to
mailhost.acme.com, it does the same tango with the MX records; the key
difference, however, is that mailhost.acme.com _can_ reach
mailhost.nyc.acme.com.
Some folks would say this type of setup is unneighborly, because it causes
anyone who tries to send you mail to waste time and bandwidth first trying
to contact a machine that they're _never_ going to be able to reach, and
then eventually falling back to the machine they can contact.
If you're running a split DNS, and the info for your domain that you're
publishing to the world is not the same as the info you use internally,
and mailhost.acme.com uses the internal info, then you could solve this
problem by publishing the weight 5 records (the second set of records above)
in only the internal data. The outside world would see only the weight 10
records, and would immediately send stuff to mailhost.acme.com, without
first trying to reach the unreachable (to them) mailhost.nyc.acme.com.
Another alternative, using just the first set of records, is to hack your
sendmail.cf to make sendmail on mailhost.acme.com recognize addresses of the
form "* @
nyc .
acme .
com" and "* @
boston .
acme .
com" as "special" and process them
by forwarding them to mailhost.nyc.acme.com and mailhost.boston.acme.com,
respectively. You'd do this in ruleset 0 in the sendmail.cf file. I
personally tend to prefer this approach, because it makes the forwarding
obvious and explicit in the sendmail.cf file, rather than depending on the
vagaries of DNS MX processing; then again, I'm perfectly comfortable hacking
sendmail.cf files to do all sorts of weird crap.
-Brent
--
Brent Chapman | Great Circle Associates | Call or email for info about
Brent @
GreatCircle .
COM | 1057 West Dana Street | upcoming Internet Security
+1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates
|
|
