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

From: "Michael Kaplan" <[email-masked]>
Date: Sat, 08 Jan 2005 10:55:59 -0500

> What are the prospects for user-side automation?
> 
> If X sends out a weekly newsletter to thousands of people, most of
> whom use your system, then X receives thousands of bounce messages
> back, requiring individual CAPTCHA decoding, followed by individual
> resending of the message, does it not?

It almost sounds as if you expect most newsletters to get bounced.
The newsletter will only get bounced if the specific sub-address used by 
the newsletter is deactivated.  But yes, inevitably some users will 
deactivate the newsletter sub-address after receiving spam.  
I've already guesstimated that commercial businesses could likely have
these CAPTCHA manually decoded in a developing country for about 0.1 cent
a piece.  The newsletter operator could spend $10 and pay for processing
10,000 bounces a year.

> How does your system fare against snooping attacks, wherein any
> relevant information such as sender + receiver's email addresses are
> routinely harvested from archives, hacked and proxied servers, and
> spyware infested computers, and fake bounces are sent back to each
> identified sender, containing a spamvertizement? These fake bounces
> are always whitelisted, are they not?

I'm not qualified to say how snooping attacks can be prevented,
but I will say that unlike the current system it is not the end of the
world when an email address is harvested since my system anticipates that
spammers will periodically harvest new addresses.  Users will deactivate the
sub-address of any harvested address.

I'm not sure what you are describing when you talk about "fake bounces."
I believe that the nature of the bounce problem is not related to
what you are suggesting.

> What is the effect of harvesting correct subaddresses by searching for
> the replies to the CAPTCHA bounces, wherein the correct subaddress is
> visible in the clear?

A person would only decode a CAPTCHA and use that sub-address when
emailing a legitimate contact.  I'm not sure how spammers are supposed
to harvest the sub-address from this mundane email correspondence.

> What is the effect of bouncing the CAPTCHA bounce back to the CAPTCHA
> bouncing recipient, with or without another CAPTCHA attached?

With my system a bounce will never be generated in response to a bounce.

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Laird Breyer <[email-masked]>
Date: Sun, 9 Jan 2005 13:29:41 +1000

On Jan 08 2005, Michael Kaplan wrote:
> the newsletter is deactivated.  

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.

> But yes, inevitably some users will 

So you expect newsletters to be sent by commercial operators exclusively?
What about noncommercial list operators?

Also, there are privacy implications in outsourcing the processing of
sensitive email messages to cheap third parties? 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?

> sub-address of any harvested address.

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 believe that the nature of the bounce problem is not related to

I'm using bounce in your sense as described in your proposal, namely a
CAPTCHA challenge replied to the sender to verify whether he or she is
human.

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.

> to harvest the sub-address from this mundane email correspondence.

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.

> With my system a bounce will never be generated in response to a bounce.

You assume that your system is universal. Consider two competing
incompatible CAPTCHA challenge systems, and the potential for bouncing
back and forth unrecognised challenges.

-- 
Laird Breyer.

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sun, 9 Jan 2005 14:32:00 +0100

> at least once? That's a thousand bounces (ie number of recipients) right

Probably not. The User would generate a fresh subaddress and subscribe
that to the newsletter. Since Subaddresses are created in "accept
everything" mode in Michael's proposal, the newsletter would be accepted
without a challenge. Only when the subaddress is deactivated, challenges
will be generated. (On a well-maintained newsletter this will probably
cause the address to be unsubscribed)

However, subscribing to mailinglists may be a bit difficult with
Michael's scheme:

Lets say, Our user Joe tries to subscriben to the mailinglist
<[email-masked]>. So he creates a new subaddress (e.g.,
<[email-masked]>) and enters into a web form or sends it to
<[email-masked]>. Typically, the mailing-list software will
reply with a confirmation request: from:
<[email-masked]> to: <[email-masked]>. When Joe
replies, his software will generate a new unique address, since he never
sent mail to <[email-masked]> before (e.g.,
<[email-masked]>). So the Mailinglist-Software will receive a
confirmation from <[email-masked]> to subscribe the address
<[email-masked]>. Some mailinglist software will refuse the
request if the two addresses don't match. 

Even if he manages to subscribe, however, the first time he wants to
send something to the mailinglist, the software will create yet another
unique address (e.g., <[email-masked]>), since he hasn't sent
anything to <[email-masked]> yet. Since most mailinglists only allow
postings from subscribed addresses, his message won't get through
(Some, but not all mailing lists allow you to specify alternate
addresses).

So at the very least, any software implementing Michael's proposal needs
to allow the user to override the automatic generation of new
subaddresses. (This of course means user interaction and it means user
errors - I know that I often make errors of that kind when I first post
to a new mailinglist)

> is the only widespread protection in existence. 

That and the sheer number of mail paths. A spammer is probably not in a
position where he can intercept a significant number of mails.

	hp

-- 
   _  | Peter J. Holzer    | Je höher der Norden, desto weniger wird
|_|_) | Sysadmin WSR       | überhaupt gesprochen, also auch kein Dialekt.
| |   | [email-masked]         | Hallig Gröde ist fast gänzlich dialektfrei.
__/   | http://www.hjp.at/ |   -- Hannes Petersen in desd
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Thomas Gal" <[email-masked]>
Date: Thu, 13 Jan 2005 11:42:05 -0800

Just a *little* insensitive huh (or should we be excited that this
plan creates employment)? Not to mention the fact that cheap labor seems to
conveniently straddle the fence and be cost effective for mailing list
providers (who oddly sell no product on a per email basis), but not cost
effective for spam producers (who do sell a product or scam in every email)
under your system. Why would it be difficult for spammers (remember botnets
are talking now and show no signs of losing intelligence) propogate those
email addresses upon discovery as well? Sure you wouldn't get spam all the
time, but every once in a while you'll get 5000!
	I wonder too if any of us have experienced how LAME it is to get
vacation and out of office bounces, and would be excited at the prospect of
more challenge response emails clogging our inbox everytime we send an email
to a new list. First you get your welcome to the list email, and then when
you send your question out to the list you get (imagine the IETF list) 1500
C/R emails. Heck for the effort of all of that I could have just gone to an
IETF meeting and signed everyones PGP keys that I met, and not only handly
provided myself an infrastructure to aleviate spam by using crypto, I've
included authentication and encryption of my messages as well. And if you
decide to have a special email address for the email list instead of
actually saying it's from who it's from (which is how you went at it) it's
just an even more valuable target for spammers to grab and distribute. "Hey
guys....just send to this email as so and so and you can reach 12,000 people
easy!"
	Seems like the path of not taking issues seriously and semi-patchin
the hull continues, but I still see lots of flaws and not so many virtues.

-Tom

[email-masked]  

> The newsletter will only get bounced if the specific 
> sub-address used by the newsletter is deactivated.  But yes, 
> inevitably some users will deactivate the newsletter 
> sub-address after receiving spam.  
> I've already guesstimated that commercial businesses could 
> likely have these CAPTCHA manually decoded in a developing 
> country for about 0.1 cent a piece.  The newsletter operator 
> could spend $10 and pay for processing 10,000 bounces a year.
>