I have an issue with one item, below.
Eric Allman wrote:
>>> B.6 Third-party Message Transmission
>>>
>>> Third-party message transmission refers to the authorized sending
>>> of mail by an Internet application on behalf of a user. For
>>> example, a website providing news may allow the reader to forward
>>> a copy of the message to a friend; this is typically done using
>>> the reader's email address. This is sometimes referred to as the
>>> "Evite problem", named after the website of the same name that
>>> allows a user to send invitations to friends.
>>>
>>> One way this can be handled is to continue to put the reader's
>>> email address in the From field of the message, but put an
>>> address owned by the site into the Sender field, and sign the
>>> message on behalf of the Sender. A verifying MTA should accept
>>> this and rewrite the From field to indicate the address that was
>>> verified, i.e., From: John Doe via [EMAIL PROTECTED]
>>> <[EMAIL PROTECTED]>.
>>
>>
>> (dhc) I am not sure which entity the term "the Sender" is referring
>> to, here. But again, this is wandering in the space of the MUA, I
>> think.
>
> Rewritten to:
>
> One way this can be handled is to continue to put the
> reader's email address in the From header field of the
> message, but put an address owned by the site into the Sender
> header field, and sign the message on behalf of that address.
> A verifying MTA should accept this and rewrite the From
> header field to indicate the address that was verified, i.e.,
> From: John Doe via [EMAIL PROTECTED] <[EMAIL PROTECTED]>.
Two points here:
* Such rewriting MUST be done *after* the verification pass has been
performed. (Obviously it can't be done before, unless the From: header
is not in the h= field list.)
* Once such rewriting is done, this message will never re-verify
again. This would *prevent* a subsequent entity, such as the MUA, from
doing its own verification. It would be nice if there were some way of
preserving the original From: contents if reverification is necessary so
that any such rewriting can be reversed for the reverification.
Tony Hansen
[EMAIL PROTECTED]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
