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