Dave Crocker 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) no matter what Alice's SSP says. Bob
is perfectly entitled to resend a mail he got using the header
fields specified in STD 11 or 2822.
Where "reject" is of course the least problematic outcome, but
"annotate as suspicious", the weasel words for "delete", would
be wrong.
I agree, and I'd appreciate some help on how to make this clear. The
corresponding requirement is actually in the form of a negative in
requirement #12.
Maybe I just need some forward references in the scenarios to the
fundamental corresponding requirements?
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.
[INFORMATIVE NOTE: the main thrust of this requirement is
that practices should only be published for that which the
publisher has control, and should not restate what is
ultimately the local policy of the receiver.]
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html