John R. Levine wrote:
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?
No, it's not backward compatible. My signatures all have a fully
compliant i= value which is not an e-mail address. (Take a look.)
It appears to be an email address and the mipassoc.org verifier failed
your signature:
Authentication-Results: sbh17.songbird.com;
dkim=permerror (verification error: multiple DNS
replies for `164d0.4d9bcfc5.k1104._domainkey.iecc.com')
header.i=johnl(_at_)submit(_dot_)iecc(_dot_)com
Silent ponders.....
Should a verifier use the first TXT response for this public key
164d0.4d9bcfc5.k1104._domainkey.iecc.com query?
A verbal signing practice failed Levine's expectation for a non-email
address i= value. Can that be translated to an automated POLICY based
violation rule?
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html