The mailing list for listmasters using Sympa

[Marc Meurrens {HMp} <address@concealed>]

Hi Olivier,

Thanks for your suggestion.
All together we are near a solution...

===

Your proposals  2 and 3  may be usefull  for some  listmasters
but unfortunately cannot be used by many others.

Even, if I run my own lists, within my own domain, with my own robot :
(such as address@concealed )
I am still depending of the installation by the hoster (e.g. myunif.edu) :
- I may not even decide of Sympa version
- I may not modify the DB, etc.
- and any modification will require the agreement of all the other
   listmasters owning other lists ( such as address@concealed )
   running on the same university server. thus, a heavy process...

===

But your proposal 1 sounds really good !

And can still be improved
(removing the need for a list A appearing in our previous discussion)
Removing also nearly all drawbacks you pointed out :

<olivier>
The main drawback of this solution,
is that having 3 lists instead of one may make usual operations
like subscribing, sending, unsubscribing,
more complex from the user's perspective.
</olivier>

===

Here it is.

Suppose I have a list 'theater' (and may be also another list 'poetry')
These are the ONLY lists known by the end users.
So they include ALL the features : subscribe, post, unsubscribe, share docs, archives, etc.
In my case, these lists are mostly private and used for working groups.
However, they are not 'secret' : non subscribers may try to post some information.
This information will then be moderated.
Thus, the list are initially configurated as
'Private, moderated for non subscribers'

Now, I also have a list 'marc.moderation' which is secret.
I decide alone to add or remove subscribers.
Nobody may subscribe, post, unsubscribe.
No trafic, no archives, no shared docs, etc.
Nobody (except the owner) is allowed to do something with this list.

The only purpose of 'marc.moderation' is to hold a list
of 'non serious members'.
These 'non serious members' may eventually not even know that
they are subscribed to 'marc.moderation'
(However, for ethical reasons, I think they should receive a 'welcome'
and a 'bye-bye' message when added or removed.)

In the list 'marc.moderation' I fill-in the 'non serious subscribers' of
several lists (theater, poetry, etc) and, may be, some other people
that have now disappeared, etc (it doesn't matter).

Btw, if some members are serious about theater, but not serious about poetry,
I may create several 'moderation' lists : marc.moderation , pierre.moderation , etc

Now, in my 'real' lists 'theater', 'poetry' and others,
I modify the send scenario as listed below and suggested by Olivier.
(mind that this is for a version < 6.1 , thus 'dkim' is not present
in my scenario)

<olivier>
The scenario will have one rule for list M members that looks like this : is_subscriber('listM',[sender]) smtp,dkim,smime,md5  -> editorkey.
</olivier>

-------------------------------------------------------------------------------------------------------------------------------
title.gettext Private, moderated for non subscribers and marc.moderation

is_subscriber('marc.moderation',[sender]) smtp,smime,md5  -> editorkey
is_subscriber([listname],[sender]) smtp,smime,md5    -> do_it
is_editor([listname],[sender])     smtp,smime,md5    -> do_it
match([header->X-Spam-Flag],/YES/) smtp             -> reject,quiet
true()                             smtp,smime,md5    -> editorkey
-------------------------------------------------------------------------------------------------------------------------------

The only drawback I see is that we need to manage separately
the additional list 'marc.moderation'
The advantage, however, is that in some cases this very 'moderation' list can be
used within several 'real' lists.

===

An alternate solution could be :
- a real list 'theater' subscribed by serious members and eventually some non serious
  members (it doesn't matter)
- a moderation list 'theater.moderated' where non serious members are added.
  the moderation list being only used to store a list (and is unused to post, etc.)
- the 'theater.moderated' list is, of course, included in the 'theater' list.

The advantage (of the inclusion) could be that addresses (of non serious members)
do not need to be duplicated in both lists.

However there is an enormous drawback : a non serious member cannot unsubscribe !

===

Unless there is a way, when somebody unsubscribe (or is deleted) from list 'theater'
to automatically unsubcribe his/her from another list (in this case 'theater.moderated') ???

===

Thanks again.
As far as I am concerned, I think there is no need to fill a 'feature request'
unless Roger has another point of view ???
Regards,
</marc>

---------------------------------------------------------------------------------------------------------------------------
Olivier Salaün a écrit :

address@concealed"> Hi Marc,

That's an interresting topic you raise and it sounds like a usefull feature indeed, therefore I suggest that you submit a feature request to keep track of this in <http://sourcesup.cru.fr/tracker/?group_id=23>.
Please detail your use case, along with how Yahoo feature works. Maybe Roger can complete with a description of Mailman's 'postblock" option.

Now let's see how you can manage with a current Sympa version :

1. split your list: your idea works well, except that you can manage to send messages to list Z only; lists M and A being used for subscription only. The advantage of sending messages to list Z is that you have messages in a single list; you just need to create a custom send.privatebutmoderatefromlistm authorization scenario, based on send.private scenario. The scenario will have one rule for list M members that looks like this : is_subscriber('listM',[sender]) smtp,dkim,smime,md5  -> editorkey. The mail drawback of this solution, is that having 3 lists instead of one may make usual operations like subscribing, sending, unsubscribing, more complex from the user's perspective.
   
2. adding a custom "unmoderate" DB field to subscriber table: this would use the additional_subscriber_fields sympa.conf parameter, see <http://www.sympa.org/manual/conf-parameters/part3#db_additional_subscriber_fields>. This solution has a couple of drawbacks :

1. standard Sympa DB needs to be extended;
2. this automatically applies to all mailing list on your server;
3. the new subscriber option is not used, untill you customize the authorization scenarios;
4. the new "unmoderate" member option can be edited by listowner, from the user editsubscriber page, but it will be a text input, not a checkbox.
   

custom_attributes: Sympa provide so-called custom attributes that can be defined on a per-list basis, see <http://www.sympa.org/manual/customizing#custom_attribute>, but it lacks a way to allow provisioning to list owners only.

Marc Meurrens {HMp} a écrit :

address@concealed"> Hello all,

I am trying to solve the following problem using Sympa 5.3.4
(may be the problem is solved in version 6 and I just have to wait ?).

Suppose we have a private working group (no access to the public)
with a few owners, a few moderators (editors), 100 serious subscribers
(but not serious enough to become editors)
and 100 less serious subscribers that need to be moderated.

Is it possible to moderate some of the users but not all?
Obviously the current answer is "no".

This is however a request from people I convinced to leave
the Yahoo stuff (where selective moderation is possible)
as to reach a more respectuous service/software.

===

The only solution I found until now to satisfy them
is not really nice :

- a list M, moderated, with subscribers m1, m2, m3
- a list A, not moderated, with serious subscribers a1, a2, a3 + the list M
- a list Z, where no message may be posted, including M and C, thus m1,m2,m3,a1,a2,a3

when m1 posts to M, the message is moderated. If the message must
be accepted, the editor MUST TRANSFER MANUALLY the message to list A
and, btw, specify in some way (e.g. a CC) that the original author is m1.
the message will then also reach list M (but without a reference to
the original author m1)

when a1 posts to A, the message is sent to M automatically
BUT m1,m2,m3 will ignore that the original author is a1
and will thus not be able to reply directly to a1 if needed.
THIS IS A REAL PROBLEM.

hopefully, archives are nearly identical on A and M,
except of course the matter of the original author.

list Z is only devoted to hold the shared documents
assuming that both the serious and the less serious
subscribers have the same rights.

===

Any idea?
Any project to build a better solution?

--
Marc Meurrens
☎ +32 475 46 28 12