On Aug 9, 2006, at 7:51 PM, Scott Kitterman wrote:
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: [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]
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.
Actually "Signing Complete" should be as explicit assertion, whereas
"Not Signing Complete" should be a default that indicates the First
Party address also uses other services. Domains being used to sign
the First Party address may not be found listed in the policy, but
rather this would require the history of these services be assessed
independently. These services could also include various mailing
lists for example. Having a domain name listed in the policy should
only imply that this domain is authoritative for the First Party
Address to allow trustworthy annotations. (It really was originated
by First Party Address.) Indicating Signing Complete would be an
additional assertion that this list is also representative of the
only sources used.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
