On Feb 13, 2009, at 3:33 PM, Ellen Siegel wrote:
Can you explain why you think this makes it impossible to use i= in
an arbitrary way? I don't see that that usage is excluded. If it's
not intended to be stable, there is no constraint at all except that
it can't use an identical identifier for unrelated groupings. And
even if it is intended to be stable, there is only a SHOULD for
using the same identifier.
There are likely two important constraints in the use of the i=
parameter.
1) A domain's token versus real namespace should not overlap within
the same message.
2) Whenever there is risk that a bad actor might be granted access,
the i= values assigned to these risky sources should be stable for a
period measured in hours and ideally days.
Otherwise, the i= value may become deceptive in the first case, and
may not serve to reduce replay abuse in the second.
Without a practical means to limit the abuse from a larger domain,
DKIM will not provide much value for most of Today's email. Many
domains emit hundreds of millions of messages daily. Tracking abuse
by message-ID or by signature will always be reactive and not respond
fast enough to mitigate abuse.
The typical malware lifespan is now measured in hours in the war
against polymorphic malware. Bad actors have well demonstrated their
effectiveness at leveraging the time it takes to flood the Internet
with the details of their bad deeds. DKIM should strive to limit the
amount of protective information disseminated. When a source
represents a transactional operation from a well controlled database,
a need for i= value stability is not likely. For larger domains,
offering an i= value will likely gain greater importance, especially
when IPv6 becomes a factor. Time will tell.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html