Franck Martin wrote:
+1
My understanding is that i= does not need to represent a
valid email address, it just need to be in a kind of valid
email address format.
The specification requires the domain part of i= to either match the
d= domain or be a subdomain of the d= domain. Examples:
d=example.com; i=user(_at_)example(_dot_)com valid
d=example.com; i=user(_at_)sub(_dot_)example(_dot_)com valid
d=example.com; i=user(_at_)sample(_dot_)com invalid
If the public key has a g= value, then a wildcard string comparison is
done. Since the default value g= is *, the g=/i= test would always
be a true.
Now, it is possible to have the hash verification of the signature to
be valid yet, the i=/d= and i=/g= granularity checking fail to return
a invalid signature result which by DKIM standards is a NO SIGNATURE
status.
So if we keep i= as is in the spec, we can conclude the
standard process and give a meaning of i= outside this spec
in another RFC?
We are so close, yet so far. :) Wouldn't it be better to fix whatever
is wrong with it or remove it now?
The reason it is technically safe to remove is mostly because it is
optional and invalid signatures are not considered by reputation.
Since for valid signatures the only feed to reputation is the signer
domain, there is no harm.
Legacy Signers can still add the i= tag to be hash bound to the
signature. So even if there is a fraudulent attempt to tamper with i=,
the hash verification would fail and the outcome would be the same -
no valid signature.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html