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