ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Reading the entrails, was Moving to consensus

2009-03-22 13:44:32

On Mar 22, 2009, at 8:01 AM, SM wrote:

I don't see much benefit in using DKIM for a blacklist model where  
we have to play catch-up with the "bad guys".

Agreed, but DKIM will likely become a hybrid of acceptance and  
provisional blocking.

Using DKIM only to move from IP address to domain based reputation  
gives us IP address independence only.  It is easier to sign using  
one domain if the end-result we seek is only to create an input for  
a reputation system which assesses the sending MTA.  The downside is  
that we are replicating the current "IP address model" with its  
disadvantages.

DKIM replay abuse is beginning, where i= values, as defined in RFC  
4871, offer a method to mitigate intra-domain sources.  Most larger  
domains exhibit a small percentage of abusive accounts.  When i= value  
control fails, d= values will likely be removed from unconditional  
acceptance lists, since DKIM replay defeats typical account rate limits.

The i= value offers a solution to this looming problem.  It is  
unfortunate that ADSP constrains the i= value in its effort to limit  
acceptance of g= restricted keys when the i= value is not represented  
in the From header.   If that type of signature represents a risk, it  
should be declared invalid by the DKIM base specification.  Due to  
complexities imposed by double signing, ADSP is only suitable for a  
small number of domains.  With such limited coverage, it seems  
unlikely receiving domains will expend additional resources to  
evaluate ADSP i= value compliance.

The i=value will help differentiate intra-domain message streams, such  
as those from mail-lists.  When annotation is based upon  
Authentication-Results headers, then the i= value can clarify a  
message's origination within the domain.  It is unclear how DKIM/ 
Authentication-Results headers can be safely merged with newly devised  
headers without problematic adoption of changes to three different  
specifications.

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

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