On Wednesday 09 August 2006 22:30, Tony Hansen wrote:
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: tony(_at_)att(_dot_)com
Sender: cards(_at_)hallmark(_dot_)com
DKIM-Signature: ... d=hallmark.com; ...
Subject: Happy birthday from Tony
or
From: tony(_at_)att(_dot_)com
Sender: news(_at_)newyorktimes(_dot_)com
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
tony(_at_)att(_dot_)com
I think that this scenario is already supported by the "Signing Complete"
practice and explicitly not desireable for the First Party (as extended by a
possible list) Expected Practice.
I think that the current requirements are correct for this use case. This is
exactly the kind of scenario First Party Expected should not support.
Signing Complete deals with the case where a domain desires to support Sender
with an associated signature and no policy record (or signs sometimes if we
end up with such a practice) supports Sender with or without a signature.
First Party Expected supports the case where a domain does not want to allow
2822.Sender signatures/policies to over-ride the 2822.From.
My vote is no change needed to the current draft for this.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html