Re: [ietf-dkim] ISSUE 1573: Modify ADSP Lookup Procedure
John Levine wrote: t hangText="Note: " The results from DNS queries that are intended to validate a domain name unavoidably approximate the set of Author Domains that can appear in legitimate email. I'd like to suggest that we use a different word than "approximate" in the above discussion and in the Levine draft. FWIW, I'm not thrilled with my suggestion either. I wasn't thrilled by "approximate", but I couldn't think of a word that more accurately captured what I was trying to say. "Approximate" may give the impression that the error may be in either direction, ... Depending on local configurations, there might be. My MTA is set up so that it recognizes domains for local hackery that aren't visible in the DNS. I realize this is out of the scope of 2821, but my thought was that there's nothing short of trying to deliver the mail and seeing what bounces to accurately tell what's valid. Surely we don't need to capture local hacks in the draft. I suppose that "overapproximate" would be OK within the constraints of 2821. I can definitely live with "approximate". I don't think "overapproximate" is even a word, or if it is, it may mean something else so let's avoid that one. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Domain Existence Check and Erroneous Abstract
On Thu, 05 Jun 2008 19:41:34 +0100, Douglas Otis [EMAIL PROTECTED] wrote: On Jun 5, 2008, at 4:23 AM, Charles Lindsey wrote: Then please could you provide us with a full example that could actually happen, starting from an X.400 email that somehow got tranformed into an RFC 2822 object that contained unresolvable domains, and which yet managed to acquire a DKIM signature (not necessarily by anything in the From header) and was also capable of being replied to by its recipient. If such a beast can exist, then we need to take note of it, but i am not aware that it could exist. Many companies use MS Exchange rather than normal SMTP servers. MS Exchange permits creation of mail addresses unreachable by SMTP, since these domains may only exist through an internal X.400 assignment. While some companies find this a desirable feature, it is often a PITA for users of this service. While a parent domain may wish to assert ADSP practices, MS Exchange related email sub-domains can be created for various purposes without publishing _any_ record within DNS. The MUA will therefore receive a mixture of SMTP and MS Exchange messages, but this would only create a problem with specific domains for users of the MS Exchange service. Will you please answer the question I asked, which was for an example of an actual message and how it would appear at various stages as it passed through a mail system from the point where it was originated (and hopefully signed) to the point where it needed to be verified. I have no idea what MS Exchange does, and after reading your gobbledegook I am still no wiser. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email:[EMAIL PROTECTED]: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE 1573: Modify ADSP Lookup Procedure
Note: The results from DNS queries that are intended to validate a domain name unavoidably approximate the set of Author Domains that can appear in legitimate email. ... I'd like to suggest that we use a different word than approximate in the above discussion and in the Levine draft. ... I suppose that overapproximate would be OK within the constraints of 2821. ... I can definitely live with approximate.nbsp; I don't think overapproximate is even a word, or if it is, it may mean something else so let's avoid that one. This (over)approximation issue is confusing, and it can be eliminated with a more precise definition of what domains are in scope for ADSP. After writing the text that evolved into what's in the Levine draft, my thoughts have evolved towards the following: ADSP as defined in [ADSP] is bound to DNS. For this reason, ADSP is applicable only to Author Domains with explicit ADSP DNS records. The handling of Author Domains without explicit ADSP DNS records is outside the scope of [ADSP]. However, attackers may use out-of-scope Author Domains in an attempt to sidestep an organization's explicit ADSP policy statements that some or all email is signed. For this reason receivers MUST handle out-of-scope Author Domains appropriately. The ADSP scope algorithm then simplifies into: - Receivers MUST look up the DNS MX record for the Author Domain. If the lookup completes with error code 3 (NXDOMAIN) the Author Domain does not exist in DNS, and therefore it is not possible to publish an ADSP record for the Author Domain. Receivers MUST treat such out-of-scope Author Domains as an error. - Otherwise, the Author Domain exists in DNS, but the organization publishes no ADSP record for the domain. Receivers SHOULD resolve the domain as required by [SMTP]. If the domain does not resolve, receivers SHOULD treat such out-of-scope Author Domains as an error. - Otherwise, receivers MAY treat such out-of-scope Author Domains as if the organization had published an explicit ADSP policy statement of unknown. So the algorithm simplifies into: MUST do NXDOMAIN test for MX lookup, SHOULD resolve the domain per [SMTP]. Whether it's SHOULD or MAY (or even not at all) depends on a trade-off between the predictability of receiver behavior against typical overhead and the potential for abuse in packet multiplication attacks. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE 1573: Modify ADSP Lookup Procedure
Jim Fenton wrote: I can definitely live with approximate. I don't think overapproximate is even a word, or if it is, it may mean something else so let's avoid that one. How about minimal approximation ? Proposed text: | A minimal approximation of a complete nomailfqdn check as | specified in [2821bis] section x.y is an NXDOMAIN (rcode 3) | result for a domain lookup, see [RFC 103?] section a.b. RFC 1034 or 1035, I'm too lazy to find the relevant sections. Frank ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
