[ietf-dkim] Re: New Issue: Problems with Scenario 4: Resent
mike at mtcc.com
Thu Sep 21 10:18:11 PDT 2006
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.]
More information about the ietf-dkim