ietf-asrg
[Top] [All Lists]

Re: [Asrg] Please critique my anti-spam system

2005-01-10 22:26:00
I'm getting the impression that you have essentially no practical 
experience running any mail system of significant size.

Certainly true, but this is not a direct criticism of my system.


[snip]

Frankly I think it is very sad that after a decade of 
experimentation in the field and 2 years of the ASRG, the only 
thing keeping this list active is a debate over the details of yet 
another sweepingly naive and hopelessly unworkable FUSSP.

I imagine that, as per the purpose of this group, that any serious anti-spam 
proposal that is not blatantly unworkable would be considered by this group 
until it was either found to be too flawed or until it was accepted by the 
group.

I presented my proposal on the premise that it could nearly eliminate spam for 
a very large segment of email users, that it could be easily and gradually 
integrated into current email structure, that it would very easy even for a 
neophyte to use, and that it would remain invulnerable to technical subversion 
for years to come.  This group then pointed out several flaws with the system 
that I had not considered or given enough appreciation for.

Many of these flaws would have doomed my system if they had gone uncorrected.  
Sometimes the first couple of solutions I would give were also flawed, but 
eventually I discovered I had an appropriate solution.

My system was declared dead at least 4-5 different times due to killer flaws, 
but they all had solutions.
I summarize some of the major killer flaws and the solutions I presented on 
this list-

Problem:  The system cannot deal with multiple languages.
Solution:  The user selects which languages bounces should go out in.  More 
than one language can be selected.

Problem:  The bounces can potentially double all email traffic.
Solution:  Filter out spam, only bounce in response to what gets through the 
filter.  Now email traffic can only be increased by 1-5%, depending on the 
strength of the filter that is used.

Problem:  Spammers will assume the addresses of innocent people and these 
people will get hit with erroneous bounces.
Solution:  As per above most spam does not generate a bounce.  Filtering out 
bounces that were not sent by the user is extremely simple and most email 
providers will likely do this filtering once this system is used by more than a 
nominal number of email users.  (also since most spam uses made up return 
addresses the ratio of erroneous bounces to actual spam would be very low).

Problem:  Many email providers already use addresses such as 
joe(_dot_)smith(_at_)example and joe(_dot_)jones(_at_)example(_dot_)  My system 
will therefor cause mailing list problems and inconvenience many companies who 
already use this format for their employee email.
Solution:  Use a less commonly used symbol to designate a sub-address.  
joe.smith;8u4nds(_at_)example or joe(_dot_)smith^8u4nds(_at_)example can be 
accepted as a common standard.  Or some other lesser used symbol.  Now the 
above problem is greatly mitigated.

Problem:  Use of a valid sub-address results in guaranteed delivery to the 
user.  Thus a valid sub-address is more valuable than a regular sub-address, 
even if that sub-address has a very finite life-span.
Solution:  Filter the mail that comes in with a sub-address.


I also include responses to what I call opinions.  I call them opinions because 
no modification is required and because, well, I disagree with them -

Opinion:  It is practical for spammers to have the CAPTCHA manually decoded.
Response:  Way too expensive, especially since even this email will have to 
pass through a spam filter.

Opinion:  A system that causes any number of innocent people to receive an 
erroneous bounce is unacceptable.
Response:  My system may (warning: arbitrary guess coming) prevent 500 pieces 
of spam from reaching inboxes for every one erroneous bounce that arrives in an 
inbox.  I could live with this.  If your provider had updated your system then 
you will never get an erroneous bounce.

Opinion:  Spammers harvest the email addresses of most people with such an 
extraordinary degree of success and frequency that this system will fail.
Response:  Temporary email addresses and services like Zoemail are based on 
this principle.  I really just disagree.


Well, I could go on.

So once again I ask:  Is there any Achilles heel to this system?  Is there any 
reason why it would not work?
Has someone already posted a serious flaw that I have failed to answer, and if 
so can you remind me of it.

Also I don't have to be the only one here to offer solutions to the posted 
criticisms. (some people have answered some of the more minor criticisms).  My 
technical expertise is such that I am actually the least qualified to do so.

I believe the process we've been having is the very purpose of the ASRG.  If by 
consensus my system is flawed and unfixable or otherwise impractical I will 
back away.  Is that the consensus?

Michael Kaplan
  
-- 
_______________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg