On 5/24/10 1:23 AM, Michael Deutschmann wrote:
On Sat, 22 May 2010, Dave Crocker wrote:
If there is a desire and need to have the semantic be "came from the
mailing list" then there needs to be a mailing list equivalent to ADSP,
which correlates a DKIM signature with the domain in a List-ID header
field.
That's not necessary.
The weakness of the "except-mlist" approach is not the difficulty of
authenticating that a given mail really is from the list it purports to be
from. We have off-the-shelf technology to do that: the list manager just
needs to use a constant MAIL FROM: domain, and protect that domain with
SPF.
The SPF element authorized is often poorly defined, whose resolution
can induce a large number of transactions against any third-party
domain. This is especially true when attempts search for the possible
element. Some now use SPF to signal reverse DNS PTR records having a
defined label, which suggests cooperation among the 40,000 IP address
owners. However, deployment of IPv6 will cause SPF and reverse DNS to
become vast and difficult to manage.
See: http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03
This scheme provides a LDSP type of third-party authorization where an
"L" flag signals a required list-id (see: RFC2919).
This scheme could even be extended to produce a policy similar to
"except-mlist" along with an ability to make exceptions.
If a BCP recommends "discardable" be discarded by mailing lists, it
should also recommend "all" be rejected as well. Neither "all" nor
"discardable" produces a compliant message when the Author Domain
signature is invalidated. (A flag added to DKIM signatures to signal
the presence of TPA policies.)
It requires some cooperation from the list owner, but so would "LDSP".
The TPA scheme does not require cooperation of list owners!
Rather, the weakness of "except-mlist" is that it requires that the MX
know which mailing lists each mailbox is legitimately subscribed to.
Without that, the badguys can pretend the victim subscribes to lists they
control.
The TPA scheme requires those seeking policy protections to provide the
relationships for MX handling. The "except-mlist" approach places the
burden upon the MX to know which mailing lists are safe. Unlike the
TPA scheme, the "except-mlist" will not allow author domains a means to
mitigate ongoing exploitation.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html