Re: [DNSOP] Fwd: New Version Notification for draft-mekking-dnsop-kasp-00.txt
At Fri, 04 Jul 2014 15:12:24 +0200, Matthijs Mekking matth...@nlnetlabs.nl wrote: I see more and more road maps that include implementing Key and Signing Policies, so Jerry and I thought it would be a good idea to standardize the policy model and the behavior of its elements. Ideally, policies can be used between multiple different software products, and if you do, you expect the same behavior. I think this is a laudable idea. I'm not sure if we can achieve the ideal goal, but it should be worth trying. I have just one very minor comment at this moment. While the draft says in Section 1.2 as follows: A key and signing policy can be expressed in any format. This document uses XML as example. there's only one XML example in it. Actually most examples use YANG. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
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
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
Kevin Darcy k...@chrysler.com wrote: if someone can give me an example (send privately if you wish) of a domain on the Internet with this null MX setup Here's a few our servers encountered today: agandm.com dur.net eay.com fnjr.com jolmail.com lfdf.com lki.org lllk.com missionnews.com ns1.com oeh.org qths.com rthc.com samueldumoulin.com sandradance.com senders.org sexnow.com wzr.net zcij.com Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fair Isle: Easterly veering southeasterly 3 or 4, occasionally 5 in south. Slight, occasionally moderate in south. Fog banks. Moderate or good, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
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
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
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
