[ietf-dkim] Re: Role of Sender header as signing domain

[Scott Kitterman]

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.

Scott K