If I read your suggestion correctly, Asim, you want LISTSERV to send the list editors to confirm all notes they approve by repeating back to LISTSERV a randomly generated token for each note they approve? This would lead to the sequence: 1) user sends note to list 2) LISTSERV sends note to moderator 3) moderator sends note to list 4) LISTSERV sends token to moderator 5) moderator echoes token to LISTSERV 6) LISTSERV distributes note Where 4) and 5) are the new steps for increased security? Or maybe you want LISTSERV to send the token and remember the note so the editor always sends the token back, not the note, but the editor has the note so s/he can discuss it with the original author if needed? 1) user sends note to list 2) LISTSERV sends note and token to moderator 3) moderator echoes token to LISTSERV 4) LISTSERV distributes note (which it had kept a copy of) I presume you would also provide a "veto <token>" command so the editor can tell LISTSERV that it's OK for it to forget a submitted note? (This would be an alternate 3) above.) Such a change would seem to take a lot of overhead in the server, and it would be a big pain for casual list owners who aren't really interested in LISTSERV; things would change for not much apparent reason. I suppose there could be an old compatibility mode as well as a new Send=TokenApproval option, but there's still the overhead issue. Then there's the case when a list owner sets up a list for TokenApproval and then refuses to approve or veto messages. Does LISTSERV automatically flush notes which haven't been approved or vetoed ("pocket veto"?), or does LISTSERV die as pending notes fill up the disk. Even if you don't have LISTSERV remember all the pending notes, it has to remember the list of pending tokens and what lists they correspond to. Otherwise, if someone captures a valid token, you're back to being exposed to forgeries and misconfigured e-mail like you experienced. I'm not saying that this is an unsolvable problem, merely that it's not cheap to implement as far as I can tell. Nick -- * [log in to unmask] * ------ * Come to the 1994 VM Workshop: June 7-10 at the University of Notre * Dame! User Experience talks, dialogues with IBM, and presentations * from other vendors in an informal setting. Contact me or sign up for * [log in to unmask] for details!