First, thanks to:
Keith.McCabe_at_ranplc.co.uk
jacy_at_fluid.mro.dec.com
My original posting was:
|>Greetings -
|>
|>In the near future the subdomain I (and other OSF/1 machines) are currently
|>in becomes obsolete (reorganization), and I'm currently looking at ways to
|>ease the transition as outlined below:
|>
|>current: icefog.uacn.alaska.edu
|>transition: icefog.alaska.edu
|>future: icefog.???.alaska.edu
|>
|>RE: sendmail
|>It would appear that the DOMAINTABLE macro would do this, but so could the
|>HIDDENHOST, HIDDENNET, and HIDDENDOMAIN macros, plus declaring a class and
|>writing a couple of rules could also accomplish this. Any other ways?
|>Advice anyone?
|>
|>Currently sending mail to icefog.alaska.edu has the following problem:
|> ----- Transcript of session follows -----
|>While talking to icefog.alaska.edu:
|>>>> HELO icefog.uacn.alaska.edu
|><<< 553 Local configuration error, hostname not recognized as local
|>554 <haymanr_at_icefog.alaska.edu>... Service unavailable
|>
|>What I'm looking to achieve is that the first two (current and transition)
will
|>work simultaneously for mail, then when I know what the future subdomain will
|>be, then I can allow the latter two entries to work. The mail gateway and
mail
|>hub systems are other machines.
|>
|>What I've found thus far is that changing it from one to another is trivial
|>using the mailsetup script, but haven't yet run across how *best* to accept
|>mail addressed to to both icefog.alaska.edu and icefog.uacn.alaska.edu as
|>unqualified host names.
|>
|>I could set myself up as a mail hub, but would rather not. I can get all the
|>aliases entered into our domain name server(s) easy enough.
|>
|>Looking for advice on the best way and the reasons why.
Conclusion:
With the following mods, I can now receive mail addressed to me
_at_icefog.alaska.edu and _at_icefog.uacn.alaska.edu - at least in my local testing,
anyway.
I ran mailsetup:
Is icefog a Mail Hub (y/[n]) ? y
...
Is icefog part of a Mail Cluster (y/[n]) ?
...
When mail leaves your local domain (alaska.edu), your return
address needs to be qualified. You can qualify it in one of the
following ways:
1) sender_at_icefog.alaska.edu - qualify with your machine name.
2) sender_at_alaska.edu - qualify with only your domain name.
Option #2 (`alaska.edu') is recommended.
Enter the tcp address format [ 2 ]:
...
Do you want aliases in /var/adm/sendmail/aliases to be considered local?
Aliases considered local ([y]/n) ?
...
Do you wish to enter nicknames for this machine (y/[n]) ?
<Keith.McCabe_at_ranplc.co.uk>
forwarded a message from the academic firewalls mailing list with the advice to
do as follows:
--------------------start forwarded message
>From Brent Chapman
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 "*_at_nyc.acme.com" and "*_at_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.
---------------end forwarded message
Further testing is being done as I create this, if there is anything to update,
I'll send an update message, else, this is it.
Randy
haymanr_at_icefog.alaska.edu
Received on Thu Feb 02 1995 - 19:52:51 NZDT