Hardening lists against spam attacks

[Anonymous]

Bill Frantz writes:

[snip lots of good ideas about token distribution]

A very good scheme, but why not give each subscriber a token when s/he
subscribes? Something along the lines of:

- - - - - - - - - - - - - - - - - - - -
Welcome to Cypherpunks.

Your unique token is: 0A553FC1771623109504522E31C07F44

This token must appear either as the first line of the message body or in an
X-Token: header for any mail you send to the list. Any messages sent to the
list
address without this information will be discarded.

Your token is initially good for <n> postings per day.
- - - - - - - - - - - - - - - - - - - -

Generate a token thus:

Let X be some known information like the From: line of a subscriber's message.
Let T be some unique information for each subscriber, like the exact time that
Majordomo processed the subscribe request.
Let F be the contents of some (non-changing) file on the machine running
         Majordomo (a "secrets" file).

Use a hash function H(X+T+F) to generate your token. Store the token, the
unique information (time, in my example) and the number of posts allowed per
day in a file you can use to validate user requests.

Every time a user sends mail to the list address, Majordomo checks for a token.
If there's a valid one, it strips it out and distributes the message. Otherwise
it throws it away. This way no one else sees which token was used to post a
message.

Alice posts all the time using her real name. She just sticks her token in the
first line of her post. Majordomo sees it, validates it, and strips it out
before passing the message along. It decrements Alice's remaining message count
for the day.

Bob wants to post something anonymously. His token isn't associated with his
user ID -- the only thing Majordomo knows about it is that it's in the token
file and it's flagged as active. He sends the message through the remailer
network with his token in it, and Majordomo validates it, strips it out, and
passes the message to the subscribers, decrementing the number of messages Bob
has remaining for that day.

Charlie wants to unsubscribe from the list. He sends an unsubscribe message to
majordomo with his token in it. Majordomo uses the known information (his
"From:" line in my example), plus the time it kept from when his token was
generated and the secrets file to validate his request. If it matches up, he's
unsubscribed and his token's invalidated; if not, he's warned that someone else
tried to unsubscribe him. (In order to allow people whose tokens have been
invalidated to unsubscribe, don't make sure the token is valid -- just that it
matches up with the user.)

Mallory wants to spam the list. He subscribes and gets a token, which he
uses to
forward commercial announcements to the list. The list manager checks the logs
to see which token was used, and reduces its posting limit or invalidates it.
Mallory is no longer allowed to post, unless his token is reinstated (or he
unsubscribes and resubscribes).

Majordomo also has to keep track of how many posts have been associated with a
token in any give day, but that seems like a small problem. Users could appeal
to the list admin if they wanted a higher limit than the default. Keeping the
number fairly low also discourages protracted flamewars somewhat.

This isn't an extremely "hard" mechanism (I know it's still vulnerable to
eavesdropping attacks), but it'd preserve the ability to post anonymously and
make it tougher for spammers to decrease the S/N. Abusers would have to
unsubscribe and resubscribe repeatedly to get new tokens, which would make
them easier for the list admin to track down.

Thoughts?