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

From: "Lee Murach" <[email-masked]>
Date: Tue, 18 Mar 2003 14:29:30 -0800

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
[email-masked]

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 18 Mar 2003 14:39:05 -0800

Something similar has already been discussed around 1000 messages
ago under the term "Cookie".

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

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 18 Mar 2003 23:49:33 -0500

At 2:29 PM -0800 3/18/03, Lee Murach wrote:
>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

Is this implemented in the MTA or the MUA?  If the MTA, then what 
happens when the spammer sends using a real return address (say a 
temporary hotmail account, or that of an innocent bystander)?

Temp account case:
A sends to B with own spam code
B returns to A asking for a resend with the new code
A resends with new code.

Forged account case:
A sends to B with fake spam code
B returns to A asking for a resend with the new code
A gets the message and does one of two things
1. tosses the message because it's a resend request with the wrong 
code--unfortunately that would mean that you couldn't change your 
code without first making sure that all outstanding email had cleared
2. sends mail to B asking for a resend with the real code - then the 
protocol continues until the message gets through.

And of course it really is a change to the protocol at that level, 
since it drastically changes the behavior of the MTA.

If it's implemented in the MUA then this essentially becomes a 
challenge response system (without the need to prove that the remote 
sender is a human being).

In either MUA or MTA case, you clearly can't do the auto-reply until 
you see mail with the Spam: header.  Anything else won't properly 
respond.  So you have to let it through without challenging.

Now we apply the patented "where's the incentive" test.

1% Adoption - the spammers clearly don't use the header.  None of 
your friends use the header.  So you still get as much spam as ever.

10% Adoption - the spammers don't use the header.  Most other people 
don't use the header, so you still have to accept email from 
spammers.  However you do now have some friends using the header, and 
initial conversations with them are slower.

So.  Not a huge amount of pain to use.  But no apparent benefit until 
90% of your correspondents are using the system and you can safely 
shut out the rest.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg