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?