Thank you for your feedback. I have updated my website in response to what I
believe were the most significant criticisms of my method, and I believe that
my method is now devoid of any major flaws. I have previously responded to the
critiques you mention but I will reiterate. Once again all of this is
contained within my website:
http://home.nyc.rr.com/spamsolution/An%20Effective%20Solution%20for%20Spam.htm
"Michael Kaplan" <mkaplansolution(_at_)lycos(_dot_)com> wrote:
From: "Seth Breidbart" <sethb(_at_)panix(_dot_)com>
I thought that the issue that you were bringing up was the
following: A spammer forges your address and sends out a million
pieces of spam and you subsequently get an enormous number of
bounces as per my system. I suggest that this won't be an issue
as your email service provider
will only allow you to receive one of these special bounces if you
had just sent out the corresponding email.
You're assuming that my email provider runs your system. Any method
that requires global implementation to start with isn't going to fly.
Since my provider isn't running your system, those who are running
your system are going to be spamming me, reported as spamming me, and
blocked for spamming me.
The following is from my website. It addresses how my system will deal with
bounces:
"Email service providers will continue their practice of blocking the bulk of
email
that is suspected of being spam even before it is accepted. Bounces are never
sent
to this vast amount of probable spam that is rejected at edge. All emails that
make
it to the level of content filtering are then sent through a weak spam filter
(meaning one that will almost never generate a false positive). Let us say
this weak filter, in combination with the pre-acceptance spam blocking,
identifies 95% of spam emails as unambiguously being spam. Bounces are
now generated only to the remaining 5% of emails. Now ISACS can only
increase a network's traffic up to 5%. This small increase in traffic
should be quite tolerable. We have also dramatically decreased the number
of innocent people who will be hit with these bounces because a spammer forged
their email address. (Frankly if a spammer can forge your address then you must
really be getting hit with spam, so activating ISACS would solve your problems).
Using a ?normal? spam filter instead of a weak one will obviously place an even
lower burden on the email system.
There will still be some innocent victims, but the number is now far fewer.
Email service providers can respond to the growing popularity of this system
by filtering out any bounce that is sent to a user who had not previously sent
the corresponding email. There really should be no reason for anyone to receive
a bounce in response to an email that they never sent."
As you can see instant global implementation of my system is definitely not a
requirement.
This is not a content filter. If the spammer doesn't have your
email address then the spammer can't send you spam. There is no
reason for the spammer to increase the spam load. Sending spam to a
very effective filter is not futile. Sending spam to a non-existent
address is completely futile so the spammer will stop doing it.
History says otherwise.
I will no longer argue that the system will decrease spamming attempts, although
it will certainly profoundly decrease spam seen by the user.
How do I know which language my sender will prefer? Particularly if the
sender is a new correspondent. If I set my system up to send out such
bounces in say, Hindi, and you don't understand it at all, how would
that situation be handled?
The text in these bounces is generic. My email provider can
recognize one of these generic bounces and substitute the generic
Hindi message with an identicle generic English message. I'm sure
that others can think of other similar ways to handle this
situation.
Once again, you're assuming that all email providers implement your
system on Day 1.
I have markedly improved my system for dealing with multiple languages.
Once again from my web-site:
" When you activate this system you select what languages you want
the bounces to go out in. Someone who speaks English and Chinese will
select both languages. The bounce will go out containing instructions
in both languages. If someone who only spoke Russian sent this Chinese
and English speaker an email using a deactivated sub-address then yes,
the Russian person would not be able to directly follow the instructions
to decode the CAPTCHA. It will be a rare occurrence, however, for these
two people to be corresponding."
Once again instant global implementation is completely unnecessary.
Even if this process did not happen then I doubt it would be a big
problem. If your system sends out bounces in Hindi then whoever is
trying to correspond with you also likely speaks Hindi. People who
cannot read each others language at all rarely correspond via email.
That works fine for mono-lingual people on both ends.
But what happens when I try to correspond with someone who speaks
Hindi, French, and English and whose primary language is not English?
We _could_ communicate except that your system sends me the Hindi
version.
Answered above.
I have actually been quite pleased by the feed back I've received over
this discussion board. No, I haven't received much in terms of words of
support,
but I've avoided what I feared most: A specific reason(s) why my system wouldn't
work. I was able to rectify most of the concrete objections (such as above)
with a few days of thought. Many of the remaining criticisms focused on
sub-groups
of individuals that wouldn't want to activate my system. I had already accepted
that some people wouldn't want to use my system but that the majority of
users would find it acceptable.
My system remains the ONLY proposed system that allows people avoid nearly 100%
of spam
while retaining their current email address, while allowing strangers to
correspond,
while being very simple to use and to implement, while remaining
impervious to any technical circumvention by spammers.
Others have said that this is not the best system, but those same individuals
absolutely refused to provide an example of a better system. I will continue
to pursue the development of this system until I am given a specific reason to
believe that it will
not work.
Michael G. 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