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/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html