Alok Menghrajani wrote:
Before I begin, I would like to thank Marty Lamb (www.martiansoftware.com)
for all the emails we exchanged together. He has developed a very
interesting anti-spam method (called tarproxy), which inspired me a lot.
(You should checkout his website if you have never heard of tarproxy).
Was that one of the systems discussed on the SpamIdeas conference discussion
list? I didn't follow it too closely, although I may now give it a second
glance.
For several reasons, I think it would be good to define a new email
protocol (this way we can fix a lot of things that weren't quite right
with email, but that's a whole different discussion). The protocol would
work like this: sender connects directly to receiver's server, does a
processor intensive calculation, if sucessful the server will accept the
email. All this is similar to penny black, and presents one major problem:
what about mobile devices, pda's, mailing-lists, etc...
So here is my solution: when the sender connects to the receiver's server,
the server will use a baysien filter to give a score to the message. This
score can be given in a 'dynamic way', that means it can change as the
message is being received (you split the message and run each part through
the filter). Depending on the score the message (or part of message) gets,
the computation will be 'easy' (short) or 'difficult' (long to perform).
So here is an example of what a communication would look like:
Sender: connects to receiver's server.
starts sending "hi, how are you..."
Server: ok, this looks like 'legitimate' mail
Sender: "i would like to propose you this new
viagra..."
Server: stop, that's spam. Server sends the sender a large number
This proposal doesn't require a new protocol. An ESMTP extension would do
just fine. I think we should kill two birds with one stone: implement an
extension in which the receiving server picks 2 primes of sufficient length,
multiplies them, and asks the sending server to factor them. Multiplying big
numbers takes much less computational effort than factoring them, so this
moves some of the cost burden to the sender.
For now, that would force spammers to slow down significantly. On the other
hand, it may lead to spammers solving one of the greater mathematical
problems of our day. If they can figure out a better way to factor big
numbers, the face of public key cryptography may change quite a bit.
One of the questions I need to be answered is: will we need one filter per
server, or one filter per user ? If it is one filter per server, then we
must take into account that a server might have users speaking many
different languages (something which is also true in the one filter per
user case), and the users can be 'interested' in very different topics
(their day to day emails can be of completely different topics).
I think this method presents one really good point: the filter never
creates false positive, since you will always receive the mail.
We could also combine all this with whitelists (since most servers already
allow users to have their address book online). But whitelists presents
the problem of identifying the sender.
I think this is a good proposal. It's not a major overhaul to exisitng
protocols, it can be phased in slowly, it puts costs where they belong, it
prevents offline precomputation before the mailing begins, and it's
compatible with whitelisting techniques. There is a downside, however, that
legitimate bulk senders would be heavily burdened by this, while spammers
can continue to hijack machines to do the dirty work.
What we really need to do is hinted at in your message:
1. Verify that the machine connecting to us is who it claims to be
2. Verify that the sender claimed is the actual sender
3. Limit the servers mail will be accepted from to systems whose owners
think should be sending mail
4. Move some cost burden from receivers to senders
Finally, I would add the following:
5. Try to move as much legitimate bulk messaging away from email as
possible, to something else
If we take the simplest steps down each of these (mutually compatible, I
think) paths, we'll be well on the way to eliminating spam.
Philip Miller
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg