ietf-dkim
[Top] [All Lists]

[ietf-dkim] RFC2822.Sender

2006-08-09 12:07:36
Tony Hansen wrote:

Damon wrote:
--- 350,357 ----
   previous scenario.  A receiver, on the other hand, may be able to
   take advantage of the knowledge the domain's practice of signing all
   mail in order to use it to bias filters against the unexpected
!    arrival of a piece of unsigned, damaged in transit mail, or mail
!    signed by an entity not described in the RFC2822.From sender policy.

(Scott's ideas incorporated too)

!! arrival of a piece of unsigned, damaged in transit mail, or if
a RFC2822.From sender policy exists which specifies authoritative
domain(s), a mail signed by an entity other than described in the sender
policy.

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. There's of course nothing that prevents a receiver from checking SSP for any address/domain it wants to, but do we now have a mandate to make assertions about any kind of origination address? How do those assertions interact with each other? What does a strong practice for ListID and a weak practice for Sender mean if they're in the same message?

Finally, is this something that can wait? Ie, are we harmed if we don't do it now?

      Mike
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html