Subject: [Asrg] alok - penny black variation

From: Alok Menghrajani <[email-masked]>
Date: Sun, 4 Jan 2004 15:34:22 +0100 (MET)

Hi,

I have been thinking about designing something like penny black for a long
time, but I never really had the time to do anything serious. Anyways, I'm
now motivated to work on my idea, and I would like to have your comments
on this matter. (I really don't want ms designing this kind
of stuff, they have done enough harm to the world).

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).

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

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.

Alok Menghrajani
[email-masked]
[email-masked]

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Denny Figuerres" <[email-masked]>
Date: Sun, 4 Jan 2004 10:46:48 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alok Menghrajani
> Sent: Sunday, January 04, 2004 9:34 AM
> To: [email-masked]
> Subject: [Asrg] alok - penny black variation
> 
> Hi,
> 
> I have been thinking about designing something like penny 
> black for a long time, but I never really had the time to do 
> anything serious. Anyways, I'm now motivated to work on my 
> idea, and I would like to have your comments on this matter. 
> (I really don't want ms designing this kind of stuff, they 
> have done enough harm to the world).
> 
> 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.
> 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). 

While I understand your thoughts on this I do not belive this group has any
interest in
Any kind of "replacement" of SMTP as such.
Please read the archives of perior email on this and the issues will be
spelled out in them.

As Far As I know / Understand this group is interested in methods to
suppliment SMTP and possibly add features to it that do not "Break" current
SMTP servers. This is difficult to do, but is more realistic today than
replacement.

But I do say that *IF* things do not change for the better there will be
more folks who say "can it and start over"
But to do so would create huge problems... 

> 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:
...
> ...

---

From: Philip Miller <[email-masked]>
Date: Sun, 04 Jan 2004 19:28:59 -0500

> (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.

> 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.

> 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

---

From: [email-masked]
Date: Tue, 06 Jan 2004 22:47:06 -0600

> 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.

I proposed something like this ("...it could be as simply as passing 
the sender a product of primes, etc. and demanding that he factor 
them before accepting the message. ") not quite a year ago in message

https://www1.ietf.org/mail-archive/working-
groups/asrg/current/msg00989.html

There apparently is some reason why this solution won't work, however 
(I'm not sure what the issue was, but I received private replies that 
insisted that the solution was unworkable, and the proposal itself 
was generally ignored).

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 07 Jan 2004 12:17:33 +0000

>insisted that the solution was unworkable, and the proposal itself 

"SMTP clients and servers MUST support the original HELO mechanisms as a
fallback." - rfc2821

So you can expect objections to proposals based on extensions.

And besides, the penny black stuff aims (I've I've read it right) to set a
problem which isn't purely CPU (or math co-processor) bound. However, all
proof-of-work schemes have the drawback that they assume "work" is
expensive for the spammer. This assumption is invalidated if the spammer
commands a large numder of slave machines. Or buys a crypto card.

I think that's a fair summary, I'm sure anything I've missed can be found
in the archive.

--

---

From: "Viktor S. Grishchenko" <[email-masked]>
Date: Sun, 18 Jan 2004 16:44:14 +0500

Alok Menghrajani wrote:
> time, but I never really had the time to do anything serious. 

http://www.nd.edu/~parasite/

Try to explore possibilities of parasitic computing in pennyblack email 
networks. It is an interesting objective.

-- 

	Viktor S. Grishchenko