The mailing list for listmasters using Sympa

["e.c." <address@concealed>]

David:

Thank you for your prompt answer. See below.

On Thu, Jun 26, 2014 at 8:32 AM, David Verdin <address@concealed> wrote:

Hi Ed,

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

David and Sympa dev:

On Thu, Jun 26, 2014 at 2:41 AM, David Verdin <address@concealed> wrote:

Indeed,

You can also use the "nrcpt_by_domain.conf file. It defined specific limits for some domains. If you fill this file with the following lines:

domain1.tld    3
domain2.tld    25

Then you will have only three users per session for domaine1.tld and 25 per session for domain2.tld.

Th 6.0.1 is rather old now. If you considered upgrading to the 6.1, you could have the delivery_time list parameter. It is not exactly what you want but you could tell ,using this parameter, that a message for a given list will not be sent after the time you define for this parameter.

But the MTA solution will work well, too.

Regards,

David

​ I am using ver. 6.1.7 (owner not listmaster) and under customization option I see:
"​

 

​ Rejection message: when a message is rejected by list editor, a notification can be sent to the original author. You may prepare various rejection messages."

Does 'list editor' here mean owner or moderator?

The moderator. If no moderator is defined in list, then it is the owner.

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.​

 

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. How this could be done, I have no idea (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.

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).

Thanks again for you prompt attention to my concerns.

Ed

​

To contribute: for now, send us a patch (address@concealed). Later, you will be able to use git - we will switch to git this year.

Best regards,

David

Thank you,

Ed

p.s. Is there any interest in doing a fork of either Sympa or Mailman in order to implement this functionality along with some other things useful to a self-moderating  list?

Le 26/06/14 04:12, Matt Taggart a écrit :

Marco Gaiarin writes:

I'm using sympa 6.0.1 (debian squeeze), and i need to setup, for only some
lists, some ''draconian'' send limit (eg, 50 recipient every 5 minutes).
The list are internal one, and the culprit is that all recipent have the
same domain/destination server, so sending to 600 recipient (even breaked in
50 recipient per smtp session) will hog the destination server.

You might consider doing this in the MTA with a "slow" transport.
For example in postfix look for "slow" in the following docs

  http://www.postfix.org/transport.5.html
  http://www.postfix.org/QSHAPE_README.html

--
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