Folks, Arvel Hathcock wrote: >>> Assume, say, one million people who regularly receive valid emails >>> from their bank ([EMAIL PROTECTED]). If they received an email >>> from [EMAIL PROTECTED], 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 [EMAIL PROTECTED], 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 [EMAIL PROTECTED] and [EMAIL PROTECTED] 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