Xref: utzoo comp.mail.sendmail:2262 comp.bugs.4bsd:1617 Path: utzoo!attcan!uunet!wuarchive!cs.utexas.edu!ut-emx!ibmchs!auschs!awdprime!sandino.austin.ibm.com!jeffe From: jeffe@sandino.austin.ibm.com (Peter Jeffe 512.823.4091) Newsgroups: comp.mail.sendmail,comp.bugs.4bsd Subject: Re: Local Configuration Error Keywords: sendmail, mx, bind Message-ID: <3856@awdprime.UUCP> Date: 15 Oct 90 00:16:09 GMT References: <1990Sep19.002139.32095@mp.cs.niu.edu> Sender: news@awdprime.UUCP Followup-To: comp.mail.sendmail Organization: IBM AWD, Austin, TX Lines: 55 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