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