AccuSpam Rebuttal to [ASCR REPLY: Individual responses from the Anti-Spam Community Registry]

[AccuSpam <support@xxxxxxxxxxxx>]

"..." below means portions we've deleted in order to focus on substantive
issues.

Again, we want to repeat that AccuSpam is *not* against .Mail.  We feel no
threat from it, nor SPF or any other sender authentication scheme.  Our logic
is that these schemes require 100% implemention in community in order to be
effective, thus will not be widely used, not even by corporations.  See below
for why.


>ASCR wrote:
>...the civil dialog...is both proper as well as productive...


Agreed.


>ASCR wrote:
>...Shelby Moore from AccuSpam noted, "...most people are unable
>to always send email from the...server...which is listed for
>their domain in DNS. Some examples are when people travel or
>if they use a different ISP for their domain (web site) than the
>ISP they connect to internet with."
>
>Shelby, what you're missing is that .Mail is not a
>"forgery prevention system" like SPF. It's not intended, at the onset,
>for individuals - and we've said that. Corporations like eBay,...*do*
>send mail from the same, known servers.


You are confirming that .Mail is a "forgery prevention system" for big
corporations.  It does not benefit the vast majority of senders.

Yet it does require a change to *all* MTA (and/or MUA) on the internet in order
to function effectively.  If even *one* MTA is not implementing .Mail
anti-forgery filters, then some forgery will still occur on .Mail domains.

And it does require *all* recipients (and/or the anti-spam filters of *all*
recipients) to treat .Mail differently.

It is a huge (centralized and dispersed) infrastructure change and huge
dispersed psychological change (for *all* recipients).  That was "cost" when I
studied economics.

And this "cost" which is charged to *all* senders and recipients, benefits only
big corporate senders.  You can argue that it benefits recipients, but only the
recipients of those corporations who use it (see next paragraph for why very
few corporations will use it).

Also I think it is highly dubious that every employee in corporations using
.Mail will be able to always send through the "approved" and "verified" mail
servers.  However, the whole premise of .Mail is that recipients should not
trust email coming from a non-.Mail domain, if that that domain also has a
.Mail domain.  Thus you end up with situation where email automatically
generated by the corporate server (e.g. Amazon receipt) is coming from the
"approved" and "verified" servers and then the human email coming from the
corporations is sometimes (even if extremely rarely) silently deleted by
SendMail and other MTAs implementing the anti-forgery filter.  You will end up
with false positives.  Those false positives could be valueable corporate
emails.  Corporations will backlash and dump the use of their .Mail once they
realize their outgoing human mail is sometimes (even if rarely) being silently
deleted.  Most people place 100 to 1000 times more value on a false positive (a
deleted legit email), than on a false negative (a not deleted spam email).

On top of that, how do we go about letting *all* recipients know which domains
have a .Mail and which ones do not.  I am not talking about computer programs
in this paragraph, but the human minds of *all* recipients.  It is a massive
confusion as to which domains should be trusted and which ones not.

.Mail and SPF are focusing the community on a fundamental decision about how we
are going to handle the forgery of sender ("spoofing") problem.  .Mail is
essentially a way to do SPF for only some domains.  It gains nothing over SPF
because you still have to implement it out to all MTA and all anti-spam filters
and all human minds.  It adds the problem on how to know in real-time, in the
human mind, which domains are and are not using .Mail.  Remember humans scan
Inbox in real-time-- they don't have time to go look up a database for each
incoming email.

So I should disclose again (in the interests of transparency of our
motivations), AccuSpam is developing what we believe is a better solution, that
does not have *any* of the problems I've mentioned above.  We are working as
fast as we can and *hope* (not sure) to announce it BEFORE the decision on
.Mail is made.  It has nothing to do with the current algorithm being used for
AccuSpam.com.  It can co-exist with .Mail (supplement each other), so there is
not motivation of competition on our part.


>...
>But to refute your point, .Mail does not require senders
>to send email from the mail server of their domain...
>A sender can send email though any server where they
>have been authorized to send email though...the
>mail server can now be a validated...


The sender still has to send through one of the validated, approved servers. 
The essense of my criticism is still valid.  There are many reasons that people
need to relay mail off the point of most convenience.  Or just consider human
error, since humans configure the relay server in their MUA (email program). 
Or just consider cost of enforcement for the corporation.  There are many ways
to look at the costs, but the bottom line is always the same.  There is a good
economic and pragmatic reason that SMTP was written the way it was.  It has to
do with the diversity of life and humans and nature.

Any way, never mind the philosophical or theoretical, and just focus on the
false positive scenario I outlined above for the corporation who uses .Mail.



>ASCR wrote:
>..."MX" record in DNS, it's used for incoming email, not outgoing.


Correct.

However, it does not change the basis and essense of my point about various
sender authentication schemes, in that they require 100% compliance of the MTA
else, they are not effective, and they require 100% compliance of the sender,
else they result in false positives.  Humans are simply not 100%, and that
diversity is a strength of nature and should be embraced (see the false
positive scenario of .Mail below for it's centralized police for "spam").  To
fight that diversity of nature, is futile.



>ASCR wrote:
>Mr. Moore also noted, "We have a theory that ANY anti-spam
>is successful only to the extent it increases costs on the
>spammers more than the aggregate increase cost on the
>community for legitimate email."
>
>While this is an interesting theory, it's not germane to our
>proposal. The cost to spammers for the .Mail system is
>functionally infinite as well as zero, as they're not allowed
>to use it in the first place.


The cost on the spammer is the extent to which .Mail affects their ROI (return
on invesment).  We have described some of the costs on the community above in
this rebuttal.  It is clear that very few senders will be protected by .Mail,
so cost on spammer is small, but the cost on the community is huge as I have
explained above.  Also .Mail has a cost of false positives on it's own senders
(explained above and more scenarios coming below).

Our theory so far has correctly predicted how popular anti-spam systems are. 
Given Bayes Theorem, we can induce that probability of theory is true increases
as evidence increases is that theory is not false.



>ASCR wrote:
>Mr. Moore goes on to say, "...it requires ALL recipients to
>incur a new cost for a very small number of senders."
>
>...Those users who wish to take advantage of the .Mail system
>will add it to their filters, but are under no obligation to do so.


Agreed.  Recipients can choose to ignore .Mail.  However, please see below.


>ASCR wrote:
>...MTAs who wish to participate will encode it as part of their
>defaults.


But if even *one* MTA does not implement .Mail, then *only some* (in fact we
will argue none) of recipients can trust .Mail.  Then you have the cost for
recipients of knowing whether the MTA that the email passed through was .Mail
compliant or not.  And then if they recieve a non-.Mail email, they have to
know whether the domain of the sender has a .Mail and thus whether they should
or should not trust it.  As explained above, recipients scan the Inbox, they
don't have time to do these manual lookups.  You either end up with 100%
compliance or you end up with a lot of cost in confusion.  Because of this
confusion, very near 0% of recipients will end up trusting .Mail.



>ASCR wrote:
>Indeed, the inventor of the most widely-used MTA (Sendmail)
>has already stated in a number of public media stories that he
>likes this proposal.


I hope he reads our rebuttal.



>ASCR wrote:
>The only "cost" users who wish to take advantage of the .Mail
>system will have would be that of a DNS lookup...


Even if you ignore the "contagion" or "side-effect" costs we outlined above and
focus only on the direct cost to implement .Mail for one recipient, I still
disagree.  The recipient has to research, find out what .Mail tool to buy,
whether to let his upstream MTA do it, or do it in his MUA (as additional
check).  This raises the point that since no one can be 100% sure the upstream
MTA did the .Mail anti-forgery check, there could be redundant hits on the
verification DNS.

However we are not concerned about the DNS traffic.  We are concerned about the
"contagion" or "side-effect" costs we outlined above and more below.


>ASCR wrote:
>...
>Mr. Moore also notes that this would be impossible for an ISP
>to set up for its users. Again, we've stated many times that
>this is not for individual users in its build-out phase. It's
>for larger senders of responsible mail who are finding that
>their legitimate, non-spam mail is not being delivered because
>it's being falsely identified as spam. The .Mail proposal is one
>for a sending system that is intended to be spam-free.


First, you confirm again that .Mail will only benefit a small minority of
senders.  What are we going to do about forgery of individuals?  You may argue
that is not your problem or your focus, but if we adopt SPF or other method for
anti-forgery, then .Mail becomes mostly redundant.

Second, you confirm that .Mail can be used to subvert anti-spam filters.  You
hope to police this with centralized verification interpretations.  Good luck! 
Some corporations think their spam is not.  Who is going to decide whose
interpretation of "spam" is correct in each instance?  "spam" is mostly an
individual interpretation of the recipient.

In fact, we have real fears that .Mail will cause more false positives and
increase false negatives!  Read below for more analysis.  That is why we are
faily confident, it won't be adopted by many, after all the hype dies into
reality of experience.



>ASCR wrote:
>Mr. Moore then states, "Besides, anti-forgery detection can
>already be done using "reverse DNS."
>
>Actually, not really. Anyone who has control over IP space
>pointers can forge a reverse DNS value. We'd be happy to set
>up the reverse DNS, for "forged.accuspam.com" on an IP to
>demonstrate.


But "forged.accuspam.com" is not "accuspam.com", but that is beside the
substantive point.  The point is there is an existing infrastructure to
implement and test a database idea such as .Mail without needing a new domain. 
I think it would be wise to test a proof-of-concept in the real world, before
asking every ISP in the world to update their MTA server.  Prove that the
database of "good senders" can work in selective implementation, because we do
not think it can for reasons explained above and below.

The community could improve "reverse DNS" which is essentially what I
understand SPF to be.

We did not mean we are advocating sender authentication (such as .Mail and SPF
and "reverse dns") that requires 100% compliance of the MTA to be effective. 
We know "reverse dns" is not a viable technique for anti-spam or anti-forgery.


>ASCR wrote:
> The key to the .Mail system is that the Sponsor Organizations
>retains control over the DNS as well as the validation procedures.
>Indeed, that's the crux of the proposal.


And we think centralized control over *anything* on internet is a bad precedent
for both technical and political reasons.  Especially if the same problem can
be solved with a dispersed solution which can be implemented incrementally
(alluding to a future AccuSpam press release of yet unreleased ("vaporware")
anti-forgery technology).


>ASCR wrote:
>We couldn't agree more - Mr. Breitner just described the .Mail
>proposal. The credentials you mention are validated and maintained
>by the .Mail registry, simply because if ISPs control them, then
>the spammers will simply become their own ISP (as many already have).


So you propose centralized control over interpretation of what is "spam". 
Sounds like a recipe for a lot of lawsuits.

Spam can not *always* be defined in terms of the sender.  Only the recipient
can make that individual decision in some cases.  So to have a centralized
decision *MUST* create false positives and false negatives.  It is impossible
not to, because not all individuals *always* agree.


Well we could rebutt some more points, but we think this is enough for now.


Bottom line is that SMTP was designed to cooperate with the diversity of
nature, not fight it.  And designed to avoid the problems of centralized
control and interpretation.  There is no 100% anything, and thus in anti-spam
and anti-forgery we have to make solutions that are controlled by each
recipient (in case of anti-spam) and sender (in case of anti-forgery) and which
scale in increments less than 100%.

Shelby Moore
http://AccuSpam.com