On Jun 5, 2008, at 2:41 PM, Damon wrote: > OK. Now that isn't going to happen. Let's be realistic. Anything > short of aliens landing in Miami is going to get something like this > into or out of Lotus Notes some time this century. (And sadly I am > being realistic here) > Saying that we ignore these systems because they haven't followed > the rules just disenfranchised a large enough piece of the pie for > this scheme to be called unworkable.
Precautions required for non-SMTP transport may involve the imposition of domain specific exceptions. In cases where there might be a mix of private/public name space, the exceptions would be only for a few specific domains. Such an effort does not seem impractical, especially when such domains are likely well known by the enterprise making use of non-SMTP transports. Domains desiring that their NNTP messages can carried over SMTP via a protocol gateway may find greater acceptance by accommodating SMTP responses against their domain. In most cases, this is likely already the case. Establishing provisions for such exceptions seems realistic. It would be true that without an exception provision, validating the absence of ADSP records may disrupt the exchange of non-SMTP messages, such as those for MS Exchange. However, validating the absence of ADSP records for a domain is: 1) not required. 2) not needed for private messages from known sources exchanged over non-SMTP transport. 3) likely already accommodated by SMTP as an alternative transport. This is not attempting to disenfranchise any non-SMTP transport. However, ADSP should be upfront about the potential disruption it may cause when provisions for exceptions are not available. A disruption of non-SMTP transport conversions will be caused when either validating the absence of ADSP records or by imposing a CLOSED practice. The DKIM WG has a few choices: A) State that ADSP only applies to SMTP and indicate ADSP does not prevent sub-domain related abuse. This approach should also specifically exclude attempts at validating the absence of ADSP records. (An approach that several have suggested.) B) State that the absence of ADSP records should be validated by the presence of SMTP resource records. This approach offers significant and immediate benefits, however this also necessitates a means to make domain specific exceptions. C) Don't state what transport is involved, and then suggest the absence of ADSP records might be validated by either the presence of SMTP resource records or the lack of NXDOMAIN. This approach offers few benefits, fails to confirm SMTP support, and fails to clarify what exceptions would be needed to prevent the disruption of non-SMTP transport. Either A or B approach would be okay. Attempting approach C has the potential of truly disenfranchising several non-SMTP transport users. It seems approach C is now being attempted by the WG ADSP draft. IMHO, approach B offers the greatest benefit over the long term. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html