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

[Michael Thomas]

Dave Crocker wrote:

>
> 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.

Dave, I'm completely confused. The constraint of requirement 12 is a 
constraint on
the protocol design in the form of "don't provide this". It's not 
telling the receiver to do
anything.

       Mike