http://www.rhyolite.com/anti-spam/you-might-be.html
I confess to:
a) feeling that CRAP appears to attempt to solve a problem of too many
mail messages by generating yet more messages, and
b) falling under the #activist tag, myself. (does anybody really buy
anything from spam, or is the problem that people buy spam services
regardless? "half of all advertising is wasted")
Here's my kook idea, which I believe is mostly orthogonal to other
anti-spam schemes, doesn't require a flag day, and retains the ease of
directly sending unsolicited non-bulk email:
a) filter by provenance, not by content
b) punish by wall-clock, not accept/reject
That is, if one is accepting mail from a relay which one trusts to be
largely ham, let the TCP connection run full bore (or at least as fast as
one can scan and queue the incoming mail to disk), otherwise, crank down
the window to rate-limit the connection. A normal ISP will be well-known
(at least in their peer group) to send mostly ham. A normal end-user
sends mail through their ISP. An end-user who submits mail directly to
the addressee's server would be unknown, but unlikely to care that their
personal mail takes 5 or 10 minutes instead of a fraction of a second. A
botnet, on the other hand, becomes effectively two or three orders of
magnitude smaller, and buying a big pipe won't help direct spammers unless
they can launder it by feeding into a much bigger ham stream -- otherwise
all that occurs is that the launderee's effective bandwidth goes down as
their peers match the windows offered to the level of spam found on the
feed.
(think of it being analogous to TCP with "proportion of spam" taking the
place of "dropped packets" as the metric controlling the window size)
This scheme has the drawback that it penalizes the direct sender of a
small number of large mails as well as the direct sender of large numbers
of small mails. What else?
-Dave
