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 6:41 PM, Mark Andrews wrote: In message 53d2dbec.6060...@isdg.net, Hector Santos writes: 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. Hi Mark, Sure, but its not the true spec condition. As stated in section 3, anything else but the three conditions could be programmatically extracted to be an error some where; an exception, indeterminate condition, possible corruption, not the spec condition, a how can this happen situation. What does an diligent, high QA conscious coder do? Being Specific Is Terrific! If the preference can technically be any non-zero value for a No Mail Service MX record, then the spec should probably make note of that in section 3, otherwise a coder may wonder and add an exception. 3. MX Resource Records Specifying Null MX To indicate that a domain does not accept email, it advertises a single MX RR (see [RFC1035], section 3.3.9) with an RDATA section consisting of a zero length label, written in master files as ., as the exchange domain, to denote that there exists no mail exchanger for a domain. The Preference SHOULD be set to zero, but implementators SHOULD NOT depend on it being zero for the NULL MX to be defined. Additional comments/nits about the draft: o Preference vs Priority An implementation note could be added: Implementation note: Some DNS record UI managers use the term Priority instead of Preference. MX expansion requires a sorted mail host order by increasing preference. The mail host with lower preferences are tried first. A Higher priority value in these UIs does not mean they are tried first. The DNS management tools I just recently used (Microsoft DNS v5 Windows GUI manager and Godaddy's web-based DNS manager) to quickly explore this used, the term Priority instead of the IETF spec defined Preference term for this MX field name. The draft has no reference to the term priority and/or the possible market, administration and technical terminology discrepancies. o No Permanent Blocks Semantics I think the draft should make a note that permanent blocks should not be extracted from an NULL MX records or the final resolution of attempts. The NULL MX condition can quickly change at any time. It is merely (to me, as I can see) an optimizer to short circuit an outbound attempt and also test an incoming message return path domain readiness for bounces/DSN which is a SMTP required mode of operation. o Security overstatement I think the security section does not need to be talking about SMTP being 'inherently insecure. Whether a site does dynamic checking or not of the SMTP session return path is the main thing here. This draft isn't removing any insecurity other than suggesting it is one way to detect the mail hosting service availability of an email domain without the need to actually try/test it. An optimizer. In fact, I think its possible that the attempt to define a NULL MX can actually nullify and learned behaver for a Implicit MX logic where there is no record at all. NULL MX is a real record and that can trigger different logic than an real NO MX record condition. For example, some MTA may have an option: [X] NO MX, Try A record ONCE TIME That was the case for our older version of MTA. The rule was relaxed (default OFF) due to the false positives. So for the modern versions, it doesn't matter anymore -- retries are based on the last SOCKET or SMTP error condition. -- 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
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
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
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? I've never written an MTA, but it seems like an obvious optimization to me. - Kevin On 7/23/2014 10:00 PM, Mark Andrews wrote: In message 53cfbb29.7040...@chrysler.com, Kevin Darcy writes: Potentially dumb question: what does this magic meaning MX target (.) offer, that a target resolving to a null address (0.0.0.0 and/or ::0) does not? No protocol or code changes required. The null address does, after all, mean no service offered here. (Now, if only load-balancer vendors could wrap their tiny minds around that concept!) - Kevin 0.0.0.0 and :: mean I offer service but I don't currently have a address / know my address. This is a temp fail rather than a permanent fail along with a ttl to retry the address lookup. On 7/17/2014 4:59 PM, Dave Crocker wrote: On 7/17/2014 10:39 AM, John C Klensin wrote: Hi. For a number of reasons, many of which have been identified by others, I find this draft and the actions it recommends distasteful. Since I'm the doc shepherd: I have not seen statements by others indicating that the specification is 'distasteful', although there have been some that seemed to confuse its functionality with that of SPF. Feel free to cite the specific comments by others that classed this as distasteful or the equivalent. I see it as another step, albeit a small one, in the direction of prioritizing the prevention of unwanted messages or connections over successful delivery of legitimate messages. A statement of I don't do X does not 'prioritize' anything. The use of information that says target address Y will not work because there is not receiver at Y's domain does not 'prioritize' anything. The specification is nothing more than a vastly more efficient form of getting an SMTP 550 Requested action not taken: mailbox unavailable, except that it is even better than that, because it also precludes waiting days to discover that there's no service to supply even that error message. Hope, it would be better if the specification were historically accurate and accurate about the protocols it cites. You do not clearly indicate any historical inaccuracy at issue. The last sentence of the second paragraph of Section 5 (Security Considerations) of the spec says: The normal way to send mail for which a sender wants no responses remains unchanged, by using an empty RFC5321.MailFrom address. First, two issues of terminology: (1) RFC 5321 does not contain or specify notations like RFC5321.MailFrom. That notation was introduced in RFC 5598, a document that was approved as Informational with a consensus that, IIR, included some significant desire that it not be normative or casually treated as normative. If this First, so what? Second, a review of the IETF mailing list archive about the document's Last Call, in May of 2009, shows a nicely solid pattern of support for the document's publication. Strange that you would call it into question at this point. specification wants to use that notation, that is fine. But it should include an explicit note to that effect in its introduction or a Terminology section, not bury a (see [RFC5598] for the definitions of these terms) reference in a parenthetical note in Section 4.1 and then expect readers who are looking specifically at other sections to pick up on it. If you want specific text changes, please suggest specific text changes. Please do not formulate a requirement for change in a fashion that leaves the authors having to guess whether it will satisfy you. I believe that the RFC Editor's principle is that, if particular terminology is needed to correctly understand a specification, then the reference to the document that defines that terminology is normative. In this particular case, it seems inconsistent to consider 2119 normative and 5598 informative since both are used to define terminology without which the document cannot be correctly understood. So, you are suggesting that RFC 5598 be a normative reference here? (2) Second, RFC 5321 does not contain a concept that it calls an empty address. The terminology it does use is null reverse-path (See RFC 5321, Section 3.7). Subject to the above, if the authors want to say null address in RFC5321.MailFrom, I don't think that is sufficiently confusing to be a problem. But empty address could be construed as MAIL FROM: in the envelope with nothing following it, and that would be bad news. So you are suggesting: empty RFC5321.MailFrom address - null () reverse-path, per 3.6.3 and 6.1 of RFC 5321 More important, however, RFC 5321 specifies the use of a null reverse path only for delivery failure and status notifications and message disposition notifications (see
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 53d133d4.4020...@chrysler.com, Kevin Darcy writes: 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? I've never written an MTA, but it seems like an obvious optimization to me. - Kevin I doubt that it is worth the effort. If one was doing this the ttl is likely to be very small ( 60) so that there are minimal effects when you do reconnect. Mark On 7/23/2014 10:00 PM, Mark Andrews wrote: In message 53cfbb29.7040...@chrysler.com, Kevin Darcy writes: Potentially dumb question: what does this magic meaning MX target (.) offer, that a target resolving to a null address (0.0.0.0 and/or ::0) does not? No protocol or code changes required. The null address does, after all, mean no service offered here. (Now, if only load-balancer vendors could wrap their tiny minds around that concept!) - Kevin 0.0.0.0 and :: mean I offer service but I don't currently have a address / know my address. This is a temp fail rather than a permanent fail along with a ttl to retry the address lookup. On 7/17/2014 4:59 PM, Dave Crocker wrote: On 7/17/2014 10:39 AM, John C Klensin wrote: Hi. For a number of reasons, many of which have been identified by others, I find this draft and the actions it recommends distasteful. Since I'm the doc shepherd: I have not seen statements by others indicating that the specification is 'distasteful', although there have been some that seemed to confuse its functionality with that of SPF. Feel free to cite the specific comments by others that classed thi s as distasteful or the equivalent. I see it as another step, albeit a small one, in the direction of prioritizing the prevention of unwanted messages or connections over successful delivery of legitimate messages. A statement of I don't do X does not 'prioritize' anything. The use of information that says target address Y will not work because there is not receiver at Y's domain does not 'prioritize' anything. The specification is nothing more than a vastly more efficient form of getting an SMTP 550 Requested action not taken: mailbox unavailable, except that it is even better than that, because it also precludes waiting days to discover that there's no service to supply even that error message. Hope, it would be better if the specification were historically accurate and accurate about the protocols it cites. You do not clearly indicate any historical inaccuracy at issue. The last sentence of the second paragraph of Section 5 (Security Considerations) of the spec says: The normal way to send mail for which a sender wants no responses remains unchanged, by using an empty RFC5321.MailFrom address. First, two issues of terminology: (1) RFC 5321 does not contain or specify notations like RFC5321.MailFrom. That notation was introduced in RFC 5598, a document that was approved as Informational with a consensus that, IIR, included some significant desire that it not be normative or casually treated as normative. If this First, so what? Second, a review of the IETF mailing list archive about the document's Last Call, in May of 2009, shows a nicely solid pattern of support for the document's publication. Strange that you would call it into question at this point. specification wants to use that notation, that is fine. But it should include an explicit note to that effect in its introduction or a Terminology section, not bury a (see [RFC5598] for the definitions of these terms) reference in a parenthetical note in Section 4.1 and then expect readers who are looking specifically at other sections to pick up on it. If you want specific text changes, please suggest specific text changes. Please do not formulate a requirement for change in a fashion that leaves the authors having to guess whether it will satisfy you. I believe that the RFC Editor's principle is that, if particular terminology is needed to correctly understand a specification, then the reference to the document that defines that terminology is normative. In this particular case, it seems inconsistent to consider 2119 normative and 5598 informative since both are used to define terminology without which the document cannot be correctly understood. So, you are suggesting that RFC 5598 be a normative reference here? (2) Second, RFC 5321 does not contain a concept that it calls an empty address. The terminology it does use is null reverse-path (See RFC 5321, Section 3.7). Subject to the above, if the authors want to say null address in RFC5321.MailFrom, I don't think that is sufficiently confusing to be a problem. But empty address could be construed as MAIL
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 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
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 20140725031019.24785.qm...@f5-external.bushwire.net, Mark Delany writes: 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. 0.0.0.0 and :: are orthognal to MX 0 . One means I am a host, I exist, but I don't know my/have a address presumably because it is offline, the other means There is no SMTP service for this domain. One is temp fail for SMTP, the other is a permanent fail. Mark. ___ 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
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
Potentially dumb question: what does this magic meaning MX target (.) offer, that a target resolving to a null address (0.0.0.0 and/or ::0) does not? No protocol or code changes required. The null address does, after all, mean no service offered here. (Now, if only load-balancer vendors could wrap their tiny minds around that concept!) - Kevin On 7/17/2014 4:59 PM, Dave Crocker wrote: On 7/17/2014 10:39 AM, John C Klensin wrote: Hi. For a number of reasons, many of which have been identified by others, I find this draft and the actions it recommends distasteful. Since I'm the doc shepherd: I have not seen statements by others indicating that the specification is 'distasteful', although there have been some that seemed to confuse its functionality with that of SPF. Feel free to cite the specific comments by others that classed this as distasteful or the equivalent. I see it as another step, albeit a small one, in the direction of prioritizing the prevention of unwanted messages or connections over successful delivery of legitimate messages. A statement of I don't do X does not 'prioritize' anything. The use of information that says target address Y will not work because there is not receiver at Y's domain does not 'prioritize' anything. The specification is nothing more than a vastly more efficient form of getting an SMTP 550 Requested action not taken: mailbox unavailable, except that it is even better than that, because it also precludes waiting days to discover that there's no service to supply even that error message. Hope, it would be better if the specification were historically accurate and accurate about the protocols it cites. You do not clearly indicate any historical inaccuracy at issue. The last sentence of the second paragraph of Section 5 (Security Considerations) of the spec says: The normal way to send mail for which a sender wants no responses remains unchanged, by using an empty RFC5321.MailFrom address. First, two issues of terminology: (1) RFC 5321 does not contain or specify notations like RFC5321.MailFrom. That notation was introduced in RFC 5598, a document that was approved as Informational with a consensus that, IIR, included some significant desire that it not be normative or casually treated as normative. If this First, so what? Second, a review of the IETF mailing list archive about the document's Last Call, in May of 2009, shows a nicely solid pattern of support for the document's publication. Strange that you would call it into question at this point. specification wants to use that notation, that is fine. But it should include an explicit note to that effect in its introduction or a Terminology section, not bury a (see [RFC5598] for the definitions of these terms) reference in a parenthetical note in Section 4.1 and then expect readers who are looking specifically at other sections to pick up on it. If you want specific text changes, please suggest specific text changes. Please do not formulate a requirement for change in a fashion that leaves the authors having to guess whether it will satisfy you. I believe that the RFC Editor's principle is that, if particular terminology is needed to correctly understand a specification, then the reference to the document that defines that terminology is normative. In this particular case, it seems inconsistent to consider 2119 normative and 5598 informative since both are used to define terminology without which the document cannot be correctly understood. So, you are suggesting that RFC 5598 be a normative reference here? (2) Second, RFC 5321 does not contain a concept that it calls an empty address. The terminology it does use is null reverse-path (See RFC 5321, Section 3.7). Subject to the above, if the authors want to say null address in RFC5321.MailFrom, I don't think that is sufficiently confusing to be a problem. But empty address could be construed as MAIL FROM: in the envelope with nothing following it, and that would be bad news. So you are suggesting: empty RFC5321.MailFrom address - null () reverse-path, per 3.6.3 and 6.1 of RFC 5321 More important, however, RFC 5321 specifies the use of a null reverse path only for delivery failure and status notifications and message disposition notifications (see Section 4.5.5 of RFC 5321) and constrains the recipient address to be used. That section also says All other types of messages (i.e., any message which is not required by a Standards-Track RFC to have a null reverse-path) SHOULD be sent with a valid, non-null reverse-path. And here I was, thinking that SHOULD means it is ok /not/ to do what is being directed, if you have a good reason. Oh, wait... Specifically referring to Section 3 of draft-ietf-appsawg-nullmx-05, there is not such thing as a NULL MX Resource Record. There is only an MX Resource Record that
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: Potentially dumb question: what does this magic meaning MX target (.) offer, that a target resolving to a null address (0.0.0.0 and/or ::0) does not? No protocol or code changes required. A target of . causes an immediate permanent failure, whereas a tagret that resolves to 0.0.0.0 is likely to cause retries and eventual timeouts. The null address does, after all, mean no service offered here. No, it means this host - see RFC 3330. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fisher, North German Bight: Northeast 3 or 4. Smooth or slight. Fair. Good. ___ 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 article alpine.lsu.2.00.1407231447050.13...@hermes-1.csi.cam.ac.uk you write: Kevin Darcy k...@chrysler.com wrote: Potentially dumb question: what does this magic meaning MX target (.) offer, that a target resolving to a null address (0.0.0.0 and/or ::0) does not? No protocol or code changes required. A target of . causes an immediate permanent failure, whereas a tagret that resolves to 0.0.0.0 is likely to cause retries and eventual timeouts. In practice, A records of 0.0.0.0 cause mail loops, and I have the logs to show it. It's a really bad idea. The version of null MX in the draft has been in wide use since 2006. If anyone wants to do something different, the proposal needs to explain why it is so much better than the existing practice that all of the existing implementations that already work would be willing to change their code. R's, John ___ 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 OK, so it's a semi-dumb question. But if we're going to assign magic meaning to something, why not assign magic meaning to the null address *specifically*in*the*context*of*SMTP*message*delivery*strategy*, i.e. auto-fail messages destined for the null address and never retry them? To nitpick your standards point about the null address, Section 2.5.2 of RFC 4291 says that the IPv6 null address (which it idiomatically calls the unspecified address) must not be used as the destination address of IPv6 packets or in IPv6 Routing headers which effectively amounts to no service here. Can't get there. I haven't gone back to see if the IPv4 null address has been similarly clarified/redefined, because, who still uses IPv4 anyway? :-) - Kevin On 7/23/2014 9:54 AM, Tony Finch wrote: Kevin Darcy k...@chrysler.com wrote: Potentially dumb question: what does this magic meaning MX target (.) offer, that a target resolving to a null address (0.0.0.0 and/or ::0) does not? No protocol or code changes required. A target of . causes an immediate permanent failure, whereas a tagret that resolves to 0.0.0.0 is likely to cause retries and eventual timeouts. The null address does, after all, mean no service offered here. No, it means this host - see RFC 3330. Tony. ___ 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
OK, fair enough. Just as long as we understand and properly record the design decision that was made here: I.e. we're more afraid of the negative consequences of software/OSes that don't treat null addresses reasonably (i.e. pointless/doomed retries, possible self-looping) than we are of the negative consequences of software that is slow or defective in their adoption of the new magic meaning of root-name MX targets (i.e. pointless/doomed A/ queries of the root name). - Kevin On 7/23/2014 12:16 PM, Tony Finch wrote: Kevin Darcy k...@chrysler.com wrote: But if we're going to assign magic meaning to something, why not assign magic meaning to the null address *specifically*in*the*context*of*SMTP*message*delivery*strategy*, i.e. auto-fail messages destined for the null address and never retry them? Because that will have horrible fallout for existing software that does not undestand the magic meaning. @ MX 0 . already has the correct semantics; the only magic in the nullmx spec is to suppress the A and lookups because they will always fail. must not be used as the destination address of IPv6 packets or in IPv6 Routing headers I haven't gone back to see if the IPv4 null address has been similarly clarified/redefined, because, who still uses IPv4 anyway? :-) Yes, 0.0.0.0 is only for use as a source address. Tony. ___ 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 53cfbb29.7040...@chrysler.com, Kevin Darcy writes: Potentially dumb question: what does this magic meaning MX target (.) offer, that a target resolving to a null address (0.0.0.0 and/or ::0) does not? No protocol or code changes required. And just to be clear, nullmx as proposed does not required any code changes and never has. It's simply recognizing a (to me at least) serendipitous confluence of existing attributes of DNS and SMTP. No new protocols are being invented and no deviation from those two standards is being suggested. Remember, considerate receivers have been adding this MX to their zones for many years and senders, whether they know it or not, having been automatically reaping the benefits as a consequence. This is about as close as it gets to a free lunch on the Internet. Mark. ___ 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/18/2014 8:40 PM, Mark Andrews wrote: MX 0 . is also consistent with SRV 0 0 0 . which is documented. Right. As Tony Finch has also noted. The specific citation is: RFC 2782: Target ... A Target of . means that the service is decidedly not available at this domain. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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/17/2014 10:39 AM, John C Klensin wrote: Hi. For a number of reasons, many of which have been identified by others, I find this draft and the actions it recommends distasteful. Since I'm the doc shepherd: I have not seen statements by others indicating that the specification is 'distasteful', although there have been some that seemed to confuse its functionality with that of SPF. Feel free to cite the specific comments by others that classed this as distasteful or the equivalent. I see it as another step, albeit a small one, in the direction of prioritizing the prevention of unwanted messages or connections over successful delivery of legitimate messages. A statement of I don't do X does not 'prioritize' anything. The use of information that says target address Y will not work because there is not receiver at Y's domain does not 'prioritize' anything. The specification is nothing more than a vastly more efficient form of getting an SMTP 550 Requested action not taken: mailbox unavailable, except that it is even better than that, because it also precludes waiting days to discover that there's no service to supply even that error message. Hope, it would be better if the specification were historically accurate and accurate about the protocols it cites. You do not clearly indicate any historical inaccuracy at issue. The last sentence of the second paragraph of Section 5 (Security Considerations) of the spec says: The normal way to send mail for which a sender wants no responses remains unchanged, by using an empty RFC5321.MailFrom address. First, two issues of terminology: (1) RFC 5321 does not contain or specify notations like RFC5321.MailFrom. That notation was introduced in RFC 5598, a document that was approved as Informational with a consensus that, IIR, included some significant desire that it not be normative or casually treated as normative. If this First, so what? Second, a review of the IETF mailing list archive about the document's Last Call, in May of 2009, shows a nicely solid pattern of support for the document's publication. Strange that you would call it into question at this point. specification wants to use that notation, that is fine. But it should include an explicit note to that effect in its introduction or a Terminology section, not bury a (see [RFC5598] for the definitions of these terms) reference in a parenthetical note in Section 4.1 and then expect readers who are looking specifically at other sections to pick up on it. If you want specific text changes, please suggest specific text changes. Please do not formulate a requirement for change in a fashion that leaves the authors having to guess whether it will satisfy you. I believe that the RFC Editor's principle is that, if particular terminology is needed to correctly understand a specification, then the reference to the document that defines that terminology is normative. In this particular case, it seems inconsistent to consider 2119 normative and 5598 informative since both are used to define terminology without which the document cannot be correctly understood. So, you are suggesting that RFC 5598 be a normative reference here? (2) Second, RFC 5321 does not contain a concept that it calls an empty address. The terminology it does use is null reverse-path (See RFC 5321, Section 3.7). Subject to the above, if the authors want to say null address in RFC5321.MailFrom, I don't think that is sufficiently confusing to be a problem. But empty address could be construed as MAIL FROM: in the envelope with nothing following it, and that would be bad news. So you are suggesting: empty RFC5321.MailFrom address - null () reverse-path, per 3.6.3 and 6.1 of RFC 5321 More important, however, RFC 5321 specifies the use of a null reverse path only for delivery failure and status notifications and message disposition notifications (see Section 4.5.5 of RFC 5321) and constrains the recipient address to be used. That section also says All other types of messages (i.e., any message which is not required by a Standards-Track RFC to have a null reverse-path) SHOULD be sent with a valid, non-null reverse-path. And here I was, thinking that SHOULD means it is ok /not/ to do what is being directed, if you have a good reason. Oh, wait... Specifically referring to Section 3 of draft-ietf-appsawg-nullmx-05, there is not such thing as a NULL MX Resource Record. There is only an MX Resource Record that this specification proposes to use with a convention involving specific content in the DATA. One could call that many things, but NULL MX Resource Record isn't one of them. By my reading of that section, it is defining the term, if only by virtue of the way it is used in the name of that section. Perhaps your confusion would be resolved if the term had a comma in it, so:
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
Hi. I have a few questions that I don't want to clutter the IETF list about but about which I would hope DNS experts, especially DNS root operations experts, would step in if they have opinions. IESG copied only for the record. I want to stress that these are questions: I may know enough to ask them but can't even competently speculate on the answers. The new specification proposes what is, in essence, a convention. If an SMTP-Sender (to use the original and very precise terminology), while doing the required lookup for an MX RR, encounters IN MX 0 . it is expected to abort the message-sending process -- no further lookups, not connection attempts, no queuing. At least in the near term, some SMTP Server (MTA) implementations will conform to that rule (many already use it) and some won't. For the latter, they will presumably do what the SMTP specs say to do. In summary, that is to look up the address(es) associated with the root and try to open a mail connection to one of them. When that connection fails (presumably times out), the SMTP server may decide to try more (or all) of the other addresses. When all of those it chooses to try fail, it is then required to queue the message, retrying the process (potentially to all 13 root servers) at regular intervals for an extended period of time. It is impossible for me to estimate the actual likely volume of such connection attempts. I suggest that any such estimate would be no better than a wild guess. It is clear that the requirement for retries and the number of root servers (i.e., that there is more than one address record) provides a multiplier effect on the number of MTAs and misdirected messages that do not follow the convention. Given that the DNS configurations for some domains are using this convention now, it should be possible to measure present-day SMTP connection attempts to the root servers. I don't know if anyone has those data. Because such attempts could originate from multiple causes, it might also be hard to interpret if it existed... beyond my experience. So, three (obviously-related) questions: (1) I understand that there have been concerns from time to time about the load caused by spurious queries to the root servers. These would not be spurious DNS queries (I assume primarily UDP) but spurious TCP connections to a port that I assume no contemporary root server uses to accept mail. Is that potential change in load an issue that anyone should be concerned about? (2) Would you recommend that the root servers take any special action to mitigate the potential problem? Such action might involve a port 25 responder that immediately closes connections (at least reducing timeout waits), or a fake SMTP server that would allow a connection to be opened, then immediately send a 5yz response to the SMTP sender. If the SMTP specs are followed by the sender, the latter would prevent attempts on other root server address and the queuing behavior. Either obviously involves some additional resources. (3) Independent of the answer to the question above, does the possibility of DNS operational impact as the result of this convention merit comments in the I-D that are not now present and, if so, what should be said? Recommendation: if the participants in DNSOP consider either of the above questions (and they are only questions) to be significant, it may be worthwhile to ask the IESG to postpone a decision on this document until this WG has an opportunity to comment. The above is obviously independent of the concerns about terminology that I raised in my Last Call response. As some of you know, sloppy and ambiguous terminology in discussions of the DNS has become a pet peeve of mine. If no one else cares, or cases enough to put effort into the problem -- even to prevent new ambiguous usage from entering the vocabulary via IETF standards track documents -- then I will go back to whining into my beer and stop trying to waste other's time on the issues. best, john ___ 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 93f32648fd67ae6abac47...@jck-hp8200.jck.com, John C Klensin writes : Hi. I have a few questions that I don't want to clutter the IETF list about but about which I would hope DNS experts, especially DNS root operations experts, would step in if they have opinions. IESG copied only for the record. I want to stress that these are questions: I may know enough to ask them but can't even competently speculate on the answers. The new specification proposes what is, in essence, a convention. If an SMTP-Sender (to use the original and very precise terminology), while doing the required lookup for an MX RR, encounters IN MX 0 . it is expected to abort the message-sending process -- no further lookups, not connection attempts, no queuing. At least in the near term, some SMTP Server (MTA) implementations will conform to that rule (many already use it) and some won't. For the latter, they will presumably do what the SMTP specs say to do. In summary, that is to look up the address(es) associated with the root and try to open a mail No. Lookup the address _at_ _the_ _root_. This is _not_ the addresses of the root servers. connection to one of them. When that connection fails (presumably times out), the SMTP server may decide to try more (or all) of the other addresses. When all of those it chooses to try fail, it is then required to queue the message, retrying the process (potentially to all 13 root servers) at regular intervals for an extended period of time. What connection? There are no addresses records at . so the MTA returns a NDN. Mark -- 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
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
John C Klensin john-i...@jck.com wrote: IN MX 0 . At least in the near term, some SMTP Server (MTA) implementations will conform to that rule (many already use it) and some won't. For the latter, they will presumably do what the SMTP specs say to do. In summary, that is to look up the address(es) associated with the root and try to open a mail connection to one of them. There are no addresses associated with the root, so the mail server will immediately report a delivery error. RFC 5321 section 5.1 paragraph 2 final sentence. The SMTP server will not try to connect to the root name servers, as your message suggested. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Biscay: Variable 3 or 4, becoming northwesterly 5 or 6 for a time in east. Slight or moderate. Rain or thundery showers. Good, occasionally 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
Tony Finch wrote: John C Klensin john-i...@jck.com wrote: IN MX 0 . At least in the near term, some SMTP Server (MTA) implementations will conform to that rule (many already use it) and some won't. For the latter, they will presumably do what the SMTP specs say to do. In summary, that is to look up the address(es) associated with the root and try to open a mail connection to one of them. There are no addresses associated with the root, so the mail server will immediately report a delivery error. RFC 5321 section 5.1 paragraph 2 final sentence. The SMTP server will not try to connect to the root name servers, as your message suggested. true as stated. what's unstated here is that every SMTP sender who encounters such an MX without understanding its new meaning will do two or three lookups: . MX, [. ,] and . A. if they are behind an RDNS that doesn't do negative caching (and there are many, though none of them are open source; the open source RDNS servers do negative caching right) then these two or three queries will flow through to the authority servers for . which is to say the root name servers. the long tail on old interpretation is between one and three decades. (which is also why repurposing/redefining things like TCP/53 is unworkable, as discussed separately.) if IETF had rules, one of them should be, don't redefine things that are in an existing datapath -- make a new datapath. vixie ___ 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 Friday, July 18, 2014 23:18 +1000 Mark Andrews ma...@isc.org wrote: At least in the near term, some SMTP Server (MTA) implementations will conform to that rule (many already use it) and some won't. For the latter, they will presumably do what the SMTP specs say to do. In summary, that is to look up the address(es) associated with the root and try to open a mail No. Lookup the address _at_ _the_ _root_. This is _not_ the addresses of the root servers. I tried to make clear that I'm ignorant of many of the details here, so, if there is no issue, I apologize for wasting people's time. If the answer to those questions is not an issue, that is the answer and the end of the discussion. However, because I'm paranoid, let me mention an issue in passing without any reason to believe that it is a problem in practice. For SMTP (and at least some other applications) there has always been a question about what to do with DNS queries in mixed IPv4 and IPv6 environments when the application wants to get both sets of addresses. I vaguely remember an idea about a query type of ADDEESS (or equivalent) that would return both A and RRs but, as far as I know, it didn't go anywhere. If there are best practices recommendations for applications writers in this area, I don't think they have been widely disseminated in the applications development community. The poor bewildered application author then has two choices, both of which appear to be rational. One is to issue two queries, one for A RRs and one for , and then sort things out in the application. The other is to issue an ANY query and sort the relevant information out from it. I at least superficially understand the problems with the latter and you obviously understand them much better. But, should an application writer make that choice (and, again, clear advice has not been broadly disseminated), a query for the root does get back address records. It is probably sensible to conclude that the number of implementations that are that stupid doesn't make the issue worth worrying about but that should be your conclusion, not mine, because I am obviously out of my depth here. john ___ 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 Friday, July 18, 2014 06:46 -0700 Paul Vixie p...@redbarn.org wrote: ... There are no addresses associated with the root, so the mail server will immediately report a delivery error. RFC 5321 section 5.1 paragraph 2 final sentence. The SMTP server will not try to connect to the root name servers, as your message suggested. true as stated. what's unstated here is that every SMTP sender who encounters such an MX without understanding its new meaning will do two or three lookups: . MX, [. ,] and . A. if they are behind an RDNS that doesn't do negative caching (and there are many, though none of them are open source; the open source RDNS servers do negative caching right) then these two or three queries will flow through to the authority servers for . which is to say the root name servers. Paul, Thanks. I obviously got the question wrong but, if it accidentally called attention to an issue that deserves even minimal consideration, I don't mind looking and feeling stupid. I obviously knew about the multiple queries but, by thinking about this from an SMTP context, was more concerned about the connection and queuing part of the problem. FWIW, many SMTP servers will deal with a negative answer from a DNS query by queuing the message (for the historical reason that a DNS change might not yet have caught up with the server queried). While the port 25 issue that I incorrectly focused on will not arise, the two or three queries you mention might, depending on the behavior of the resolver on which that SMTP server calls, be repeated at each queue retry interval. Again, I'm not competent to evaluate whether that is an issue or not. thanks again, john p.s. Just one or two lookups against the root. The sequence would be an MX lookup for the putative mail delivery domain (which should not affect the root servers), then . A and, optionally, . , in either order. While some implementations have historically done it, SMTP (at least as of RFC 5321) forbids doing an MX lookup on the information obtained from the DATA of a prior MX query. ___ 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
Paul Vixie p...@redbarn.org wrote: what's unstated here is that every SMTP sender who encounters such an MX without understanding its new meaning will do two or three lookups: . MX, No, MTAs do not look up MX records for MX targets. [. ,] and . A. But they might do these lookups, yes. If this is a worry for the root server operators (but I thought they had said in the past that it doesn't pose a problem) then the draft could specify a canonical address-less domain lower down the hierarchy, e.g. empty.as112.arpa (making use of the AS112 DNAME proposal). Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Plymouth: South 4 or 5, becoming variable 3 or 4. Slight or moderate. Rain or thundery showers. Good, occasionally 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 Jul 18, 2014, at 10:18 AM, Tony Finch d...@dotat.at wrote: Paul Vixie p...@redbarn.org wrote: what's unstated here is that every SMTP sender who encounters such an MX without understanding its new meaning will do two or three lookups: . MX, No, MTAs do not look up MX records for MX targets. [. ,] and . A. But they might do these lookups, yes. If this is a worry for the root server operators (but I thought they had said in the past that it doesn't pose a problem) then the draft could specify a canonical address-less domain lower down the hierarchy, e.g. empty.as112.arpa (making use of the AS112 DNAME proposal). Tony. - Many years ago Joe Abley and I suggested to create a special name for exactly this purpose a name that was guaranteed to never exist in the DNS thus the first lookup would always return NXDOMAIN thus the A+ lookups would never take place. http://tools.ietf.org/html/draft-jabley-sink-arpa-03 Olafur ___ 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
Many years ago Joe Abley and I suggested to create a special name for exactly this purpose a name that was guaranteed to never exist in the DNS thus the first lookup would always return NXDOMAIN thus the A+ lookups would never take place. http://tools.ietf.org/html/draft-jabley-sink-arpa-03 While I don't think it's relevant for this application, isn't that what RFC 6761 defines invalid to be? R's, John ___ 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 Jul 18, 2014, at 10:52 AM, John Levine jo...@taugh.com wrote: Many years ago Joe Abley and I suggested to create a special name for exactly this purpose a name that was guaranteed to never exist in the DNS thus the first lookup would always return NXDOMAIN thus the A+ lookups would never take place. http://tools.ietf.org/html/draft-jabley-sink-arpa-03 While I don't think it's relevant for this application, isn't that what RFC 6761 defines invalid to be? R's, John John, I think it would be great to have this document use “no-mail.invalid.” as the domain name rather than “.” in the MX record i.e. foo.bar.example MX 0 no-mail.invalid. But this is just a question of preference and installed base. Olafur ___ 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
Olafur Gudmundsson o...@ogud.com wrote: I think it would be great to have this document use “no-mail.invalid.” as the domain name rather than “.” in the MX record I don't think this would help. It would be different from what existing code recognizes and it would not divert the unwanted A+ queries away from the root name servers. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: West or southwest 4 or 5. Slight or moderate. Thundery showers in north. Good, occasionally poor in north.___ 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
I think it would be great to have this document use ?no-mail.invalid.? as the domain name rather than ?.? in the MX record i.e. foo.bar.example MX 0 no-mail.invalid. But this is just a question of preference and installed base. The aspirations of this document were far more modest than people seem to think. The original intent was to merely document a relatively standard operating procedure that mail admins routinely deploying. Up to that point it was trade-craft that sometimes surprised and confused new mail admins. We wanted to reduce that surprise and confusion. Nothing more. There was no original intent to try and change the practice nor to pass judgment on it. It was deemed that that would be covered by some future activity if warranted. Maybe NULLMX considered harmful if enough IETF wonks were keen on an admonition or driving an alternative. It's been nearly ten years since the original draft was posted, and it has travelled just about the full length of the IETF digestive tract. I can readily understand why the original goal may no longer be apparent. Importantly, in the intervening decade there has been zero evidence of sufficient energy to pursue alternatives, yet alone pursue them to completion. And of course the practice has become far more entrenched since then. I encourage folk to consider the doc in that context if they can. Mark. ___ 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
(copying John Levine given his recent summary on the IETF list as well as his co-author role) --On Friday, July 18, 2014 10:36 -0400 Olafur Gudmundsson o...@ogud.com wrote: If this is a worry for the root server operators (but I thought they had said in the past that it doesn't pose a problem) then the draft could specify a canonical address-less domain lower down the hierarchy, e.g. empty.as112.arpa (making use of the AS112 DNAME proposal). ... Many years ago Joe Abley and I suggested to create a special name for exactly this purpose a name that was guaranteed to never exist in the DNS thus the first lookup would always return NXDOMAIN thus the A+ lookups would never take place. http://tools.ietf.org/html/draft-jabley-sink-arpa-03 One more general observation and then I'm going to stop and leave this part of the issue to you folks. I believe there is fairly general (if still a bit rough) consensus in the email community that having some clear, DNS-based, way for a system to indicate that it does not accept email.Long ago, there was some hope that WKS records would solve that problem (and others like it), but we know how that worked out. Today's problem, IMO, is that, while there is little debate about DNS-based solution, or even DNS-based solution involving something special in the relevant MX record, I haven't seen a careful analysis by DBS experts on which of several DNS approaches have the least bad operational properties. If a particular SMTP implementation is aware of and follows the spec, almost any consensus indicator that doesn't conflict with other things should be fine -- ., ***, a special name in example.com or example.net, the proposal above, or something else, because there will be a string compare within the SMTP server and no lookups will be done. Since SMTP prohibits non-ASCII domain names, one might even consider something Like фиктивный.example.com or 虚假.example.com (literally, not as IDNA A-labels) which would cause many SMTP servers to do something nasty that does not involve the DNS. DATA containing . has the advantage of already being deployed, so anything else has to offer enough marginal value to overcome the assumptions that go with existing practice. But, modulo that issue, I don't think the SMTP community really cares what the string is as long as there is a string and a mechanism (Tony and others have said as much). The only issue that is, IMO, really important is with side-effects or damage caused by SMTP implementations that do not know about the convention or conform to the spec. They will certainly do lookups; how far they will get and whether they will requeue and try again depends somewhat on the string chosen and, modulo the observation about non-ASCII bogus strings, that is your area of expertise and not mine (or that of the AppsAWG). Given that the IETF used to pride itself on the application and quality of cross-area review, I think it is desirable and appropriate that the DNS community generally, and DNSOP in particular, weigh in on the string. I'd be happiest, and I'm confident that John L would be too, if the answer was any of * Just fine, . is no problem * Ok, . isn't likely to cause enough of an incremental problem to be worth worrying about. * We really wish you had asked ten years ago, but don't see . as causing enough of an incremental problem to be worth the difficulties associated with getting existing implementations to change their ways. But, again in the spirit of cross-area review, I'd really like it --and, as someone who periodically plays email expert on television, be a lot more comfortable-- if DNSOP had enough of a discussion to advise on this. I would hope that, if the advice were use a different string, preferable whatever, because... the IESG and the advocates of no mail received here indicator MXs would pay careful attention. And I'd like to see the spec reflect the analysis, if only in an appendix, which may require someone on the DNSOP list to help John L with text. But that is, as always, secondary to getting the spec, protocol, and operational issues right. john ___ 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
Today's problem, IMO, is that, while there is little debate about DNS-based solution, or even DNS-based solution involving something special in the relevant MX record, I haven't seen a careful analysis by DNS experts on which of several DNS approaches have the least bad operational properties. But, John, this is the one that's implemented in many popular MTAs, has been in daily use for the better part of a decade, and has no observed issues at all that I ever heard of. No doubt it sends some traffic to the root servers, but have any root server surveys ever even mentioned A or query traffic to . ? I can sorta kinda see not wanting to bless it in an RFC, but if we tell people to do something different, we'll just look ever more out of touch and they'll ignore us. Again. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ 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
John C Klensin john-i...@jck.com wrote: If a particular SMTP implementation is aware of and follows the spec, almost any consensus indicator that doesn't conflict with other things should be fine -- There are actually more constraints than you imply in your message. . Has the advantage of being implemented and deployed. Has the disadvantage of directing useless queries to the root name servers from MTAs that do not understand null MX records. *** MX target names should obey the LDH host name rules. You won't be able to enter this target into many DNS admin tools since they enforce LDH syntax. Some nameservers (e.g. BIND) will by default refuse to load a zone with a non-hostname MX target. This loses the advantages of a . target and fails to keep useless queries away from the root name servers. a special name in example.com or example.net, These domains are reserved for use in examples, not for production purposes. Are their name servers scaled up enough to handle stray queries from MTAs that don't understand null MX records? This question applies to any non-. target. The reason I suggested using AS112 was because it is designed for sinking unwanted queries that should not have leaked out in the first place. But I still prefer to stick with .. Since SMTP prohibits non-ASCII domain names, one might even consider something Like фиктивный.example.com or 虚假.example.com (literally, not as IDNA A-labels) which would cause many SMTP servers to do something nasty that does not involve the DNS. You are muddling up the IDNA layers here. The MX target comes from the DNS so if you try to put an IDNA name there it has to be encoded as an A-label before you put it in the DNS. If you try hard you can put un-encoded UTF-8 in the DNS, but then it would violate the hostname rules in a similar way to ***. It is likely that there are MTAs which do not check that MX targets actually obey hostname syntax, so this kind of hack is not going to reliably suppress lookups. They will certainly do lookups; how far they will get and whether they will requeue and try again depends somewhat on the string chosen I think it depends more on the MTA's and/or postmaster's attitude to DNS misconfiguration. Some are quicker to permfail than others. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Irish Sea: South or southeast 4 or 5, becoming variable 3 or 4. Moderate becoming slight. Rain or thundery showers, fog patches. 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 Friday, July 18, 2014 14:59 -0400 John R Levine jo...@taugh.com wrote: Today's problem, IMO, is that, while there is little debate about DNS-based solution, or even DNS-based solution involving something special in the relevant MX record, I haven't seen a careful analysis by DNS experts on which of several DNS approaches have the least bad operational properties. But, John, this is the one that's implemented in many popular MTAs, has been in daily use for the better part of a decade, and has no observed issues at all that I ever heard of. No doubt it sends some traffic to the root servers, but have any root server surveys ever even mentioned A or query traffic to . ? If you head read all of my note, you would have noticed that I expressed a strong preference for staying with MX . unless there were compelling reasons for doing something else. Compelling is a pretty high bar, but I think we need to ask and then listen. Also see below. As to no observed issues and indications of support in the many popular MTAs you have cited elsewhere, I think counting SMTP implementations is essentially bogus for reasons discussed (and claims made) in another thread on the IETF list. For those with the patience for the analysis, see [1] below. More relevant, I think, is that the deployment scale for this convention has nothing to do with how many SMTP servers implement it -- whether they do by string matching (also see below) or by giving a just stop here interpretation to certain types of DNS responses to lookup of MS DATA field contents. If no one created an MX . entry, then the number or types of servers who were prepared to deal with one in a special way would be completely irrelevant and the number of queries to the root would be zero. Now we both know that there are a bunch of MX . records out there. I assume the number is not very large compared to the total number of nodes in the DNS that own address records or even that number less the number of nodes who have MX records that point to SMTP servers. But the load on the root as the result of this convention (whether approved by the IETF or not) is, unless my brain is completely not working today, dependent on how often such records are encountered less the number of systems that trap the . convention locally. If the reason for asking for IETF approval is to encourage more nodes to be associated with these records (otherwise, you presumably wouldn't be looking for standards track) then more MX . entries are likely to result in more DNS queries -- how many more is, I believe, anyone's guess although I discuss some parameters below. Part of the issue here is an SMTP subtlety (or perhaps an RFC 5321 glitch). Your spec says (Section 3) The DNS root is not a valid host name, so a NULL MX record can not be confused with an ordinary MX record. That is clearly true. But, while an SMTP implementation could invoke the operational necessity provision of 5321 and make a string comparison check rather than sending a query to the root, SMTP does not require that the DATA associated with an MX record pass SMTP tests of valid host name (in SMTP a rather restrictive bit of local syntax); it basically requires that whatever is out there be looked up, with validity (getting back an address record) depending on what the DNS has to say (see 5321 Section 5.1) So, again with the stipulation that I may still not fully understand the issues here, I'd look, not at numbers of SMTP server implementations, or even the amount of traffic they might carry, but the number of MX RRs with . in the DATA. I'd assume that number would grow significantly and asymptotically after this specification is approved and more operators install the records and then with the growth in the Internet (or the DNS). The actual number of queries would depend on the subset of those nodes that were hit, either intentionally or by mistake. I don't think we have any way to estimate that. In any event, if one believes in Internet growth and that don't send me mail MX records are a good idea, there will be a lot more of them in the future, maybe enough to justify a change now if one is otherwise appropriate (or maybe not). My apologies for not thinking of it sooner but, if I were worried about DNS root server impacts (email messaging with mistakes about domains may be such a small percentage of traffic to not count) or even unnecessary DNS traffic minimization more generally, I'd recommend that this new specification explicitly update Section 5.1 of RFC 5321 to require that DNS servers make a string-comparison test against . (or whatever the string turns out to be) and stop if it is found rather than doing DNS lookups on whatever is in the data field. As an alternative, 5321 could be updated to require checking the contents of MX DATA against the SMTP mailbox domain rules. Neither would affect anything that exists today that is reasonable, but they would move that check from
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 Friday, July 18, 2014 20:39 +0100 Tony Finch d...@dotat.at wrote: John C Klensin john-i...@jck.com wrote: If a particular SMTP implementation is aware of and follows the spec, almost any consensus indicator that doesn't conflict with other things should be fine -- There are actually more constraints than you imply in your message. Yes, almost certainly. . Has the advantage of being implemented and deployed. Has the disadvantage of directing useless queries to the root name servers from MTAs that do not understand null MX records. *** MX target names should obey the LDH host name rules. I completely agree, but SMTP imposes no such requirement. You won't be able to enter this target into many DNS admin tools since they enforce LDH syntax. Some nameservers (e.g. BIND) will by default refuse to load a zone with a non-hostname MX target. Does that imply that this spec should contain a warning that loading one of these null MX records may require a configuration change in one's nameserver? Just asking. This loses the advantages of a . target and fails to keep useless queries away from the root name servers. a special name in example.com or example.net, These domains are reserved for use in examples, not for production purposes. Are their name servers scaled up enough to handle stray queries from MTAs that don't understand null MX records? Yep. Sorry for not selecting a better example, but I hope the point was clear. This question applies to any non-. target. The reason I suggested using AS112 was because it is designed for sinking unwanted queries that should not have leaked out in the first place. But I still prefer to stick with .. Ok, thanks for clarifying. Since SMTP prohibits non-ASCII domain names, one might even consider something Like фиктивный.example.com or 虚假.example.com (literally, not as IDNA A-labels) which would cause many SMTP servers to do something nasty that does not involve the DNS. You are muddling up the IDNA layers here. The MX target comes from the DNS so if you try to put an IDNA name there it has to be encoded as an A-label before you put it in the DNS. If you try hard you can put un-encoded UTF-8 in the DNS, but then it would violate the hostname rules in a similar way to ***. I'm actually not... and sorry if I wasn't clear. Because SMTP doesn't impose any restrictions on what it can pick up from MX DATA (presumably the only limits are those imposed by 2181) and knows nothing about IDNA, un-encoded UTF-8 (or, for that matter, un-encoded UTF16 or something else as long as it is within the 64 byte label limit, is just meaningless trash -- far further up the trash scale than **. If an implementation chooses to apply host name checks (or SMTP mailbox domain name validity checks) that seems wise to me, but goes beyond what SMTP requires. It is likely that there are MTAs which do not check that MX targets actually obey hostname syntax, so this kind of hack is not going to reliably suppress lookups. Exactly. They are different examples of guaranteed bogus strings; they don't help a bit with the query problem. If we really want help with the query problem, we need to update SMTP (see previous over-long note to DNSOP, which I'll forward to you under separate cover. They will certainly do lookups; how far they will get and whether they will requeue and try again depends somewhat on the string chosen I think it depends more on the MTA's and/or postmaster's attitude to DNS misconfiguration. Some are quicker to permfail than others. Yep, And that is independent of whether we agree about what constitutes DNS misconfiguration. Had you said misconfiguration, abuse, or stupidity, we'd probably agree. :-) john ___ 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
John C Klensin john-i...@jck.com wrote: MX target names should obey the LDH host name rules. I completely agree, but SMTP imposes no such requirement. RFC 974 specifies that the target of an MX record is a host name. You won't be able to enter [***] into many DNS admin tools since they enforce LDH syntax. Some nameservers (e.g. BIND) will by default refuse to load a zone with a non-hostname MX target. Does that imply that this spec should contain a warning that loading one of these null MX records may require a configuration change in one's nameserver? No, because . doesn't violate LDH syntax. (What admin GUIs do is another matter...) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Humber, Thames: Mainly southeast 4 or 5, increasing 6 at times. Slight or moderate. Thundery showers. Good, occasionally 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
John C Klensin john-i...@jck.com wrote: To the contrary, I think the problem here (if there is one) is that these types of ideas are being invented, specified through formal or informal private discussions, deployed, and then brought to the IETF for standardization. The null MX record is simply re-using the existing logic for null SRV records, so the design already has IETF approval. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ East Sole, Lundy, Fastnet: Southerly becoming variable 3 or 4. Slight or moderate. Thundery showers. Good, occasionally 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
(Warning to DNSOP and IESG -- this response is going to descend quickly into SMTP esoterica and is probably safe to ignore from a DNS perspective) --On Friday, July 18, 2014 22:39 +0100 Tony Finch d...@dotat.at wrote: John C Klensin john-i...@jck.com wrote: MX target names should obey the LDH host name rules. I completely agree, but SMTP imposes no such requirement. RFC 974 specifies that the target of an MX record is a host name. And so? RFC 2821 obsoleted 974. As far as I can tell, it says nothing at all about the DATA field in an MX record, leaving pulling that information out and looking it up in the DNS to be inferred from context and a parenthetical comment (perhaps taken from the preferred MX record). It does use the term host addresses and destination host, but in a too-informal context to assume that people would infer host name (aside: whatever that means) in the DNS sense. After 14+ years, I no longer remember and cannot reconstruct whether that was a DRUMS screwup or mine although the WG is ultimately responsible for not reviewing carefully enough. When RFC 5321 was done, we obviously knew there was a problem with the 2821 text because its text improves on the situation. The pre-5321 change log doesn't say much that sheds light on the change, other than saying that the description of MX handing was changed in -10 (one of several post-Last-Call versions). The relevant section is more clear and it does explicitly say the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or RR). But that is it: domain name. One can read that as an invocation of the discussion in Section 2.3.5 but that isn't the only possible reading. The section invokes 1035 and a sequence of letters, digits, and hyphens drawn from the ASCII character set. The following sentence reads Domain names are used as names of hosts and of other entities in the domain name hierarchy. so, while 2.3.5 (if one believes that the text in 5.1 invokes it) requires LDH, it does not require a host name.If one doesn't believe that 2.3,5 is invoked, then a domain name is presumably just an FQDN conforming to 1034/1035 as interpreted by 2181). There is, fwiw, some additional test in 2.3.5 that further muddies the waters. That is definitely not a good example of clarity or precision. Mea culpa, with or without comments about quality of review. I have tightened things up in the 5321bis editing copy (yes, there is such a thing). ... Does that imply that this spec should contain a warning that loading one of these null MX records may require a configuration change in one's nameserver? No, because . doesn't violate LDH syntax. (What admin GUIs do is another matter...) Those admin GUIs or text input converters were what I was concerned about (should have said nameserver configuration interface or words to that effect). Your call (and John L.'s). john ___ 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 alpine.lsu.2.00.1407182019070.28...@hermes-1.csi.cam.ac.uk, Tony F inch writes: John C Klensin john-i...@jck.com wrote: If a particular SMTP implementation is aware of and follows the spec, almost any consensus indicator that doesn't conflict with other things should be fine -- There are actually more constraints than you imply in your message. . Has the advantage of being implemented and deployed. Has the disadvantage of directing useless queries to the root name servers from MTAs that do not understand null MX records. *** MX target names should obey the LDH host name rules. You won't be able to enter this target into many DNS admin tools since they enforce LDH syntax. Some nameservers (e.g. BIND) will by default refuse to load a zone with a non-hostname MX target. This loses the advantages of a . target and fails to keep useless queries away from the root name servers. . is a place holder exception. Below is a minimal zone with a MX with all the domains set to .. Named will load MX 0 . fine. . prevents lots of the internal checks at load time from triggering. % named-checkzone zone zone zone:1: no TTL specified; using SOA MINTTL instead zone zone/IN: loaded serial 0 OK % cat zone @ SOA . . 0 0 0 0 0 @ NS . @ MX 0 . % MX 0 . is also consistent with SRV 0 0 0 . which is documented. no-mail.invalid however will elicit a warning / failure depending upon what the error level is set to. Named-checkzone looks up every MX target and check for A or records with the exception of .. It also checks that they are syntactically valid hostnames. It also tries to determine if a IPv4 address has been used instead of a hostname by mistake. % named-checkzone zone zone zone:1: no TTL specified; using SOA MINTTL instead zone zone/IN: zone/MX 'no-mail.invalid' (out of zone) has no addresses records (A or ) zone zone/IN: loaded serial 0 OK % cat zone @ SOA . . 0 0 0 0 0 @ NS . @ MX 0 no-mail.invalid. % . is a really good exception marker. It is also the minimal exception marker we can have. a special name in example.com or example.net, These domains are reserved for use in examples, not for production purposes. Are their name servers scaled up enough to handle stray queries from MTAs that don't understand null MX records? This question applies to any non-. target. The reason I suggested using AS112 was because it is designed for sinking unwanted queries that should not have leaked out in the first place. But I still prefer to stick with .. Since SMTP prohibits non-ASCII domain names, one might even consider something Like =D1=84=D0=B8=D0=BA=D1=82=D0=B8=D0=B2=D0=BD=D1=8B=D0=B9.ex= ample.com or =E8=99=9A=E5=81=87.example.com (literally, not as IDNA A-labels) which would cause many SMTP servers to do something nasty that does not involve the DNS. You are muddling up the IDNA layers here. The MX target comes from the DNS so if you try to put an IDNA name there it has to be encoded as an A-label before you put it in the DNS. If you try hard you can put un-encoded UTF-8 in the DNS, but then it would violate the hostname rules in a similar way to ***. It is likely that there are MTAs which do not check that MX targets actually obey hostname syntax, so this kind of hack is not going to reliably suppress lookups. They will certainly do lookups; how far they will get and whether they will requeue and try again depends somewhat on the string chosen I think it depends more on the MTA's and/or postmaster's attitude to DNS misconfiguration. Some are quicker to permfail than others. Tony. --=20 f.anthony.n.finch d...@dotat.at http://dotat.at/ Irish Sea: South or southeast 4 or 5, becoming variable 3 or 4. Moderate becoming slight. Rain or thundery showers, fog patches. Moderate or good, occasionally very poor. --1870869256-999632820-1405712346=:28941 Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop --1870869256-999632820-1405712346=:28941-- -- 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
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
The target us a hostname (RFC 1035). 3.3.9. MX RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFERENCE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / EXCHANGE/ / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: PREFERENCE A 16 bit integer which specifies the preference given to this RR among others at the same owner. Lower values are preferred. EXCHANGEA domain-name which specifies a host willing to act as a mail exchange for the owner name. In message d6cbb305b5bc2818e7b34...@jck-hp8200.jck.com, John C Klensin writes : (Warning to DNSOP and IESG -- this response is going to descend quickly into SMTP esoterica and is probably safe to ignore from a DNS perspective) --On Friday, July 18, 2014 22:39 +0100 Tony Finch d...@dotat.at wrote: John C Klensin john-i...@jck.com wrote: MX target names should obey the LDH host name rules. I completely agree, but SMTP imposes no such requirement. RFC 974 specifies that the target of an MX record is a host name. And so? RFC 2821 obsoleted 974. As far as I can tell, it says nothing at all about the DATA field in an MX record, leaving pulling that information out and looking it up in the DNS to be inferred from context and a parenthetical comment (perhaps taken from the preferred MX record). It does use the term host addresses and destination host, but in a too-informal context to assume that people would infer host name (aside: whatever that means) in the DNS sense. After 14+ years, I no longer remember and cannot reconstruct whether that was a DRUMS screwup or mine although the WG is ultimately responsible for not reviewing carefully enough. When RFC 5321 was done, we obviously knew there was a problem with the 2821 text because its text improves on the situation. The pre-5321 change log doesn't say much that sheds light on the change, other than saying that the description of MX handing was changed in -10 (one of several post-Last-Call versions). The relevant section is more clear and it does explicitly say the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or RR). But that is it: domain name. One can read that as an invocation of the discussion in Section 2.3.5 but that isn't the only possible reading. The section invokes 1035 and a sequence of letters, digits, and hyphens drawn from the ASCII character set. The following sentence reads Domain names are used as names of hosts and of other entities in the domain name hierarchy. so, while 2.3.5 (if one believes that the text in 5.1 invokes it) requires LDH, it does not require a host name.If one doesn't believe that 2.3,5 is invoked, then a domain name is presumably just an FQDN conforming to 1034/1035 as interpreted by 2181). There is, fwiw, some additional test in 2.3.5 that further muddies the waters. That is definitely not a good example of clarity or precision. Mea culpa, with or without comments about quality of review. I have tightened things up in the 5321bis editing copy (yes, there is such a thing). ... Does that imply that this spec should contain a warning that loading one of these null MX records may require a configuration change in one's nameserver? No, because . doesn't violate LDH syntax. (What admin GUIs do is another matter...) Those admin GUIs or text input converters were what I was concerned about (should have said nameserver configuration interface or words to that effect). Your call (and John L.'s). john ___ 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
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 Thursday, July 03, 2014 12:03 -0700 The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'A NULL MX Resource Record for Domains that Accept No Mail' draft-ietf-appsawg-nullmx-05.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2014-07-17. Hi. For a number of reasons, many of which have been identified by others, I find this draft and the actions it recommends distasteful. I see it as another step, albeit a small one, in the direction of prioritizing the prevention of unwanted messages or connections over successful delivery of legitimate messages. I continue to believe that prioritization is undesirable, at least without fundamentally converting the email infrastructure to an acknowledge on delivery because there is no expectation of successful deliveries one rather than the current protocols, which focus on notifications for non-delivery.That is not a strong technical objection and is definitely not intended to be an argument against publication if the IESG concludes that there is community consensus for doing this, especially since, of the changes that could be motivated as above, this is one of the more benign. Hope, it would be better if the specification were historically accurate and accurate about the protocols it cites. The last sentence of the second paragraph of Section 5 (Security Considerations) of the spec says: The normal way to send mail for which a sender wants no responses remains unchanged, by using an empty RFC5321.MailFrom address. First, two issues of terminology: (1) RFC 5321 does not contain or specify notations like RFC5321.MailFrom. That notation was introduced in RFC 5598, a document that was approved as Informational with a consensus that, IIR, included some significant desire that it not be normative or casually treated as normative. If this specification wants to use that notation, that is fine. But it should include an explicit note to that effect in its introduction or a Terminology section, not bury a (see [RFC5598] for the definitions of these terms) reference in a parenthetical note in Section 4.1 and then expect readers who are looking specifically at other sections to pick up on it. I believe that the RFC Editor's principle is that, if particular terminology is needed to correctly understand a specification, then the reference to the document that defines that terminology is normative. In this particular case, it seems inconsistent to consider 2119 normative and 5598 informative since both are used to define terminology without which the document cannot be correctly understood. (2) Second, RFC 5321 does not contain a concept that it calls an empty address. The terminology it does use is null reverse-path (See RFC 5321, Section 3.7). Subject to the above, if the authors want to say null address in RFC5321.MailFrom, I don't think that is sufficiently confusing to be a problem. But empty address could be construed as MAIL FROM: in the envelope with nothing following it, and that would be bad news. More important, however, RFC 5321 specifies the use of a null reverse path only for delivery failure and status notifications and message disposition notifications (see Section 4.5.5 of RFC 5321) and constrains the recipient address to be used. That section also says All other types of messages (i.e., any message which is not required by a Standards-Track RFC to have a null reverse-path) SHOULD be sent with a valid, non-null reverse-path. So. there isn't any The normal way to send mail for which a sender wants no responses -- RFC 5321 and other specs significantly constrain the cases in which null reverse-paths may be used. If this specification intends that notifications that are generated in response to a null MX record, then that needs to be made an explicit requirement to conform with the language of RFC 5321. Some additional observations that suggest this document needs additional work before approval, probably with an intervening additional Last Call: (a) Sloppy DNS terminology has been the source of many problems (see recent discussions of dotless domains in draft-klensin-dotless-terminology-harmful; hostname used to describe a DNS entry that contains an address RR, a DNS entry where the owner also owns at least one address RR, and the first (leftmost) component of an FQDN (with additional ambiguity as to whether a zone break is implied); and considerable confusion about terms like resolver. Whether the IETF steps forward to try to clean up previous messes or not, it certainly should not countenance making things worse. Specifically referring to Section 3 of draft-ietf-appsawg-nullmx-05, there is not
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 53c8394a.6080...@dcrocker.net, Dave Crocker writes: Specifically referring to Section 3 of draft-ietf-appsawg-nullmx-05, there is not such thing as a NULL MX Resource Record. There is only an MX Resource Record that this specification proposes to use with a convention involving specific content in the DATA. One could call that many things, but NULL MX Resource Record isn't one of them. By my reading of that section, it is defining the term, if only by virtue of the way it is used in the name of that section. Perhaps your confusion would be resolved if the term had a comma in it, so: NULL, MX Record? In other words, NULL is an adjective within the term. If you would prefer a different term, please suggest one. A better description of the record is No Service MX Record or No Service Offered MX Record. Mark -- 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
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 Thu, Jul 17, 2014 at 10:39 AM, John C Klensin john-i...@jck.com wrote: (d) It seems to me that the cases this proposal addresses are special enough that a dedicated Extended Status Code would be in order. Instead, the document specifies the highly generic 5.1.2 (even those the RFC 3463 definition of X.1.2 includes incapable of accepting mail and invalid for mail (which don't mean quite the same thing). Especially since there is not an easily-located WG discussion, the document should at least explain its choice. If consensus is to register a new code as suggested, one could certainly help himself to a cloning of the useful parts of draft-ietf-appsawg-email-auth-codes, now in Last Call. -MSK ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
