In my own examination of spam systems, I have grouped them into a few
classes,
as far as software is concerned.
a) Some require new software only at the recipient. These can most easily
be
adopted, one user at a time. However, there are limits on what they can
do.
There are also political problems (blacklisting falls in this category.)
(Almost all solutions require some new software at the recipient end but
it
can be gradually installed in all proposals I have seen.)
b) Some also require new software by legitimate bulk
mailers. I consider this a difficult, but attainable task, since the
numbers
of such mailers are (comparatively) few compared to the number of users of
all mailing software.
c) Some ask for new software at senders, but do not demand it. They have
a fallback if the senders don't have the software. The fallbacks range
from
easy to use to hard, and the risk of lost mail varies accordingly. They
don't want the fallback to be too easy because they want pressure on
senders
to adopt the new protocol, and don't want it to be too hard or too much
mail
is lost.
d) Some ask for new software for spammers (for example labelling
requirements)
and hope that legal means (such as Lessig's bounty proposal) can force
spammers
to run this software. Good luck!
e) Some demand new software at senders, such as stamp generators,
certificates,
etc. They plan to, at least eventually, insist on it or refuse mail.
f) There has been one case where a software change has been demanded of
senders,
namely the closing of open relays. Though it has taken several years,
most
open relays are closed, but not all of them. There was considerable
pain.
My experience of the history of deploying software suggests you will
easily
get recipients to install new software if it cuts back on their spam well.
Demands on senders are extremely difficult, especially on MUA senders.
Changes
to MTA senders can happen gradually over the course of perhaps 5 years
under
extreme pressure, with pain and dropped mail.
Do any disagree with these conclusions?
There is also some work involving "tarpits" done by Marty Lamb at
http://www.martiansoftware.com/tarproxy
In my opinion this would fall somewhere in the middle of all the options
listed above, and it might actually have the greatest chances of success, as
it doesn't require the cooperation of anyone in particular. As outlined
above, if enough are spread around, pain would start to be felt and
sysadmins will sit up and take notice.
A short description of the principle, in the words of its author:
********************** start quote
"An email message would be fed to the incremental classifier one piece (or
token) at a time. After analyzing each piece, the classifier would respond
with a classification of the message so far, providing a running probability
that the message is spam.
Now imagine that your SMTP server has been provided with an incremental
classifier. You now have a real-time indicator that a message is likely spam
while the spammer is connected.
The Idea
Now we have moved identification of spam to the time of its receipt. But how
can the SMTP server best use this knowledge? I propose that the running
probability from the classifier be used to throttle the connection with the
offending server. If an incoming message looks like spam [1], the connection
could be slowed dramatically, consuming the spammer's resources and wasting
their time [2]. This would transform the server into a sort of dynamic
tarpit, in which the spamminess of the incoming message affects the
viscosity of the tar [3]. As the spam probability goes up, the socket speed
goes down [4].
If enough of these dynamic tarpits were in place (or just a handful were
placed in the right places), the spammers' mail software would bog down,
reducing the rate at which they can send messages, in turn reducing the fees
they can charge their customers. If these tarpits were ubiquitous, they
could completely change the economics of spam, creating a scarcity of
bandwidth experienced only by spammers."***************************** end of
quote
Regards
Teo
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg