ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion

2010-04-28 14:27:04
On 4/28/10 11:11 AM, John R. Levine wrote:
or this might be a narrow scenario where ADSP could do less harm
than good.

could you elaborate. I'm rusty on ADSP. Was a MLM option
introduced?

 No, ADSP can say "throw away mail that purports to be from me if it's
 not signed", and the MLM could apply it to incoming mail.

ADSP policy would be in respect to the From email address domain, 
independent of a DKIM signature or evidence of having emerged from a 
mailing list.

White-listing a mailing-list to override the application of ADSP could 
expose these lists to relaying misleading messages when needed handling 
has not been applied.  Allow domains interested in being protected, 
audit for the needed handling and then make explicit authorizations of 
the third-party services.  After all, third-party authorization scheme 
scales, and will only require a single transaction to solve issues 
created by ADSP records using the same transactional overhead.

Your proposal that MLM remove Signatures would cause restrictive
policies to fail. Seems like ADSP would make things worse in this
case.

 Indeed.  I'm assuming that any list that paid attention to ADSP would
 sign its outgoing mail and would expect its recipients to trust it
 enough to whitelist the list's mail.  Or equally (more?) likely, ADSP
 doesn't really work, and users who sign everything can tell the list
 manually.

There are many considerations what should go into a mailing-lists being 
white-listed against the application of ADSP policies.  Why not allow 
domains seeking protection with ADSP to make the needed audits and 
convey their approval by way of a domain authorization?  Perhaps some 
have no interest in seeing their messages replayed and distributed by 
some mailing lists.   There is no limit on the number of domains 
authorized using a hashed label approach.

-Doug


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>