Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!cs.niu.edu!rickert
From: rickert@mp.cs.niu.edu (Neil Rickert)
Newsgroups: comp.mail.sendmail
Subject: Re: Proper handling of MX records
Message-ID: <1990Aug11.200440.27899@mp.cs.niu.edu>
Date: 11 Aug 90 20:04:40 GMT
References: <1990Aug10.192705.8072@mp.cs.niu.edu>
Organization: Northern Illinois University
Lines: 87

In article <1990Aug10.192705.8072@mp.cs.niu.edu> I wrote:
> There seem to be some problems with the handling of MX records in sendmail.
>My references are to sendmail-5.64.  Both the standard version and the IDA

 Here is some more information on the original problem which led to my earlier
comments.  At the end is the patch used.

  There is an address for HOST2, with two MX records.  Preference 10
  selects HOST1, while preference 100 selects HOST3.  HOST1 is trying
  to send mail to HOST2.  deliver.c calls getmxrr() to find the MX
  records, if any.  Consider the following two possible cases:

    Case 1:  The DNS resolver library returns the two MX records in the
	     order HOST1, HOST3.  getmxrr discovers that HOST1 is itself,
	     discards the record after setting 'localpref' to the preference.

	     getmxrr now examines the record for HOST3.  Since the preference
	     is >= localpref, it discards this record also.

	     getmxrr no decides that there are no valid MX records.  It then
	     returns HOST2, with a count of 1.

	     deliver.c now finds the Internet address of HOST2, and correctly
	     sends the mail.

	     NOTE: If there is only one MX record the same behavior occurs.

     Case 2: The DNS returns the records in the order HOST3, HOST1.  Here
	     getmxrr first sees HOST3, and places it in its response array.
	     Next it sees HOST1, recognizes it as itself, discards it after
	     setting 'localpref' to 10.

	     Now getmxrr() sorts the response array, and rejects any host
	     (HOST3) whose preference is >= localpref.  Since the response
	     array is now empty it returns an error indicator, and deliver.c
	     aborts with a 'configuration error' message.

 Clearly something is wrong here.  The behavior of sendmail should not depend
on the order in which the DNS resolver happens to return MX records.  The
enclosed patch changes the behavior so that the result of Case2 is the same
as that of Case 1.  It is my understanding that this is what the RFCs call for.
Namely: Only MX records with preference < local host preference are considered;
	If there are no MX records, and A record is sought.

 In the actual case where the problem arose, HOST2 was HOST3, but the MX record
returned was a bogus MX record due to qualifying HOST2 in the local domain
and matching a wildcard MX record.

 This solved the immediate problem.  But actually it is still technically wrong
since HOST2 does have its own MX records which are not in the local domain,
but they can never be found by the current code in getmxrr() if a wildcard
MX record exists.

 I suspect the correct behavior is that when no MX records are found, a second
attempt should be made, this time inhibiting qualification in the local domain.
Only after the second attempt should getmxrr() indicate no MX records found.

 Here is the patch which eliminates case 2 above.
           ------
*** /tmp/,RCSt1031327	Sat Aug 11 14:34:01 1990
--- domain.c	Sat Aug 11 14:33:03 1990
***************
*** 158,167 ****
  			 * the best choice left, we should have realized
  			 * awhile ago that this was a local delivery.
  			 */
! 			if (i == 0) {
! 				*rcode = EX_CONFIG;
! 				return(-1);
! 			}
  			nmx = i;
  			break;
  		}
--- 158,165 ----
  			 * the best choice left, we should have realized
  			 * awhile ago that this was a local delivery.
  			 */
! 			if (i == 0)
! 				goto punt;
  			nmx = i;
  			break;
  		}
-- 

=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Sci Dept, Northern Illinois U., DeKalb IL 60115
  InterNet, unix: rickert@cs.niu.edu              Bitnet, VM: T90NWR1@NIUCS