Hector, The issue with checking SSP first is that DKIM base is stand alone. Some people will deploy base and not deploy SSP until much later if at all. Thanks,
Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hector Santos Sent: Thursday, August 10, 2006 10:20 PM To: Michael Thomas; Damon Cc: [email protected] Subject: Re: [ietf-dkim] Issue: Requirements #9 NOT REQUIRED for 1stpartyvalid signatures. ----- Original Message ----- From: "Michael Thomas" <[EMAIL PROTECTED]> To: "Damon" <[EMAIL PROTECTED]> >> Damon wrote: >> >> The Protocol MUST NOT be required to be invoked if a valid >> first party signature (without the 's') is found. > This was a typo on my part. The intent was only one first party > signature is necessary. Sorry 'bout that; corrected. I vote to remove this requirement #9 since its design implementation concept and it conflicts with some of other reguirements such as: #2, #3, #4 and #7 which all have a need to check SSP first scenario. Examples: "No Mail Expected" signed or not signed, it failed an expectation. "No Signing Expected", it should not matter if the mail was signed by whom, it failed an expectation. and so on. The implemention can choose to look at the verification of first or decide to do the SSP first. As long as the combined results produces the same outcome, it should not matter how it is done. On the other hand, in my technical opinion, to be consistent and in order to statisfy discovery requirements, a more efficient model is to so SSP first, before verification is done. So if anything, the discovery requirements should promote Practice and Expectation requirement that says: The PROTOCOL SHOULD consider to be invoked first before the need for signature verification is required. But again, a design consideration so I vote to remove it since its really more about telling the protocol designer how the steps should be done. Unless of course, we agree that this ought to be done. :-) -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
