Folks,
Arvel Hathcock wrote:
Assume, say, one million people who regularly receive valid emails
from their bank (info(_at_)accounts(_dot_)bigbank(_dot_)com). If they
received an email
from info(_at_)mail(_dot_)account(_dot_)bigbank(_dot_)com, how many of them
would believe the
email is really from the bank?
I assure you, lots. Through liberal use of sub-domains via email and
web sites end users have been trained to ignore the sub-domain part
...
MTA operators will be using/deploying ADSP. End-users are the intended
beneficiary (as is the case with _all_ filtering systems). The
motivation driving MTA operators to deploy ADSP is end-user protection.
There is a difference between intending end-user benefit, versus intending
end-user processing. We need to be quite clear about what entity is actually
going to process the information ADSP is supplying. From your note, it isn't
clear where you expect the processing to be done.
If the goal is end-user processing of differential information about domain
names in the From: field, then I urge us to shut the effort down now.
Seriously.
There is no empirical basis for believing that the "protection" of these ADSP
features will be a) understandable by end-users, or b) hard for attackers to
bypass. Absent strong and clear empirical basis, we have to rely on general
precepts about humans factors, and these, I am afraid, do not support this
effort.
If it's for end users, my experience says that they are equally likely to
be fooled by info(_at_)accounts-bigbank(_dot_)com, which would suggest
we've been
wasting our time.
I agree with the first part of what you've said but the second part does
not follow logically. One can not claim that because we fail to protect
a user completely we therefore aren't able to provide any protection at
all and have thus wasted our time. ADSP isn't attempting to solve the
accounts-bigbank.com problem. But it does solve the foo.bigbank.com
problem. This is wonderful news and a welcome step forward.
Let's consider this some more:
Users will not distinguish between
info(_at_)accounts(_dot_)bigbank(_dot_)com and
info(_at_)accounts-bigbank(_dot_)com(_dot_)
No matter how much you protect the use of one, you cannot protect
against use of the other. So, cousin domains provide an utterly trivial path
for bypassing the intended end-user protection.
Standards are costly to develop, deploy and use. A global standard had
better provide strategic benefit. That means persistentAs explained, this
won't do that. Even if one believes that it "protects" the name space it seeks
to protect, the ability to bypass that protection trivially means that there
is no real end-user benefit.
As a consequence, what you claim as protection really is not meaningful
protection.
Some of us in this working group have some background in human factors,
usability, user-centered design, and the other topics (and buzzwords) of the
human side of computer use. Most of us do not. As a working group, we have
amply demonstrated a complete lack of skill in designing for end-user
processing. So we need to stop trying.
Filtering engines, on the other hand, are far more tractable as targets. As a
group, we know a fair amount about them. They can be taught to map a
particular domain name to a particular reputation and then apply that
diligently. However as has been noted, filtering engines are more typically
using precise strings, rather than name "root" strings.
In any event, this basic confusion about intended use of ADSP is one of the
several reasons there is no real consensus about it or its features.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html