*** 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 *************** If we are going to have a list of designate third parties, they should be treated like first party (that's the point of the list). I'd make it a MUST, except that would be specifying receiver policy. Additionally, while I agree that receiver policy should not be required by the protocol, I think that not specifying a desired receiver policy goes to far. I'd suggest that we MUST NOT require instead of MUST NOT specify. That achieves the goal of not having receiver policy cause protocol failures, but allows more freedom in design to communicate sender expectations. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html