[ietf-dkim] Re: New Issue: Problems with Scenario 4: Resent

[Michael Thomas]

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