Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!mp.cs.niu.edu!rickert From: rickert@mp.cs.niu.edu (Neil Rickert) Newsgroups: comp.mail.sendmail Subject: Re: Local Configuration Error Message-ID: <1990Sep20.182739.29113@mp.cs.niu.edu> Date: 20 Sep 90 18:27:39 GMT References: <1990Sep19.002139.32095@mp.cs.niu.edu> <2199@charon.cwi.nl> Distribution: comp Organization: Northern Illinois University Lines: 56 In article <2199@charon.cwi.nl> piet@cwi.nl (Piet Beertema) 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 ..... and more quotes from my previous article. > >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. You must be looking at different source code to mine. In the 5.64 release from Berkeley, as soon as an MX record pointing to the local host is found its preference is recorded, and any further MX records are only stored into an array for sorting if they have a lower preference. Thus if the local preference is the best preference, and comes first, getmxrr() acts as if no MX records were found. If the local record is found later there are already entries in that array which will ultimately be all rejected, and in this case (unless the patch I supplied is used) a configuration error is declared. >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. Here I disagree. I said in my previous article that giving an A-record is more useful than declaring a configuration error. Let me give a scenario where that behavior is useful. Host X is on a private network, and cannot communicate with most internet hosts. Host Y is on both Internet and the private network. Host Y deliberately does not forward internet packets due to company policy, security concerns, etc. Host X has an A-record in the domain database to facilitate communication by hosts which are on the private network. There is an MX record directing email to host Y. Host Y should be able to forward the mail by SMTP; it should not have to set up a UUCP link just to circumvent the inadequacies of your interpretation. Of course the domain database could set up two MX records, with the highest preference to X, second preference to Y. This would work. But every host sending email to X would have to time out on its attempt to send to X before it sent to Y. This seems stupid, when the other method works. Namely, if there is not MX preference better than the local host (which would be true for Y, but for no other host), use the A record to forward mail. Although MX records are often used in association with UUCP forwarding of mail, don't close your mind to other possibilities. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940