The mailing list for listmasters using Sympa

[David Verdin <address@concealed>]

Le 26/06/14 16:29, e.c. a écrit :

David:

Thank you for your prompt answer. See below.
You're welcome! :-)

Is this list editor function programmable or does it require manual intervention?

What do you mean "programmable"?

​ I was hoping that postings could be counted (within a 24 hour period) from each subscribed email address and then all attempted postings could be rejected from subscribers that had reached the threshold.​

 

Well almost...
In Sympa 6.2, we store several data used to display statistics. Among them is the number og messages posted by a user. Sadly, we don't store it within a temporal window but simply the whole total of messages posted. That's an interesting feature. It whould be short to change, I think.

Are any exploits possible here?

No. We just include the message in a notification template. we don't process it. So whatever the end user wirtes, it won't affect the system.

I first requested (both from Sympa and Mailman) a feature that would limit postings per member and per list in a 24 hour period (say 0:00 to 24:00 gmt (utc), say 6 per member and 60 per list). This functionality was already present in LISTSERV in 1996.

That's quite an unusual request. Most of the time, people tend to find solution to give maximum freedom to end-users and let the system handle the rest.
What exactly is the problem with letting users post whatever they want to the list? We have a public list service with around 700 lists scaling from 5 to 20 000 subscribers and did not have any troubles with it.

​ It couldn't have been that unusual for the LISTSERV users of the last century. My rationale is precisely to give maximum freedom of _expression_ to list members but due to the sui generis nature of the list in question it is necessary to treat excess postings as 'flooding.' ​

  ​ Also it is important that there be no moderation of the list, even by list owner(s). Since I am not a programmer, I am not even sure how  certain badly needed ​functions should be implemented but I am fairly certain that they are 'computable' in a formal sense. For example, I would like each member to be able to issue a command like:

-address@concealed

to the sympa, mailman server and thereafter not to receive any postings from that list member. This command could even serve as a pro rata 'vote' to further reduce 'flamer's daily quota of postings. Heh! Nice feature! A kind of "ignore list" for mailing lists.

How this could be done, I have no idea

I do. :-P

(or even whether it is part of the mailing list program, the MTA, or whatever). The main point here is that at least for this sui generis list, the paternalistic moderated list model is quite intolerable. I appreciate how strange this must sound to the average list master or owner but I can assure you based on about 18 years of experience with this list that what I describe is something that will have to be implemented sooner or later.

I see.
You could add a link at the end of each message loloking like:

http://your.sympa.server/listname/ignore/sender.encoded.email@address

Clicking this link would prevent you from receiving any mail from this address. We do this for unsubscribing from lists  - or even from whole list families.
Of course, this feature should be explicitely activated - in most lists in enterpise, people are not allowed to ignore what their colleagues have to say (a shame if you ask me).

The problem seems to be that the bulk of development effort is dedicated to features important to pollsters and admen (lists with 700,000 members) rather than to unmoderated discussion lists​ with 70-700 members.

False impression. Sure, on the Sympa web site, we tend to stress out the fact that Sympa is globally scalable because it is widely used as a large scale.
However I - and the other Sympa authors share my point of view - certainly don't want Sympa to be restricted to such usage. Sympa must remain usable on a single machine with an average configuration without all the fancy connection with the information system used in entrerprises - and without a MySQL cluster.

​ I am not surprised that I am laboring under a false impression.​

  ​ See below.​

Consequently: no, it is not necessary to fork. Please, contribute instead. We will gladly accept contributions - but don't forget that we need to review your code and try to make it fit in the Sympa big picture, so integretion is not instantaneous.

​ Unfortunately I am not qualified even to understand the workings of your program, much less to contribute code. I downloaded the source for both mailman and sympa and tried to learn a little Python and Perl but​

  ​ m​ ​y cognitive style seems to be more synthetic rather than analytic (I wrote a few Qbasic programs back in the 80's that were useful to me but I couldn't ​seem to ​ wrap my mind around C even though​ ​ I immensely enjoyed the Kernighan and Ritchie book, more as a piece of fine exposition than a language manual).
Well, just wait until we issue the 7.0 version. Fully refactored code, much more understandable. You may have a different opinion about your capacity to contribute. Later this year, follow up!

Thanks again for you prompt attention to my concerns.

Well, I noted the idea, but I can't promise it will be implemented soon. We still have a lot on our plats for the coming year or so.
So well, be patient - except if the list's vox populi tells us this is a crucial feature for a lot of people.

Best regards,

David

--
A bug in Sympa? Quick! To the bug tracker!

David Verdin Études et projets applicatifs
Tél : +33 2 23 23 69 71 Fax : +33 2 23 23 71 21   www.renater.fr	RENATER 263 Avenue du Gal Leclerc 35042 Rennes Cedex

Attachment: smime.p7s
Description: Signature cryptographique S/MIME