On 5/20/10 11:22 AM, John Levine wrote: > > From my perspective, it would have to be very compelling for me to > >> support modifying ADSP at this point. ADSP is the DKIM tail and not >> vice a versa. >> > Entirely agreed. As this point the only concrete datum I'm aware of > is that ADSP has been observed to break IETF mailing lists. I would > want to see a lot more practical as opposed to hypothetical experience > before offering further advice. > John,
Your advise is generally good, but not in respect to "all". Rather than weakening MTA acceptance barriers imposed by DKIM+ADSP "all" or "discardable", these barriers need strengthening. ADSP "all" is intended to mitigate the significant harm caused by phishing. It is not reasonable to expect recipients will know whether a message contains a mailing list related headers that might defeat ADSP protections. ADSP "all" or "discardable" offers email service providers a clear basis to not deliver non-compliant messages. Email service providers should ensure strict ADSP compliance. While resorting to "discardable" might increase the number of non-complaint messages blocked, this is at the expense of delivery integrity, which "all" was to avoid. To achieve greater compliance with "all" or "discardable", a legal imperative seems needed. The "except-mlist" assertion offers potentially deceptive results, where the author domain needs to make explicit exceptions. An ADSP "copyrighted" assertion along with an Author Domain Signature that includes a "(copyright)" comment should allow injured domains a means to seek expeditious compliance. By creating a potential for needing to respond, email service providers would then likely become proactive and strictly adhere to ADSP assertions. Those wanting to participate on mailing list would then need to use alternative domains, where perhaps the list subscription could ask about their desired ADSP compliance, with a checkbox or command "as currently signed". -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
