Eric,

Thank you very much for your clarification of this. It makes the issues 
much clearer.

Both cases 4 and 6 would be very useful to us.  The lists I'm 
responsible for (on four different servers) are mostly small lists for 
fairly close-knit communities of participants. We have *never* had an 
incident of someone forging an editor address to post to one of the 
lists. The volunteers who serve as editors of these lists resent having 
to confirm their own messages. If we ever have an incident of a forged 
editor address, it would be easy to explain to the subscribers and then 
we could switch to editor confirmation.

Our big problem is that some of our list addresses have appeared on web 
pages and have been picked up by spammers. We are getting hammered by 
the ads for Viagra and easy college degrees. We want to be able to 
require confirmation from non-members so that our editors don't get all 
the spam to review.

--Dan


Eric Thomas wrote:
> The problem with the "unintuitive" nature of posting confirmation is that
> the syntax is overloaded, ironically to make things simpler for novice
> users. The syntax works fine with non-moderated lists, because there is only
> one confirmation (by the poster) and the "Confirm" option is only used for
> one thing. Even if the poster is on REVIEW and the message goes to the
> editor, by definition the editor is a third party and there can be no
> argument that the poster's confirmation should also have counted as the
> editor's.
> 
> For a moderated list, there are two confirmation steps: by the poster before
> the message goes to the editor, and by the editor. The poster confirmation
> could potentially be for nobody, for everybody, for non-members only, and
> for non-editors only. The editor confirmation is a simple yes/no switch. So
> we have eight possibilities, which actually reduce to six in practice:
> 
> 1. NOBODY/NO: "Send= Editor".
> 
> 2. NOBODY/YES: "Send= Editor,Confirm". "Confirm" applies primarily to the
> editor - the person causing the message to be actually posted.
> 
> 3. EVERYBODY/*: "Send= Editor,Confirm,All". The second confirmation setting
> is immaterial since "everybody" includes the editor.
> 
> 4. NON-MEMBER/NO: cannot be done.
> 
> 5. NON-MEMBER/YES: "Send= Editor,Confirm,Non-Member".
> 
> 6. NON-EDITOR/NO: cannot be done.
> 
> -. NON-EDITOR/YES: same as case 3 since, in the end, everybody ends up
> confirming.
> 
> To enable cases 4 and 6, you would need something like:
> 
> * Send= Editor
> * Confirm-by-Poster= ...
> * Confirm-by-Editor= ...
> 
> The downside of course it is that it is three keywords instead of one. What
> you would gain primarily is case 4 (the usefulness of case 6 is debatable
> since it is false security). All this being said, few people turn off editor
> confirmation nowadays, because any subscriber could then spoof the editor's
> address and post whatever he wanted.
> 
>   Eric
> 

-- 
                                     Peace,  Dan

=>  Daniel D. Wheeler - Education & Psychology, Univ. of Cincinnati
==>  Email: [log in to unmask]      URL: http://wheeler.uc.edu
===>  KIDLINK: http://www.kidlink.org