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