Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
On Wed, 2008-04-30 at 19:54 -0400, Wietse Venema wrote: Dave Crocker: Arvel Hathcock wrote: I propose that the side advocating removal of the NXDOMAIN check agree to language which makes this step AT LEAST a SHOULD and preferably a MUST. Having the ADSP specification include normative text that calls for validating the From field domain name does two things: 1. Couples an entirely separate and more generally useful mechanism (checking domain name validity) to one that is considerably more limited (ADSP). 2. Modifies SMTP. (Yes, really.) Having non-normative text that describes it serves to promote the idea but not couple it with the fate of ADSP. Instead of discussing how many angels fit on a pinhead, I suggest that we do something sensible, like: ADSP is bound to DNS, and therefore it's defined only for author domains that exist in DNS. +1 -- :: Jeff Macdonald | Director of Messaging Technologies :: e-Dialog | [EMAIL PROTECTED] :: 131 Hartwell Ave. | Lexington, MA 02421 :: v: 781-372-1922 | f: 781-863-8118 :: www.e-dialog.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
Dave Crocker wrote: Having the ADSP specification include normative text that calls for validating the From field domain name does two things: 1. Couples an entirely separate and more generally useful mechanism (checking domain name validity) to one that is considerably more limited (ADSP). I could easily put this another way: we are making use of a DNS facility. Coupling usually implies some sort of bidirectional dependency. There is none here. 2. Modifies SMTP. (Yes, really.) Having non-normative text that describes it serves to promote the idea but not couple it with the fate of ADSP. Perhaps so, but since everyone has agreed this is a good idea, what is the harm? Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
Date: Wed, 30 Apr 2008 15:12:34 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?) Arvel Hathcock wrote: I propose that the side advocating removal of the NXDOMAIN check agree to language which makes this step AT LEAST a SHOULD and preferably a MUST. Having the ADSP specification include normative text that calls for validating the From field domain name does two things: 1. Couples an entirely separate and more generally useful mechanism (checking domain name validity) to one that is considerably more limited (ADSP). For reasons I have shared before I have to disagree. The check for domain existence is not unrelated. In short the check for domain existence tells you whether something is a D about which it is valid to search for a P. The fact that people may already be doing this elsewhere and that it is useful for other reasons doesn't have any impact on the fact that this check gives you a hard algorithmic boundary for what entitiies ADSP is intended to apply to. We have a specification that is currently intended to cover a narrow and well defined set of entities, that is domains, and a check to tell whether a given entity is such a thing. 2. Modifies SMTP. (Yes, really.) As I think has been pointed out before here is the definition of the domain portion of addr-spec from rfc2822. The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a host name or a mail exchanger name) as described in [STD3, STD13, STD14]. Wouldn't something have to exist to meet this specification? Or does the term Internet domain include things that don't exist but maybe could? Having non-normative text that describes it serves to promote the idea but not couple it with the fate of ADSP. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html _ Express yourself wherever you are. Mobilize! http://www.gowindowslive.com/Mobile/Landing/Messenger/Default.aspx?Locale=en-US?ocid=TAG_APRIL___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
Arvel Hathcock wrote: This is where we are at present on the NXDOMAIN issue I believe but others might have a different view. That's my impression, as well. What's the path towards settling this? I propose that the side advocating maintaining the NXDOMAIN check as an actual algorithmic step agree to remove this from the algorithm description in favor of placement somewhere else. I'd be happy with this if I knew where the somewhere else is. If there was a domain existence check somewhere else that we could reference, that's worth discussing. But I know of no such reference. The other question is what the existence check should consist of: check for an NXDOMAIN response or check for MX/A/ which more precisely defines mail domains? -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
Text which states that ADSP is to be applied only to Author Domains which _actually exist in DNS_ would suffice since there's only one way to determine whether that condition is meet. Sorry, to clarify, the one way I'm talking about is: doing a DNS lookup. I realize there are many different types of lookups (MX/A, etc) that _could_ be done. All we care is that one is performed so we have NXDOMAIN (or not). Arvel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
On May 1, 2008, at 3:16 PM, Arvel Hathcock wrote: The other question is what the existence check should consist of: check for an NXDOMAIN response or check for MX/A/ which more precisely defines mail domains? Needs to be NXDOMAIN I suspect to avoid the cry You're retasking records for what they weren't meant to do. When domain validity checks discover whether SMTP might be supported by the domain's DNS, MX and then A records could be queried without retasking their purpose. Not looking for _positive_ confirmation of possible SMTP support means empty nodes could be considered valid domains, which is wrong, problematic from the standpoint of depending upon negative results that might overlook local resolutions, and of course wasted overhead. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
On May 1, 2008, at 3:31 PM, Arvel Hathcock wrote: Text which states that ADSP is to be applied only to Author Domains which _actually exist in DNS_ would suffice since there's only one way to determine whether that condition is meet. Sorry, to clarify, the one way I'm talking about is: doing a DNS lookup. I realize there are many different types of lookups (MX/A, etc) that _could_ be done. All we care is that one is performed so we have NXDOMAIN (or not). Publishing ADSP should mandate MX records be published when the domain intends to receive email. By making this mandate, not finding an MX record will prevent subsequent transactions attempting to retrieve policy records. Such a convention reduces the amount of undesired traffic for domains not involved with SMTP. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
Arvel explained: The debate has shifted from outright hostility to any NXDOMAIN check at all (complete elimination of it in it's entirely) to just removing it from a required algorithmic step and instead referencing it non-normatively with some version of this is a good idea that you might want to think about if you're not already doing it. This is where we are at present on the NXDOMAIN issue I believe but others might have a different view. That's my impression, as well. What's the path towards settling this? -- J.D. Falk Receiver Products Return Path work with me! http://www.returnpath.net/careers/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
This is where we are at present on the NXDOMAIN issue I believe but others might have a different view. That's my impression, as well. What's the path towards settling this? I propose that the side advocating maintaining the NXDOMAIN check as an actual algorithmic step agree to remove this from the algorithm description in favor of placement somewhere else. I propose that the side advocating removal of the NXDOMAIN check agree to language which makes this step AT LEAST a SHOULD and preferably a MUST. This is a completely reasonable and sensible way to close the issue IMO. We are down to the bare-bones of what many of us are able to accept with regard to further fundamental changes. Unbelievable compromise has already been made and no side is getting all of what they want. We're now talking about trimming ADSP to the point of near uselessness. There's no more flesh we can carve from this pig and still make a sandwich. Arvel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
On Apr 30, 2008, at 3:01 PM, Arvel Hathcock wrote: This is where we are at present on the NXDOMAIN issue I believe but others might have a different view. That's my impression, as well. What's the path towards settling this? I propose that the side advocating maintaining the NXDOMAIN check as an actual algorithmic step agree to remove this from the algorithm description in favor of placement somewhere else. NXDOMAIN would remain a problem regardless where in the specification it is placed. : ( I propose that the side advocating removal of the NXDOMAIN check agree to language which makes this step AT LEAST a SHOULD and preferably a MUST. How about: Recipients SHOULD check for the existence of SMTP discovery records, to confirm absence of ADSP. ADSP MUST provide recipient value from their checks. This is a completely reasonable and sensible way to close the issue IMO. We are down to the bare-bones of what many of us are able to accept with regard to further fundamental changes. ADSP should declare protection for messages publicly exchanged over SMTP, instead of all public exchange protocols that might employ DKIM at some point in the future. The specification has failed to trim itself in a few important areas. ADSP should be limited to positive existence checks, and specific public exchange transports. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
So, I take this as a no to the compromise proposal (at least from one person). That's too bad. Having the ADSP specification include normative text that calls for validating the From field domain name does two things: 1. Couples an entirely separate and more generally useful mechanism (checking domain name validity) to one that is considerably more limited (ADSP). I believe that a normative reference would require that the result of an already widespread practice be part of an ADSP evaluation. Where the practice is not already extant, claimed compliance with ADSP could require it. That's all. 2. Modifies SMTP. (Yes, really.) I don't understand, please explain. This sounds new. Having non-normative text that describes it serves to promote the idea but not couple it with the fate of ADSP. Non-normative language leaves ADSP deployers in the dark about whether the protocol can be relied on because success would depend upon an optional NXDOMAIN check that some have, some don't, and none need perform. Since we know the protocol needs this in order to avoid being trivially defeated and since it has already been acknowledged as a common practice it seems inexcusable for an engineering team to make it an optional thing or to simply promote the idea. Perhaps we could get some other people to weigh in on this matter. Arvel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
Dave Crocker: Arvel Hathcock wrote: I propose that the side advocating removal of the NXDOMAIN check agree to language which makes this step AT LEAST a SHOULD and preferably a MUST. Having the ADSP specification include normative text that calls for validating the From field domain name does two things: 1. Couples an entirely separate and more generally useful mechanism (checking domain name validity) to one that is considerably more limited (ADSP). 2. Modifies SMTP. (Yes, really.) Having non-normative text that describes it serves to promote the idea but not couple it with the fate of ADSP. Instead of discussing how many angels fit on a pinhead, I suggest that we do something sensible, like: ADSP is bound to DNS, and therefore it's defined only for author domains that exist in DNS. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
On Wed, Apr 30, 2008 at 3:25 PM, J D Falk [EMAIL PROTECTED] wrote: Arvel explained: The debate has shifted from outright hostility to any NXDOMAIN check at all (complete elimination of it in it's entirely) to just removing it from a required algorithmic step and instead referencing it non-normatively with some version of this is a good idea that you might want to think about if you're not already doing it. This is where we are at present on the NXDOMAIN issue I believe but others might have a different view. That's my impression, as well. What's the path towards settling this? Vote? Survey? Regards, Al Iverson -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA Remove lists from my email address to reach me faster and directly. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
On Wed, Apr 30, 2008 at 6:49 PM, Arvel Hathcock [EMAIL PROTECTED] wrote: Having non-normative text that describes it serves to promote the idea but not couple it with the fate of ADSP. Non-normative language leaves ADSP deployers in the dark about whether the protocol can be relied on because success would depend upon an optional NXDOMAIN check that some have, some don't, and none need perform. Since we know the protocol needs this in order to avoid being trivially defeated and since it has already been acknowledged as a common practice it seems inexcusable for an engineering team to make it an optional thing or to simply promote the idea. Perhaps we could get some other people to weigh in on this matter. I think I agree with you. I am not understanding what is revolutionary about an NXDOMAIN check. I see sites rejecting mail based on NXDOMAIN currently, regularly. I would even dare to call this an observable best practice. I would need to hear more on how it modifies SMTP and/or turns the universe on its ear -- I'm not yet convinced that it is as earth shattering as described. Regards, Al Iverson -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA Remove lists from my email address to reach me faster and directly. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
Instead of discussing how many angels fit on a pinhead, I suggest that we do something sensible, like: ADSP is bound to DNS, and therefore it's defined only for author domains that exist in DNS. Excellent. Section 3.2 already lists the domain does not exist as a valid ADSP result. So we could add Wietse's text ADSP is bound to DNS and therefore is to be applied only to Author Domains which actually exist in DNS. as the first sentence of section 3 perhaps? Arvel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
On Apr 30, 2008, at 5:09 PM, Al Iverson wrote: I am not understanding what is revolutionary about an NXDOMAIN check. I see sites rejecting mail based on NXDOMAIN currently, regularly. I would even dare to call this an observable best practice. I would need to hear more on how it modifies SMTP and/or turns the universe on its ear -- I'm not yet convinced that it is as earth shattering as described. NXDOMAIN represents the DNS RCODE 3 Name Error response. This code is meaningful when retuned by an authoritative DNS server and represents a specific heuristic of DNS. For example, this code might occur when a referral at an existing domain name contains a CNAME that does not exist. Keep in mind, it is possible to resolve hostnames locally without dependence upon DNS. Resolving such SMTP clients locally might represent _crucial_ services expected to function even when DNS is unavailable. After all, DNS represents a potential target for DDoS attack. The specific use of NXDOMAIN as an ADSP compliance/acceptance test may interfere with alternative methods of resolving hostnames, whether or not DKIM or ADSP is used by the SMTP client's domain. : ( NXDOMAIN protection also fails when wildcards are used. In addition, NXDOMAIN requires ADSP records be placed at _every_ existing node, rather than just those potentially supporting SMTP. Clearly, knowing whether a domain might support SMTP offers far greater value than knowing a node exists but may contain no resources, or none related to SMTP. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
