In message <53d2dbec.6060...@isdg.net>, Hector Santos writes: > > On 7/25/2014 1:18 PM, Kevin Darcy wrote:> > > I remain skeptical that the methodology in the draft, as written, > > requires no code changes, since I just performed a private experiment > > with a recent version of sendmail, and delivery failed in a > > spectacularly ugly way that made it appear much more like a bad .cf > > than "no mail accepted for this domain". But, I'll spare everyone the > > gory details of that experiment, and its aftermath, if someone can > > give me an example (send privately if you wish) of a domain on the > > Internet with this "null MX" setup, and I'll talk to our gateway folks > > to see if it fails in similarly ugly ways, at recent or latest code > > versions of our gateway software. (Yes, I know it was said earlier in > > the message thread that there have been no negative consequences of > > this "null MX" methodology after years of deployment, but I'm going to > > be from Missouri here -- "show me"). > > > I agree with you that code changes are needed, at least for our package. > > A published NULL MX does not reduced the number of MTA retries in our > implementation and thats because there are high false positives so the > full attempts are tried until exhausted. > > We will need to tweak the code or the retry frequency table for this > particular socket error, in this case 10061. To optimize, we will > need to specifically look for three conditions: > > MX.Count == 1 and > MX[0].Preference == 0 and > MX[0].Exchange == "." > > to trump, preempt any call attempt. Nuke the preference check. Count and exchange is enough.
> -- > HLS > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
