On Jun 4, 2008, at 9:14 AM, Dave Crocker wrote: > > In the interest of accuracy: > > I have been probing some email receive-side folk, about their call- > back or verification steps like this that they conduct. Generally, > the range of tests is of these types. > > Unfortunately, it is rarely based on the rfc2822.From field. It > is, instead, typically based on rfc2821.mailfrom. > > So we need to be careful about assuming that any of these tests are > likely to be "free". In fact, one bit of feedback I got was > explicit about these additional tests as costing too much. They had > tried and found they added too much delay.
Dave, This touches a significant issue. The rfc2822.From fields may contain addresses that will _not_ resolve any DNS resource records for protocols other than SMTP. For example, Microsoft Exchange was initially based upon X.400 recommendations in the 1980s by the Consultative Committee of International Telephone and Telegraph (CCITT), now known as Telecommunications Standardization Sector of the International Telecommunication Union (ITU-T). As a result, use of X. 400 addresses means it is fairly common to find email-address domains that do not exist whatsoever within DNS. An NXDOMAIN result with respect to an X.400 MS Exchange email-address is completely meaningless. Although your attempt to better define the ADSP draft's abstract represents an improvement, this abstract still misses this extremely important point (made in the otis-dkim-adsp draft). While DKIM might be used by many different protocols, it is _not_ practical to offer protection based upon the use of DNS for non-public exchange protocols. Nor is it logical to assume that a domain will implement DKIM for _all_ exchange protocols, especially when DKIM becomes considered essential only for the public SMTP exchange. With respect to ADSP, the WG must stop pretending ADSP can apply to protocols as broadly as DKIM might. ADSP MUST be narrowly defined as only pertaining to SMTP message exchanges! Otherwise, ADSP becomes disruptive when misapplied at an MUA accepting messages carried over different protocols. MUAs might be able mitigate some disruption by making ADSP optional. The optional nature of ADSP could apply to all messages handled by the MUA, or more ideally, as an exception limited to specific email-address domains. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html