Well, I think I'm being misunderstood here. Allow me to try and clarify.
A) SMTP software -- all software, really -- should have a general
optimization of "don't try things that are doomed to failure"
B) As a specific instance of that general optimization, there's no point
in retrying a message that failed because of what was returned from DNS,
if the exact same records are still cached from the earlier lookup.
(Insanity is sometimes defined as doing the same thing, in the same
circumstances, and expecting a different result).
C) Does this imply that SMTP software should look at TTLs? Sure. Is this
harder to do with some APIs than others? Certainly. It is the nature of
optimizations that they are not *perfect*. Only that the help a lot, to
minimize wasted effort and/or resources
D) No "special semantics" are being applied to TTLs here. Just the
(obvious, definitional) fact that the TTL value controls cache
expiration, together with the realization that there's no point in
retrying a message if the contents of your name-resolution cache are
going to doom your attempt
E) Putting all of this together: domain owners who choose not to provide
SMTP service could point their MX to a name, of their choosing, that
resolves to a null address, and with a sufficiently-high TTL, such that
SMTP clients obeying the optimization identified above, will auto-fail
the message (tempfail promoted to permfail) if the DNS-record expiration
time would occur after the client's queue-expiration time. Bonus points
awarded for recognizing the special nature of the null address and
giving a nice friendly error message back to the sender to the effect
that mail service is not available for the domain.
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").
As a minor editorial nit, the draft refers to "null MX" being "an
ordinary MX record" in the Security Considerations, after Section 3
already proclaimed "a NULL MX
record can not be confused with an ordinary MX record". So it is
"ordinary" or isn't it? Maybe different adjectives should be used...
- Kevin
On 7/24/2014 11:10 PM, Mark Delany wrote:
On 24Jul14, Kevin Darcy allegedly wrote:
So, if the TTL on the record were higher than the queue-expire setting
of the MTA, wouldn't the *intelligent* strategy be to promote the
tempfail to a permfail?
Most SMTP clients use a DNS cache so they have no idea what the
original TTL is.
Even if they could see the auth TTL you'd have to worry about domains
that just happen to have very large TTLs in place today for whatever
reason. How do you differentiate those domains?
As far as standardizing such an idea, I'd hazard a guess that the IETF
would not look kindly on encoding semantics into TTL values. Your
rationale for this approach would need to be pretty compelling.
I've never written an MTA, but it seems like an
obvious optimization to me.
It's surprising how hard it is to get the TTL out of most DNS client
libraries. None of the gethostby* family return it. Even fancy
libraries like c-ares are hit and miss with making the TTL available
for different RR types.
And of course the whole thing implies changing every SMTP client on
the planet to recognize these large TTLs. That's a bit of work.
All in all it's hard to see what this approach achieves compared to
nullmx which works today with no code changes and does not require any
special interpretation of DNS data.
Mark.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
