In article <[log in to unmask]], Nick Laflamme <[log in to unmask]] wrote: ]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: OPTION 1: ] ]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? Yes. OPTION 2: ]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) that can very well be an option. I wasn't thinking on these lines. ] ]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. I say, flush the notes within 12 hrs or less, in both cases, option 1 & option 2. Like subscription=confirm are within 48 hrs, usually. ]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!