On Thu, Apr 17, 2014 at 3:16 PM, Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
So, the bug is that Yahoo/DMARC/ are authenticating the From:, when it shouldOne of the key points about DMARC's design is that it's concerned specifically with From:. The reason is that the content of From: is what's typically shown to the recipient by MUAs. If DMARC keyed off Sender: instead, then this would work:
really be authenticating the Sender:. DMARC should key it's policy from
Sender: rather than From, and if it did that then:
1) we could leave the From: intact, which is what's good for the end
users.
2) the list would change the Sender:, which is what we would establish
the reputation of the list, not the From:
3) MUAs would compare the From: and Sender:, and if they differed,
could say useful things like:
"From: Mrex@xxxxxxx via ietf@xxxxxxxx".
(I was also wondering this morning on my commute if a layer of message/rfc822
added by the mailing list might be a useful interim hack)
From: security@xxxxxxxxxx
Sender: haha@xxxxxxxxxxxxxxxxxx
If DMARC pays attention to Sender: in favor of From:, then this passes, but what the user is shown that the message is from security@xxxxxxxxxx with a DMARC pass. Not good.Using Sender: as the authentication key was suggested and ultimately abandoned during both DomainKeys (RFC 4870, the predecessor to DKIM) and Sender-ID (RFC 4406, pretty much never implemented) for this sort of reason.
> MUAs which are not implementing the rfc822/2822/5322 "on behalf of"
> semantics of a message that carries both From: and Sender: header
> fields ought to be FIXED. Standards that build on rfc822/2822/5322
> and do not respect "on behalf of" semantics of messages with
> both "Sender:" and "From:" also need to be FIXED.
I don't believe that's standardized. I'm also not sure we (the IETF) want to enter into user space like MUAs, an area we have historically avoided because we don't really have such expertise.
-MSK