Tony,
Then your domain (att.com) will need to declare a relaxed 3rd party
signature concept.
For example:
Using SSP-01 this is defined as default policy or o=~.
Using a DSAP framework, you would declare:
OP=OPTIONAL;
3P=OPTIONAL;
In both cases, you are using a NEUTRAL policy.
You are no longer protecting the authorization of the signature because you
essentially don't care who signs the message.
But you want to allow the 3rd party to have the message authenticity and
integrity power of DKIM.
Now, with DSAP, you can be restrictive on which 3rd party would be allowed
to sign:
OP=OPTIONAL;
3P=OPTIONAL;
3PL=*.hallmark.com;*.newyorktimes.com
which Michael's document covers with requirement #5 covers.
So in my technical view, we don't need the 2822.Sender because it is already
covered with requirement #5.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Tony Hansen" <[EMAIL PROTECTED]>
To: "DKIM List" <ietf-dkim@mipassoc.org>
Sent: Wednesday, August 09, 2006 10:30 PM
Subject: Re: [ietf-dkim] RFC2822.Sender
> Stephen Farrell wrote:
> >
> > Michael Thomas wrote:
> >> Tony Hansen wrote:
> >>> add RFC2822.Sender
> >>>
> >> I'm not the chair, but I've seen considerably less consensus about
> >> anything other than rfc2822.from. I'm frankly not sure I understand
> >> it very well.
> >
> > I know I don't understand it!
> >
> > Maybe a more detailed use-case would help? (Tony?)
>
> I want to make certain that what we're building with policies doesn't
> prevent eCard senders or News agencies from doing what they currently
> do. They should be able to 1) send a message to someone on my behalf
> while 2) marking themselves as the sender and 3) being able to sign the
> message. According to 2822, this minimally requires support for
> RFC2822.Sender as well as RFC2822.From.
>
> For example, consider these scenarios:
>
> From: [EMAIL PROTECTED]
> Sender: [EMAIL PROTECTED]
> DKIM-Signature: ... d=hallmark.com; ...
> Subject: Happy birthday from Tony
> or
> From: [EMAIL PROTECTED]
> Sender: [EMAIL PROTECTED]
> DKIM-Signature: ... d=newyorktimes.com; ...
> Subject: some news story
>
> These need to be validated against the sender.
>
> Yes, there are a variety of issues. And to properly deal with this
> issue, we also need to deal with Sender/d= above being "@bigbadguy.com".
> DKIM is not sufficient in and of itself, as we all know. But we need to
> be able to support these scenarios somehow.
>
> If we don't let this be done using Sender:, then we need to have some
> other way of doing it. My choice is to support the 2822 way of doing it,
> which says we need to support Sender:.
>
> Tony Hansen
> [EMAIL PROTECTED]
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
