ietf-dkim
[Top] [All Lists]

[ietf-dkim] end-users vs filtering engines

2008-04-30 11:23:24
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

<Prev in Thread] Current Thread [Next in Thread>