[ietf-dkim] Practices protocol naming poll (Closing issue 1550)
Scott Kitterman
ietf-dkim at kitterman.com
Thu Mar 20 21:06:05 PDT 2008
On Thu, 20 Mar 2008 23:22:24 -0400 Sandy Wills <sandy at WEIJax.com> wrote:
>Dave Crocker wrote:
>>
>> Exactly which value of exactly which field or command are you referring
to?
>>
>> And how does your desire related to the current *SP specification, which
>> explicitly calls for using the value(s) in the rfc2822.From field?
>
>I don't see how we can get a useful check from this header line:
>
>From: Me at AOL.com, You at Hotmail.com, Him at gmail.com, Her at yahoo.com
>
> There's been a lot of bandwidth invested in discussion of which
>address is "right". First? Last? There's no clear best answer, which
>means there's no _right_ answer that can be put in a spec and used. Any
>decision made by us will be capricious and without basis, and will be
>screwed up by the first email user to forget to put his boss's name first.
>
>But we may get something useful from:
>
>Sender: Me at AOL.com
>
>which is required if From: has more than one item.
>
> An implementation of SSP can start with a check for Sender: simply
>because if it exists, that's the sender. One test and it's done. Only
>if that check fails would it look at From: and use the
>by-definition-only-one sender found there. In the worst case, it makes
>two tests and it's done.
> Looking at From: first seems to be slightly more complicated, to me.
> Look for a From: address, good, look for another. If none, that's it.
> If another found, then throw that away and look for a Sender: address.
> Always at least two looks, and sometimes three.
And Sender is quite often (usually AFAIK) not displayed to the end user.
Once we're in the land of largely invisible header fields, there of no
ability to reliably sort out mail that is spoofed from a particular domain.
Why not include resent-* too.
Unless the protocol is tied to From, it's essentially valueless from my
perspective. There is not a solution that is both pretty and useful. Pick
one.
Scott K
More information about the ietf-dkim
mailing list