[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20306.1207589753@devserv.devel.redhat.com>
Date: Mon, 07 Apr 2008 13:35:53 -0400
From: Josh Bressers <bressers@...hat.com>
To: oss-security@...ts.openwall.com, Solar Designer <solar@...nwall.com>
Subject: Re: list: members vs. read-only subscribers
>
> 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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
