[ietf-dkim] Re: Role of Sender header as signing domain
ietf-dkim at kitterman.com
Tue Nov 28 07:42:11 PST 2006
On Tuesday 28 November 2006 10:17, Frank Ellermann wrote:
> Hector Santos wrote:
> > Why are you stuck on Sender? It is not the author or owner of the
> > message and that is whats important in DKIM.
> If the sender is different from the From address(es) it's clearly
> not the author. But at that time it's the owner, responsible for
> many technical details, Dave's "secy" in RFC 733.
> For Resend-* the owner at that time is the "resender", responsible
> for picking this way to forward the mail to somebody else. It should
> work often. But not in scenarios where an anti-replay mechanism or
> something else stripped important (for DKIM) header fields of the
> original sender (author or secy). Or if the original mail is old.
> >> this is a petition for reopening this Issue. That gives 1 vote, but
> >> you will need lots more to take action. So I invite anyone else who
> >> supports this view to reply with a +1.
> +1 Hector's "owner" proposal makes me nervous, the owner is somebody
> who has a mail, it can be the receiver, a secy, a list, a gateway, ...
So how do we start down this path without ending up with PRA?
2822.From is the only identity that is reliably displayed to the end user. It
is also a required part of the message. As soon as you grant 2822.Sender the
same role as 2822.From in SSP, then any anti-forgery potential inherent in
SSP (let's not argue that one again - just saying to the extent there is any)
has been seriously diluted. Follow this trail to the end and you end up
protecting resent-sender again.
More information about the ietf-dkim