Re: [anti-spam-wg@localhost] Solution to Spam

[der Mouse <]

> The solution is simple:

> 1.  Limit the number of recipients for each email.  For domestic use,
>     10 or 20 is quite adaquate.  Emails with more recipients than the
>     allowed limit should automatically be spanned as separate emails.

This can be done now, by receiving mailservers.  It may be worth
trying, but I doubt it will help much.

> 2.  A 10-15 second delay between emails should be imposed.

This will be...difficult.  A given server can prevent a given sender
from sending more often than that, but nobody is in a position to
prevent a sender from sending back-to-back to multiple recipients.

Worse, it will punish legitimate senders who compose offline and send
the composed messages through their email provider's outgoing
mailserver as a batch, by requiring them to stay online several times
as long as they really need to.

> 3.  Each email request should force a graphic to be loaded to the
>     email client with an obscured word on it.  This graphic should be
>     random.

This immediately eliminates two classes of people from using email, the
blind and the text-only.  Neither is particularly large, but neither is
deserving of such treatment, and I for one as a mailserver owner and
operator (both incoming and outgoing) won't implement either side of
any protocol that has such effects.

It's not clear when this happens and to whom: to the sender's user
agent at send time, or the receivers' at receive time, at read time,
when?

> 4.  Each uploaded email should have a random ID appended to its
>     header as an authorisation code.

Appended by whom?  Who chooses it?  Who needs to trust it?  If that
entity isn't the sender, how can it be assured it's trustworthy?

> 5.  The recipient's email server should then confirm the code with
>     the sending server.  If the code does not exist then the email is
>     destroyed without notification.

What prevents a spammer's sending server (which these days usually
means an 0wn3d Windows box somewhere) from answering "yes, it's fine"
to every such "confirmation" request?

> So, let us do our sums on this, for an average spammer.  We'll assume
> that the email has 1000 recipients.

That's _way_ too low for a spam run.  1000000, or even 10000000.

> 1000 recipients at a limit of 10 per email would result
> in 100 emails.
> 100 * 10 seconds delay = 1000 seconds or about 16
> minutes.

Right as far as it goes.  But who is going to enforce these limits?
And how?

> add 100 * 5 second delay for loading of each
> authorisation graphic = 500 seconds or about 8 minutes.
> That's a total of 24 minutes to send 1000 recipients.

Five seconds?  How enormous are you thinking of making these images??
Anything that's large enough to have significant impact on high-speed
connections will be totally unusable on slow dialups.  Not to mention
the problems I sketched above (blind and text-only users).

> This coupled with the authorisation code will practically result in
> the complete elimination of spam on the internet if universally
> adopted.

Perhaps - but how do we get the spammers to adopt it?  How do we ensure
they are actually doing so instead of just writing shells that make all
the right noises when queried but don't actually do anything?

> The adaptations required to implement this are of a minor nature
> compared with other programming tasks and can be released as updates
> to existing servers and client software.

You appear to be under some kind of impression that spammers use
existing mail clients and servers for their spew.  This is true only
from the point at which it hits the recipient's incoming mailserver.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B