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.
--
HLS
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
