[Top] [All Lists]

Re: [ietf-smtp] RFC2821bis discussion of DKIM and SPF (was Re: Error in RFC 5321 concerning SPF and DKIM)

2014-07-30 10:18:13
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

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.


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?

Douglas Otis

ietf-smtp mailing list

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>