ietf-dkim
[Top] [All Lists]

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

2006-09-21 10:55:06
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
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html