rickert@mp.cs.niu.edu (Neil Rickert) (09/19/90)
In article <gord.653697425@menaik> gord@cs.UAlberta.CA (Gord Urquhart) writes: > > I am running sendmail 5.61 in conjunction with Bind. Everything works >except for machines that are MX'ed to the local host. If there are 2 MX >records for a host with the prefered one being the local host then in This looks like a problem for which I posted a patch several weeks ago. Since it is a simple patch, I will repeat it. What happens is this: With two or more MX records, the behavior is dependent on the order in which the MX records are retrieved from the name server. If the best preference/local address entry comes first, it is rejected and so are all other MX records. There is then a lookup for an A-record (in deliver.c). But if the best preference does not come first, after all MX records have been stored they are sorted. In this case if the best preference is local a configuration error is declared. Clearly the dependence on the order makes no sense. Either it should always be a configuration error, or it should always result in a search for an A-record. Since the second choice is more useful, the patch implements it. Note: the patch is for sendmail 5.64, but there is probably very little difference in the code. *** /tmp/,RCSt1025390 Thu Sep 13 14:39:07 1990 --- domain.c Fri Aug 10 16:12:53 1990 *************** *** 161,170 **** * 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; } --- 161,168 ---- * 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 Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
piet@cwi.nl (Piet Beertema) (09/20/90)
>With two or more MX records, the behavior is dependent on the order >in which the MX records are retrieved from the name server. If the >best preference/local address entry comes first, it is rejected and >so are all other MX records. There is then a lookup for an A-record >(in deliver.c). But if the best preference does not come first, after >all MX records have been stored they are sorted. In this case if the >best preference is local a configuration error is declared. > Clearly the dependence on the order makes no sense. Either it should >always be a configuration error, or it should always result in a search >for an A-record. Since the second choice is more useful, the patch >implements it. In both cases only the local MX record is discarded (but marked) and all other MX records are stored and sorted. Then, if the highest-preference MX record points to the local host it's an error that should not be "solved" by looking at an A record. After all, the presence of an MX record indicates that, for whatever reason, the A record should *not* be used (e.g. if the domain is used by a uucp site). And if there is an A record, but the error occurs due to a wrong DNS entry for the domain, it's the DNS entry that should be fixed, not the way sendmail handles MX RR's. -- Piet Beertema, CWI, Amsterdam (piet@cwi.nl)
jeffe@sandino.austin.ibm.com (Peter Jeffe 512.823.4091) (10/15/90)
In article <1990Sep19.002139.32095@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > With two or more MX records, the behavior is dependent on the order >in which the MX records are retrieved from the name server. If the >best preference/local address entry comes first, it is rejected and >so are all other MX records. There is then a lookup for an A-record >(in deliver.c). But if the best preference does not come first, after >all MX records have been stored they are sorted. In this case if the >best preference is local a configuration error is declared. Hmmm, this continues to confuse me. You say you're working with 5.64, but I can't find the logic you refer to. In the reno 5.64 domain.c the following occurs in getmxrr() as it expands the response from the nameserver: > 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; > continue; > } > prefer[nmx] = pref; > mxhosts[nmx++] = bp; As you can see, unless the domain name matches the local hostname, the record is stored in the prefer and mxhosts arrays; if it matches the local host, then localpref and seenlocal are set. Unless I'm totally off my rocker, I don't see anywhere where "all other MX records" are rejected after the local one is seen, regardless of preference. Later, when the records are sorted, the ones with a preference >= localpref are discarded, as per rfc-974. If there are none left, then we've hit the "best is local" scenario and we get the EX_CONFIG returned. This is how the code reads, and this is how sendmail acts. If there are more than one MX records, and the highest pref is the localhost, then regardless of which order the records come in I get an EX_CONFIG. If there is only one MX and it is the localhost, then I get the "punt" strategy of attempting delivery directly to the host. To my mind, this is the only questionable conduct here, since a list consisting only of localhost is not the same as an empty list, and I think it should result in an EX_CONFIG instead of a punt. In any case, can someone please clarify where the above-described behavior is supposed to occur? I've shown you mine, now you show me yours :-) ------------------------------------------------------------------------------- Peter Jeffe ...uunet!cs.utexas.edu!ibmchs!auschs!sandino.austin.ibm.com!jeffe first they want a disclaimer, then they make you pee in a jar, then they come for you in the night