----- Original Message -----
From: "Tim Draegen" <tdraegen(_at_)ironport(_dot_)com>
To: <Bill(_dot_)Oxley(_at_)cox(_dot_)com>
- All the language in SSP-req around how a verifier should
handle mail can be axed. Specifically, the information
advertised by SSP should stop at "I (do/do not/partially)
sign". Adding ".. and therefore you should treat unsigned
email from me as suspicious" might seem useful, but the
unenforcible nature of this only adds confusion.
And removing it further adds confusion to an already ambiguous "What is the
Payoff?" DKIM-BASE protocol that has a very high potential for invalidation.
Signing mail is the easy part. What you need to do is explain to me (and
the rest of the receiver world) why they should a) look for, and b) add
overhead in processing DKIM signatured on the receiver end. For what
purpose? For the signer's benefit? The receiver's benefit? The User's
benefit? And how do you measure that benefit?
We keep trying to hide the fact, the reality, that in the end, every one of
us is going to market and use DKIM as a New Security, "Anti-Bad Mail", "Good
Guy Reinforcement" feature, which inherently implies a filtering or Tagging
concept that is independent of how one actually does rejects, holds, tags or
ignores mail.
My suggestion is to remove all these subjective ideas and concentrate on the
mechanics on how SSP can improve the security (authorization) of using
DKIM-BASE in the first place. I believe that was the original proof of
concept when DKIM and SSP was just one! It was a mistake to separate it in
my view.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html