[comp.mail.sendmail] Problem with MXs in Sun sendmail

ibarrac@scs.fiu.edu (Carlos Ibarra) (09/06/90)

At Florida International University, we have a network of Sun workstations
and a mailhost machine. I have set up the nameserver so that each workstation
has two MX RRs, one with preference 10 for itself, and one of preference 20,
for the mailhost machine. The idea is that the workstations are down more
often than the mailhost, so if a workstations is down and some outside machine
is trying to send mail to it, the outside machine should try the workstation
first, then the mailhost, which should accept the message.

The problem is, this does not work. If a workstation is down, the mailhost
machine's sendmail is contacted by the outside machine and receives the
message. Then, the mailhost sees that the destination machine is not itself,
and tries to contact the destination machine. Since that is still down, it then
tries the next MX which is itself. At that point, it fails with this error:
   ----- Transcript of session follows -----
Connected to serss0.fiu.edu:
>>> HELO fiu.edu
<<< 553 fiu.edu host name configuration error
554 cova@polar ... Service unavailable

Here, polar.fiu.edu is the destination machine, serss0.fiu.edu is the mailhost,
which also responds to the name fiu.edu.

Sendmail tries to contact itself through a TCP connection, therefore when it
recognizes that it is talking to itself, it cuts the connection to avoid a mail
loop.

According to RFC974 (Mail Routing and the Domain System), if the sender's own
name appears among the MX RR's for a destination machine, all MX RRs with
preference >= the sender's MX should be discarded. Does Sun's sendmail not
do this? If it did, it would not work anyway, right?

How can I make the mailhost machine accept the message which was originally
intended for the other machine (which is down) and not attempt to forward it?
 

hack@moxie.lonestar.org (Greg Hackney) (09/07/90)

ibarrac@scs.fiu.edu (Carlos Ibarra) writes:

>Connected to serss0.fiu.edu:
>>>> HELO fiu.edu
><<< 553 fiu.edu host name configuration error
>554 cova@polar ... Service unavailable

It sorta sounds like the sendmail.cf file on serss0 is
not configured to recognize itself as both "fiu.edu"
and as "serss0.fiu.edu". (Perhaps the Cm line?).
--
Greg Hackney
hack@moxie.lonestar.org

brian@ucsd.Edu (Brian Kantor) (09/07/90)

In sendmails 5.59 thru 5.64, there is a bug in domain.c that doesn't
properly compare MX names with hostnames - it doesn't use the FQDN of
your local host, so if your local hostname isn't set to a FQDN but is
instead a simple hostname (as most Suns are), the MX (which is fully
qualified) will not match to the local hostname, and you'll try to open
a connection to yourself - getting the 'not recognized as local'
(formerly, 'I refuse to talk to myself') error.  I assume Sun's
sendmail has the bug too.

The following patch (to 5.64) fixes that; it also adds a bit more
debugging that I used to figure this out.
	- Brian


*** ../../sendmail.64.virgin/src/domain.c	Tue Jun  5 18:27:44 1990
--- domain.c	Thu Jun 21 12:00:27 1990
***************
*** 55,61 ****
--- 63,79 ----
  	querybuf answer;
  	int ancount, qdcount, buflen, seenlocal;
  	u_short pref, localpref, type, prefer[MAXMXHOSTS];
+ 	char localhostfqdn[MAXNAME];
  
+ 	if (tTd(8, 1))
+ 		printf("getmxrr: res_search(host=`%s',MX)\n", host);
+ 
+ 	localpref = 0;
+ 	strcpy(localhostfqdn, localhost);
+ 	getcanonname(localhostfqdn, MAXNAME);
+ 	if (tTd(8, 2))
+ 		printf("getmxrr: \tlocalhost=`%s'\n", localhostfqdn);
+ 
  	errno = 0;
  	n = res_search(host, C_IN, T_MX, (char *)&answer, sizeof(answer));
  	if (n < 0)
***************
*** 119,125 ****
  		if ((n = dn_expand((char *)&answer, eom, cp, bp, buflen)) < 0)
  			break;
  		cp += n;
! 		if (!strcasecmp(bp, localhost)) {
  			if (seenlocal == 0 || pref < localpref)
  				localpref = pref;
  			seenlocal = 1;
--- 137,145 ----
  		if ((n = dn_expand((char *)&answer, eom, cp, bp, buflen)) < 0)
  			break;
  		cp += n;
! 		if (tTd(8, 2))
! 			printf("getmxrr: MX '%s' = %d\n", bp, pref);
! 		if (!strcasecmp(bp, localhostfqdn)) {
  			if (seenlocal == 0 || pref < localpref)
  				localpref = pref;
  			seenlocal = 1;

rickert@mp.cs.niu.edu (Neil W. Rickert) (09/07/90)

In article <18507@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes:
>In sendmails 5.59 thru 5.64, there is a bug in domain.c that doesn't
>properly compare MX names with hostnames - it doesn't use the FQDN of
>your local host, so if your local hostname isn't set to a FQDN but is
>instead a simple hostname (as most Suns are), the MX (which is fully
>qualified) will not match to the local hostname, and you'll try to open
>a connection to yourself - getting the 'not recognized as local'
>(formerly, 'I refuse to talk to myself') error.  I assume Sun's
>sendmail has the bug too.
>
>The following patch (to 5.64) fixes that; it also adds a bit more
>debugging that I used to figure this out.
>	- Brian
 ... patch followed.

 -----

 Congratulations.  You just fixed a problem which did not exist.  The
problem is in your sendmail configuration file, not in getmxrr().
Certainly there is a problem in getmxrr()  in domain.c, for which I
supplied a fix about two weeks ago.  But it is not here.

 Background:  getmxrr() is called from deliver.c with one of the parameters
(localhost) supposedly the name of the local host.  It is computed in
deliver.c by evaluating $w.  In my opinion this is wrong, and it should
use $j (that patch is in the IDA versions).  I did send Berkeley email
about this several weeks ago.  (If you want to change this, look in
deliver.c a few lines before getmxrr() is called).

 Brian's patch instead takes the value of localhost, and canonicalizes it
first.  THIS SHOULD NEVER WORK.  If this works, your sendmail.cf is wrong.
The $w macro should already be canonical.  If not, redefine $w near the
beginning of sendmail.cf

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115.                                  +1-815-753-6940