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

["Michael Kaplan" <mkaplansolution at lycos.com>]

> 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.smith at example and joe.jones at example.  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.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.org
https://www1.ietf.org/mailman/listinfo/asrg