Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joi

  On 9/24/10 3:46 PM, Michael Deutschmann wrote:
> > On 23/Sep/10 21:16, John R. Levine wrote:
> > > All of this emphasis on complex designs for MLMs strikes me as a waste
> > > of time, since it's a tiny corner of the mail space that has not
> > > historically been a vector for abuse, and shows no sign of becoming one.
> It may be tiny, but users will not tolerate the total destruction of
> mailing list traffic, which is the inevitable result of any ADSP use at
> both ends which is sufficent to block actual forgeries (without using
> whitelists).
Agreed.  Most domains desire protection from blatant spoofing.  
Unfortunately, assertions requiring Author Domain signatures negatively 
affect deliverability.  Regardless how a signature might be damaged or 
missing, the ADSP dkim=all tpa-path allows rejection of any failure not 
recovered with a TPA Label.  TPA-Labels accommodate various verification 
methods from specific domains based upon DKIM signatures, or TLS, or 
SPF, or EHLO/addr to permit highly restrictive acceptance criteria, and 
even accommodate use of specific mailing-lists.  Making such 
accommodations could reduce use cousin or sub domains as a solution to 
protect transactional messages which then makes the phishing problem 
more intractable.

DKIM/ADSP being unable to make exceptions, prevents greater use of 
restrictive acceptance criteria designed to mitigate spoofing.  As a 
result, one of DKIM's strongest features can't be utilized by most 
domains.  Out of about 20 thousand financial domains being heavily 
phished, only 60 have found the only actionable ADSP assertion 
"discardable" appropriate, even though DKIM is significantly better at 
surviving email infrastructure than SPF.  The TPA-Label tool is able to 
recover from any number of problematic downstream services and this 
should offer significant survivability improvements.   Mailing lists 
sign their messages will simplify the recovery process.

Blocking all neutral sources is not practical, nor is reactive blocking 
effective against phishing. DKIM should be able to support proactive 
blocking based upon sender practices.  Recipients processing these 
practices will benefit with less email in an unknown state.

-Doug

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