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
