Michael Thomas wrote:
Whatever SSP does (and the more interesting case is a "Bob" who
is completely DKIM-unaware), the mail should not be rejected
by the next receiver(s) ...
This line of discusses re-enters the model in which we believe the
sender is telling the receiver how to process in-coming mail. That
is, essentially, intruding on the SMTP specification and the rather
wide range of individual receive-side operational policies.
I (again) suggest that we do not want to do that.
I'm pretty sure I'm not doing that. Requirement #12 sez:
12. Given the considerations in scenario 4, the protocol MUST NOT
provide a mechanism which impugns the mere existence of third
party signatures in a message. A corollary of this requirement
is that the protocol MUST NOT in any way tie practices of first
party signers with third party signers.
I do not see how this language pertains to directives about rejecting or
not rejecting a message. That is, I think there is confusion about
dictating the processing of a signature with the acceptance or rejection
of a message.
The former is within our purview. The latter is not.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html