It still can be "opaque" on the left hand side and it can still be aligned with
then first party and/or third party. The problem was the lack of a policy
system, rules to verify the expectation declared by policy. That was what made
it "opaque" and quite frankly, DKIM itself is "opaque"without policy protocol.
--
Hector Santos
http://www.santronics.com
On Jul 28, 2014, at 5:11 PM, Douglas Otis
<doug(_dot_)mtview(_at_)gmail(_dot_)com> wrote:
Dear Tony,
See comments inline:
On Jul 28, 2014, at 11:04 AM, Tony Hansen <tony(_at_)att(_dot_)com> wrote:
On 7/26/14, 11:16 AM, John Levine wrote:
When i= was considered important in DKIM, many people considered it a
valid way to verify the identity of the sender of a message, given that
*) it was actually used
*) it really did map into the name used with the From: header
So the text about "belongs to the person who actually sent the message"
could be considered a reference to the use of i=.
Well, yes, and no. In retrospect, that was always a failure of
communication. The i= bit came from people in corporate environments
where the mail system is locked down, and you can't put anyone's
return address but your own on your mail. But, of course, there are a
lot of mail systems, and only some of them are like that.
Yup, hence my subsequent sentence that you didn't quote:
However, subsequent work with DKIM showed that i= was unreliable for that
purpose, and instead should be treated as an opaque value.
Agreed.
At the time DKIM was being proposed, I suggested it should have provisions
for opaque tokens for abuse feedback reporting. Although the 'i=' tag had to
be within the signing domain; it evolved into being defined as an opaque
reference. This definition, however, could prove problematic if in conflict
with processes expecting its prior definition. It seems a safer approach
would have been to deprecate the 'i=' and define a new opaque tracking tag.
Is there a survey showing this tag can be safely used as an opaque reference?
Regards,
Douglas Otis
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp