On Jan 08 2005, Michael Kaplan wrote:
Wouldn't the newsletter operator first have to obtain the specific
sub-address from each receiver (assuming your system is widely deployed)
at least once? That's a thousand bounces (ie number of recipients) right
at the start.
The address is provided by the recipient when they sign up for the newsletter,
just like what is done now.
You mean the sub-address? How many unique sub-addresses do you expect people
to carry in their heads, or do you expect each person to carry around
a sub-address generator everywhere, for such occasions?
Also, there are privacy implications in outsourcing the processing of
sensitive email messages to cheap third parties?
Outsource the CAPTCHA, not the entire message.
The CAPTCHA contains the key to generating the required sub-address. That's
all that is needed.
What happens if a
Nigerian spammer outfit offers 0.1 cent per bounce processing, and
keeps a record of these bounce messages, reads each CAPTCHA and
compiles a clean set of email addresses which are guaranteed to accept
spam messages?
In the critique section of my webpage I detail how tremendously
costly this would be for spammers.
No it would not be. You can't have it both ways. On one side, you say
it would be cheap to decode CAPTCHAs by an army of human beings, but now
you say it would be expensive to decode CAPTCHAs by an army of human beings.
I'm saying if the CAPTCHAs are decoded at 0.1 cent a pop, then the decoder
can increase profits by 100% simply by reselling the decoded CAPTCHA at
0.1 cent a pop.
Each such deactivation generates a number of automatic CAPTCHA bounce
messages for people trying to contact that sub-address. The more
snooping occurs, the higher the frequency of deactivation, and the
higher the amount of work on senders. However, snooping implies
guaranteed spam delivery, so is much more valuable than ordinary mail
address harvests, and is easy to do with a distributed infrastructure.
I'll leave others to comment with more knowledge, but I doubt that
snooping occurs with such an extreme degree of frequency that it would
disable this system. This system is ideal for dealing with an address
that is occasionally snooped.
Your system seems to *require* that addresses be snooped only
occasionally, as you don't appear to have given much thought yet on
the equally valid possibility that addresses be snooped very
frequently. Might I suggest you think through the case of frequent
snooping and write down solutions for the implications as part of your
case studies?
The existence of these CAPTCHA messages are an inherent security risk,
because they are allowed to be passed to the receiver's inbox without
checks of any kind, on a priority basis, provided a weak set of
credentials is bundled. This weak set of credentials consists of
a public email address identifying the purported sender, if I understand
your proposal correctly.
The obvious line of attack given the above is as follows: A spammer
writes a CAPTCHA containing an advertisement rather than a
sub-address, and inserts as the sender of this fake CAPTCHA an email
address which is likely to belong to the receiver's whitelist.
Sometimes, this fake CAPTCHA is blocked because the inserted address
is not on the receiver's whitelist, but this doesn't matter to the
spammer as the mail did not cost him much to send. Sometimes, the
inserted address belongs to the receiver's whitelist, in which case the
advertising payload gets priority treatment, bypassing all spam defenses
as it could be a legitimate challenge.
An email service provider that has not no accommodation to my system
would treat a fake bounce just like any other piece of spam, ergo the spammer
would have no incentive to fake a bounce.
That's incorrect. Your bounce, when treated like any piece of spam,
will arrive into a user's inbox about 30% of the time, just like any
other piece of spam. (global deployed spam catch rates appear to be
around 70% or so). The spammer therefore has the following incentives
after harvesting:
* 30% of fake CAPTCHA challenges go through to the wider population.
* 100% of fake CAPTCHA challenges go through to the population which deploys
your system.
An email service provider that has accommodated my system will
treat a fake bounce just like an erroneous bounce. The bounce white
list will only allow in bounces coming from an address that the user
had emailed within the past few hours. The fake bounce will never
be seen, ergo the spammer would have no incentive to fake a bounce.
Of course the fake bounce will be seen, since it has the correct
sender address. Remember that a few hours is a million years for a
computer.
Perhaps you are unaware of the fact that email is much like a
postcard, without the stamping security measure. Anybody at any time
can read messages, or in fact modify them in every way, so long as
they are located within the relevant mail path. The honour system
is the only widespread protection in existence.
Valid sub-addresses can also be harvested automatically on users'
computers by spyware. Valid pairs of (sender/receiver) addresses can
be harvested from public archives of mailing lists, and such pairs can
be used to send spam disguised as a fake CAPTCHA challenge as
described above.
I don't have to hypothesize about the efficacy of multiple sub-addresses.
Zoemail and Reflexion users have many satisfied customers.
How many customers do Zoemail and Reflexion have in total? Aren't you
perhaps generalizing from insufficient data? You are after all proposing
a system for the masses, so you must think in terms of hundreds of
millions of users.
I don't mean to flood the list with postings concerning my system,
but since my initial posting I've only been responding to follow-up
posts. Although flaws exist, I am pleased (at least in my view) that
If the postings are becoming off topic, the chair should probably step
in and say so. Otherwise, this is still a semi-technical discussion
(and it is certainly not intended to be personal).
no killer flaws have been illuminated, and that no reason has been
given why it wouldn't be highly efficacious at blocking spam even when
employed by a massive number of people. Much of the concern seems focus
on inconvenience to people who do not use the system, and I still can't
bring myself to believe that this inconvenience is severe enough to kill
the system, especially given the severity of the spam problem. I accept
that others feel differently.
It takes time to understand a system invented by someone else, so flaws
if any don't show up on a strict schedule.
Inconvenience is not the sole focus of the criticisms I've followed on
this thread. I've seen people list at least the following:
* Unacceptable increases of mail traffic.
* Incompatibility with mailing lists.
You've argued that the increase of traffic can be kept to 5%, but that
seems wildly optimistic to me. Here's a procedure for increasing the
traffic by much, much more:
Consider a mailing list serving 1000 people. Assume that each such
person has given a single unique sub-address to the mailing list
operator, and the mails being distributed by that list are therefore
accepted without filtering by each of the 1000 people.
One of these people is a spammer, who begins to send spam messages
through the list after a short time. Each of the 1000 users now
receives unfiltered spam through the list address, and decides to turn
off their list sub-address. The next time some message is sent via the
mailing list, 1000 CAPTCHA bounces are sent to the mailing list
operator. Conclusion: one single message sent by a spammer to the list
has resulted in 1000 CAPTCHA bounces, representing approximately
100,000% increase in traffic for the operator over a short time.
There's also the fact that list messages (such as your own to this
list) often arrive twice, once through the list and once directly. If
I used your system, I would be sending you a CAPTCHA bounce which
would be clogging your inbox. You would get a bounce for every user
you replied to on this list, and requiring you to place me and all
other members of this list on your whitelist over time.
-- Laird Breyer.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg