On 9/16/10 5:15 PM, Michael Deutschmann wrote: > ... The "third party signing" problem and the mailing list problem > are *not the same*. The latter is a narrower use case. It's not > even a subset of literal "third party signing", since any complete > solution must accommodate third parties who *do not sign* --- > mailing lists that are completely DKIM-ignorant.
Agreed. > (Yes, I know any accommodation of legacy lists makes it much much > easier to pull off a successful forgery. But as the alternative is > "dkim=unknown", it's no loss. An intermediate signal, meaning that > mailing lists are the only way the signature can break, would be very > helpful to recipients who know what they are subscribed to.) Review the TPA-Label draft. The Third-Party Authorization specifies _how_ the entity can be authenticated using methods such as DKIM, SPF, EHLO, TLS, etcetera where the SMTP client should be identified to mitigate message replay abuse. DKIM does not represent the best method to authenticate the SMTP client, however a cryptographic method for authenticating this source is needed to better cope with the IPv6 environment. The Authorization can also require inclusion of List-ID or Sender header fields before messages from this source are acceptable. These additional requirements should help mitigate most of the risks related to spoofing with a message that visually appears to represent a distribution from a different source. In the case of mailing-lists, recipients would be wise to sort list messages into specific folders to better ensure there would be less of an opportunity for deception. Likely, for most of those subscribed to a list, this is already a common practice. > Sure, you can try to force all mailing lists to go through some > signing ritual. But if the mailing lists were that willing to bend > to accommodate DKIM, they could already accommodate the published > RFCs by rewriting the From: on the messages they forward. No need to force lists to change their behavior. Instead, third-party services need to be characterized by zones containing TPA-Labels to allow administrators an easy method to convey their desires by simply pointing to such a zone. For example, imagine MAAWG publishing their own TPA-Label zone. The TPA-Label scheme allows email to gracefully transition to different authentication methods as they become available. A domain may decide to sign using a subdomain just so they can signal which authentication method should be used for messages containing their Author Domain. Once ADSP provides both comprehensive and actionable information, recipients will have a greater incentive to process this protocol. Recipients might even decided to check ADSP first, since a lack of a TPA-Label in conjunction with a ADSP dkim=tpa-path assertion can signal a message should be refused before any authentication is even attempted. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
