ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] l= summary, as I see it

2009-05-22 12:39:03

On May 22, 2009, at 6:53 AM, Eliot Lear wrote:
l= provides a benefit when the SIGNERS sign, and mailing lists DON'T  
DISTURB.  This does happen, although we can debate how often.  The  
key point is that if the mailing lists employ an anti-spam check and  
resign, there is probably no need for l=.  This to me means that l=  
should be viewed as a Time To Market function to have more valid  
signatures out there, and is best obviated by deployment of DKIM in  
mailing list software.  That's happened in some place, but not enough.

I stand by my point that it is perfectly feasible to mitigate any  
risks that l= introduces.  But.  Those risks DO have to be mitigated.

So here's where I come down: nuke l=, but get the mailing list  
software people to sign.  The big one I would want to tackle is  
MailMan.


Why limit the l= discussion to messages being changed made mailing  
lists???

Mailing lists will not affect often phished transactional email where  
retaining valid signatures is far more important.  It is too soon to  
conclude how DKIM is best used.  Many recipients will receive messages  
with various bits of text added, such as ads which may unsafe,  
especially when iFRAMEs are commonly inserted into websites.  Removing  
the l= parameter will ensure DKIM is unable to cope with this  
situation and DKIM signatures will fail to provide the desired  
protection.  People may even expect DKIM signatures to fail whenever a  
notice is added.  This creates an obvious mode for phishing by adding  
fake notices.

Not all providers check DKIM signatures.  To improve DKIM coverage, it  
could become important for MUAs to remain able to bridge protection  
gaps and deal with typical environments, and indicate appended  
information.

-Doug


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