On Feb 10, 2009, at 8:23 PM, Jim Fenton wrote:
Added:
Absent additional external information outside of the
context of g=, verifiers MUST treat the Local-part contents as
opaque strings.
My suggestion (in place of the added sentence):
In the absence of external assertions to the contrary, verifiers
MUST not assume that the i= value corresponds to an email address;
both the Local-part of the value and any "subdomain" of the d= value
that appears are significant only to the signer.
While caution is commendable, going to this extreme is detrimental.
Use of the i= parameter to affirm email-addresses of the domain in
signed header fields will now require an undefined semaphore. ADSP
does not represent a good solution since ADSP is not suitable for
many, if not most, domains and only corresponds with the From header.
The fix for ADSP for conflicts is to include a signature without an i=
value. In essence, calling the i= value opaque without other
assertions permits what should be viewed as an extremely poor
practice. When someone is using a token for the i= value that
collides with their real email-address space within the same message,
they are in a small, perhaps nonexistent, minority.
Such use would be fairly deceptive after all. Since such use is
deceptive, rather than warning against i= values without finding some
new and undefined semaphore, it would be safer and less disruptive to
warn against the colliding of token and real namespace within the same
message. Both of these spaces are under the control of the domain and
are easily isolated since tokens are not constrained to just nine
digits. Why burden DKIM with yet another mechanism without an
apparent necessity, and where future problems are better resolved by
SHOULD NOT allow token namespace to collide with real email-addresses
within the same message.
Would it really be preferable to have an o= tag with a value "real" or
"token" included within the DKIM signature? Or is a new header REALLY:
i=<> needed?
Where do you see a solution being found? What would be the
repercussions of just saying within an Errata or some deployment
document:
The DKIM signature SHOULD NOT allow any i= value token namespace to
collide with real email-addresses within the same message?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html