On Monday 10 December 2007 12:24, Dave Crocker wrote:
Wietse Venema wrote:
My point is that SSP alone cannot distinguish between mail from my
Bank and mail from a Criminal who pretends to be a slightly different
bank. It distinguishes only the stupid criminals who send mail in
the Bank's name without signature by the Bank.
...
SSP alone does not distinguish between mail from a Bank and mail
from a Criminal who pretends to be a bank. That is SSP's dirty
little secret.
I think this goes to a core issue point of discrimination that should be
used for considering SSP features: The difference between near-term,
essentially tactical, concerns, versus concerns that are strategic.
A standard is a very expensive thing. Expensive to develop, expensive to
deploy and typically expensive to use when it pertains to operations issue
and especially to policy issues.
Hence, a standard should pertain to core, strategic issues, especially when
they are in the security and operations realm.
Fraudulent From domains are a problem, and they certainly occur in massive
numbers, but if bad actors can trivially use alternatives that are not
equally protected, fixing only the fraudulent From domain issue is of no
long-term benefit.
As such, anything that SSP attempts needs to be evaluated in terms of
long-term benefits and the likelihood that there is a simple work-around
available to bad actors.
My own preference is to look for mechanisms that would be good to have,
even if spam and phishing were not serious problems, and then use their
presence merely as motivators for taking immediate action.
We have extensive, real world precedent for signing messages.
I believe we do not have any real-world precedent for telling recipients
what to do with mail that is not signed. And we certainly have not done a
threats and work-arounds analysis for SSP.
For each proposed SSP feature, there needs to be a statement describing the
thread, the way that the feature will mitigate it and some discussion of
possible work-arounds and the ease with which they can be used.
d/
-1. Been there. Done that. And no, I'm not going to look it up for you.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html