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!