Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!jhunix!andy From: andy@jhunix.HCF.JHU.EDU (Andy S Poling) Newsgroups: comp.mail.sendmail Subject: Re: Local Configuration Error Summary: wrong Keywords: backup SMTP server MX configuration error local Message-ID: <6460@jhunix.HCF.JHU.EDU> Date: 20 Sep 90 19:43:21 GMT References: <1990Sep19.002139.32095@mp.cs.niu.edu> <2199@charon.cwi.nl> Reply-To: andy@jhunix.hcf.jhu.edu (Andy Poling) Followup-To: comp.nail.sendmail Organization: The Johns Hopkins University - HCF Lines: 47 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 > >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. Wrong, wrong, wrong. I have a number of hosts that I would like to be able to "back each other up". That is, if hostA is down, hostB is a secondary MX for hostA and will receive hostA's mail and queue it until hostA regains consciousness. This approach takes the burden of retry-ing off of the far-away sender. Nowhere does anything say that because I am an MX for another host, I cannot choose to deliver mail to that host using SMTP. According to your interpretation, that is impossible and wrong. Frankly, considering how configurable the rest of sendmail is, I would think that this behavior ought to be controllable by setting an option. That behavior is more in the "spirit" of sendmail... My $.02 worth. -Andy -- Andy Poling Internet: andy@gollum.hcf.jhu.edu Systems Programmer Bitnet: ANDY@JHUNIX Homewood Academic Computing Voice: (301)338-8096 Johns Hopkins University UUCP: uunet!mimsy!aplcen!jhunix!andy