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
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Thursday, August 10, 2006 10:20 PM
To: Michael Thomas; Damon
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Issue: Requirements #9 NOT REQUIRED for
1stpartyvalid signatures.
----- Original Message -----
From: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>
To: "Damon" <deepvoice(_at_)gmail(_dot_)com>
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