oss-sec mailing list archives

Re: list: members vs. read-only subscribers


From: Josh Bressers <bressers () redhat com>
Date: Mon, 07 Apr 2008 13:35:53 -0400


It appears that Josh and Vincent have expressed the same opinion in the
quotes above.  Unfortunately, ezmlm-idx does not have a notion of having
different types of subscribers to a list - "members who can post" vs.
"read-only subscribers".  Yet, if this is really what we want (any other
opinions?), we may be able to achieve it in one of two ways:

1. Use the "allow" list feature to specify the addresses of "full
members".  Unfortunately, in my experience the "allow" list is used for
lists that are moderated for non-subscribers only (to allow some
non-subscribers or alternate addresses of subscribers to post without
moderation), not for those that are also moderated for subscribers.
I have not looked into whether this would be easy to fix or not - but I
or someone else at Openwall can look into it if needed.  It might turn
out that the fix is trivial.

2. Setup a second list for the read-only subscribers, and subscribe that
list to the main one.


Here is my proposal, technical issues aside (we are smart people, we'll
figure something out).

* The current member list can post unmoderated
* New subscribers (anyone can subscribe) will be moderated by default, but
  can have the moderation flag lifted when the prove to be useful
  contributors (we need to define what a useful contributor is)
* Non members can post, but will be moderated (if spam is an issue, we
  could consider just throwing this stuff out, but I'd really like to avoid
  it if possible)

I think that this should appear as one list to the end user.  If we end up
using some bizarre solution with multiple lists to work around the
ezmlm-idx shortcomings, we need to ensure that this is not obvious to the
end users.  Users should be able to hit reply and the right thing just
happens.


For the wiki, I'd say just make it a free for all.  If they take the time
to create an account, let them make changes, we'll keep an eye on what gets
modified.  We can deal with spam if it becomes a problem.

If you don't like this, speak up now, otherwise, I think it would make
sense to find a solution that fits this model.

-- 
    JB


Current thread: