***************
*** 537,549 ****
for signing its messages to a non-related domain in such a way
that it does not require active participation by the non-related
domain. That is, the published information MUST have a way to
! specify the domains that are allowed to sign on its behalf.
6. Practices and Expectations MUST be presented as an information
service from the sender to be consumed as an added factor to the
receiver's local policy. In particular a Practice or
! Expectation MUST NOT specify any particular disposition stance
! that the receiver should follow.
7. If the Discovery process would be shortened by publication of a
"null" practice, the protocol SHOULD provide a mechanism to
--- 542,556 ----
for signing its messages to a non-related domain in such a way
that it does not require active participation by the non-related
domain. That is, the published information MUST have a way to
! specify the domains that are allowed to sign on its behalf.
! Signatures by such delagatees SHOULD be treated like First Party
! DKIM signatures.
6. Practices and Expectations MUST be presented as an information
service from the sender to be consumed as an added factor to the
receiver's local policy. In particular a Practice or
! Expectation MUST NOT require any particular disposition stance
! that the receiver MUST follow.
7. If the Discovery process would be shortened by publication of a
"null" practice, the protocol SHOULD provide a mechanism to
***************
This addition is suggested for a couple of reasons...
1. Completeness. I think there is some value in providing a reasonably
complete list of Practices. There will likely be effective uses for policy
information by receivers that we haven't thought of yet. An incomplete set
of practices may hamstring this kind of innovation.
2. RFC 2821 discovery - This is the requirement change a alluded to yesterday
in the signalling DKIM support before DATA thread. I won't rehash that here.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html