SUMMARY: sendmail.mx doesn't work locally

From: Patrick O'Callaghan (poc@usb.ve)
Date: Fri Feb 12 1993 - 16:38:59 CST


Sorry this has taken so long, but I've only just solved the problem.
First, my question:

>> I've just installed Sun's sendmail.mx in place of standard sendmail,
>> but it doesn't seem to work correctly. To explain:
>>
>> SunOS 4.1.2, NIS + DNS. The MX RR points all mail to this domain
>> (usb.ve) at a central server (shaddam.usb.ve). This works fine fromm
>> anywhere *except* from shaddam itself, i.e. if I do:
>>
>> shaddam> mail -v poc@urth.usb.ve
>> Subject: MX test
>> foo bar
>> .
>> EOT
>> shaddam> poc@urth.usb.ve... Connecting to urth via ether...
>> Trying 159.90.10.3... Connection refused by urth
>> poc@urth.usb.ve... Deferred: Connection refused by urth
>>
>> The same test from any other machine works correctly. I've tried it on
>> our local machines and also from elsewhere in the Internet, with zero
>> problems. Note that no machine apart from shaddam is running a
>> sendmail demon, and that shaddam's demon is sendmail.mx. Before anyone
>> asks, yes I *did* make the commented change in the cf file, and yes I
>> *did* reinitialize the freeze file.

OK, a number of people asked whether my sendmail is actually called
sendmail, or sendmail.mx. Seems like more than one of you has been
bitten by this. It *must* be called /usr/lib/sendmail or other things
(like "mail") won't find it. I actually thought of this just after
sending the post, but it doesn't solve the problem.

Thanks, but no cigar, to:

From: "Jim Davis" <jdavis@cs.arizona.edu>
From: Neil W Rickert <rickert@cs.niu.edu>
From: blymn@mulga.awadi.com.AU (Brett Lymn)
From: Ying.Ho@Corp.Sun.COM (Steven Ho)

(Steven Ho was closest to the right answer)

After a good deal of Deep Thought, I went back to the beginning and
reread RFC974 (Mail Routing and the Domain System). It turns out that
the behaviour I'm seeing is exactly correct. The RFC states:

   The first major principle is derived from the definition of the
   preference field in MX records, and is intended to prevent mail
   looping. If the mailer is on a host which is listed as an MX for the
   destination host, the mailer may only deliver to an MX which has a
   lower preference count than its own host.

and

      If the domain name LOCAL is listed as an MX RR, all MX RRs with a
      preference value greater than or equal to that of LOCAL's must be
      discarded.

and

   Another, more dangerous, possibility is that the domain system
   believes that LOCAL is handling message for REMOTE, but the mailer
   on LOCAL is not set up to handle mail for REMOTE. For example, if
   the domain system lists LOCAL as the only MX for REMOTE, LOCAL will
   delete all the entries in the list. But LOCAL is presumably
   querying the domain system because it didn't know what to do with a
   message addressed to REMOTE. Clearly something is wrong. How a
   mailer chooses to handle these situations is to some extent
   implementation dependent, and is thus left to the implementor's
   discretion.

In other words, you have to handle this case in your sendmail.cf. For
now, I just defined the "w" class specfically as all my local
machines, i.e. sendmail now thinks they are all aliases for the
mailhost. This seems to work but is not elegant. If anyone has a more
theologically sound solution I'd be glad to hear from them.

The Motto is of course: RTFRFC :-)

Patrick O'Callaghan Internet: poc@usb.ve
Departamento de Computacion NICNAME: PO22
Universidad Simon Bolivar Tel: +058 (2) 963 3022 ext 3320
Apartado de Correos 89000 FAX: +058 (2) 93 71 28
Caracas, Venezuela "There is no Net but the Internet"



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:28 CDT