Hector Santos wrote:
Patrick Peterson wrote:
PS: SSP does not dictate receiver behavior :)
and the irony is that raw DKIM *does* dictate receive behavior!
The Receiver either processes DKIM or it doesn't. But if it does, there
is a militant inherent policy of "Ignore if Failure." Forget that it
was ever signed.
IMO, this inherent DKIM policy defies logic and this makes SSP even
harder to work out. It is the #1 flaw of the system and in my book,
possibly the ultimate consideration if DKIM will become widely adopted
or not. It policy, done to appease the mailing list people, will
continue to be a thorn on DKIM's side until it is resolved or addressed
by some means.
What that means, that SSP should of been designed to look at three DKIM
possible results:
1 - NOT SIGNED
2 - SIGNED AND SUCCESSFUL
3 - SIGNED BUT FAILURE
#1 and #3 are really not the same as DKIM wants it to be. Although SSP
is allowed to do a SSP check for #1 and #3, any final classifications
performed are dependent on those two states, including any future
desirable reporting system based on it.
"Report: This message was never signed."
"Report: This message was signed and successful"
"Report: This message was signed but it failed to be validated."
DKIM "ignore if failure" simply makes everything more complicated for
any augmented policy-based or reputation-based add-on technology. That
high potential realistic state simply can not be ignored.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html