ietf-asrg
[Top] [All Lists]

[Asrg] spam-shake: an anti-spam e-mail protocol

2003-03-18 15:42:35
Hi all.

This is to describe an anti-spam protocol that might be implemented via 822 
mail headers without requiring changes to mail transfer protocols.

A sends a message to B.  B sends it back to A, whereupon A resends the message 
to B.  The result: B receives A's message, and A learns B's spam code.  Spam 
code?  Spam codes are alphanumeric strings included in the message header that 
enable the receiving mailer to accept mail from an unrecognized sender while 
rejecting unsolicted mass mailings.  The three-way handshake, although it 
replaces one mail send with three, needn't be an onerous imposition on senders 
generally, since it need occur only on a first-time mailing to propagate the 
spam code, and thereafter only when the receiver changes his spam code.

But the spammer, assuming he doesn't already know the codes, will be obliglied 
to receive and process replies from each recipient in order to learn them.  
This is scarcely practical.  Neither is it possible to assemble spam code lists 
in same way email lists are compiled, because users can change their spam codes 
at any time, and the changes are automatically learned by those senders who do 
receive and process replies.

The proposed implementation contemplates a new header line, called a spam line, 
to be included with the other lines of the standard RFC 822 mail header.  The 
format & usage follows:

Spam: Send spam-code
Spam: Reply spam-code

In the exchange that follows, A sends a message to B.  A doesn't know B's spam 
code, and so uses his own code.  B notes that A has supplied a incorrect spam 
code, and so sends the message back, with the spam line changed to a Reply and 
listing B's correct code.  A resends the message with the correct code.

1. Spam: Send A-spam-code
2. Spam: Reply B-spam-code
3. Spam: Send B-spam-code

Here's the decision psuedo-code. Note that users can change spam codes in the 
course of the handshake, so messages could be repeatedly returned.  Also, 
messages without spam lines are returned to sender by adding a spam line, and 
requesting the originator to resend the message.

if Spam  { /* Spam line is present */
    if Send {
        if message-code is my-code
            accept message
        else
            Spam: Reply  my-code
        return
    }
    if Reply {
        Spam: Send message-code
        return
    }
    /* invalid spam line */
    return
}
/* didn't have a spam line; must be from non-shake mailer */
Prepend a "please resend this message" to message body and...
Spam: Send my-code

I don't believe it's necessary to overhaul the Internet architecture just to 
deal with spam, when all that is truly required is a procedure to handle 
messages from unrecognized senders with unfamiliar subjects.  So my thought is 
that this strategy could be implemented by your mail user agent, after 
filtering for subscribed lists and other mail that you do want to receive, and 
would never need to reject.

Lee Murach
lemur(_at_)codemode(_dot_)com
<Prev in Thread] Current Thread [Next in Thread>