Mailman 3 June 2018 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett 07 Nov '22

07 Nov '22

Hi. There's a fairly simple problem here that needs to be addressed. And it's mostly a documentation/install problem. I'm hoping we can get this resolved before the next release. PROBLEM: Mailman comes out of the box ready to backscatter spam people. Yes, it's easy enough to fix. But because it comes stock this way, and is documented to install this way, most people install it to do this. Those of us who work in abuse departments are tired of hearing "well that's how Mailman works". We also object to having to teach people how to fix their mailman installations because it's not documented in the current manual. This is *exactly* like Sendmail 14 years ago. We didn't accept it then, and Sendmail fixed the problem. RESOLUTION: Mailman default installation should not backscatter in a default configuration. 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by default. Nearly everyone uses web based signup. 2. Discard or hold messages from non-subscribers by default. I would think that it would be perfectly reasonable to have documentation on how to enable the 1980s-style -request / -subscribe etc aliases. However this documentation should have a note that this is against the AUP of nearly every network provider, and enabling it will likely cause them to get listed in various blacklists as a backscatter source. FYI: I know that this goes against the instincts of many old-time mailing list advocates here. But after dealing with a 10k/hour backscatter DoS my tolerance for this problem is understandably limited. Yes, it was a sweet day back in the 1980s. I was running a mailing list server and several UUCP gateways at the time, so I remember them well. But those days are past, and we need to deal with the reality of today. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

21 168

Mailman 2.1.27 released
by Mark Sapiro 02 Jul '18

02 Jul '18

I am pleased to announce the release of Mailman 2.1.27. Python 2.6 is the minimum supported, but Python 2.7 is strongly recommended. This is a routine bug fix release with a few new features and some minor security enhancements. See the attached README.txt for details. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see our web site at one of: http://www.list.org https://www.gnu.org/software/mailman http://mailman.sourceforge.net/ https://mirror.list.org/ Mailman 2.1.27 can be downloaded from https://launchpad.net/mailman/2.1/ https://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 2

Mailman 3.2 coming up soon
by Abhilash Raj 29 Jun '18

29 Jun '18

Hi All, I am going to release Mailman 3.2 next week. which is going to include new releases for all components, including Postorius, Hyperkitty, Django-Mailman3, MailmanClient and finally Mailman Core. Note that all of these are now Python 3 only and support Python 3.5+. There already is a very long list of new features and bugfixes in these releases, but if someone wants me to look at some last minute bugfix that you want to get-in, let me know. -- Abhilash Raj maxking(a)asynchronous.in

1 0

Re: [Mailman-Developers] Mailman3 access with a screen reader
by Mark Sapiro 13 Jun '18

13 Jun '18

On 06/12/2018 02:30 AM, Andrew Hodgson wrote: > > Just starting to move lists that are mostly used by blind people to Mailman3. One thing we have found is that when tending to moderation requests, if you view the message in the web interface it seems invisible to screen readers when the message is viewed on screen. The window that comes up with the message and the buttons doesn't seem to read out for some reason using Chrome or Firefox with the latest version of Jaws. During the last PyCon sprints we did some accessibility testing and made some changes, but I don't know if we looked at that specific area. @Terri is the one who was working on this. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Re: [Mailman-Developers] Mailman3 access with a screen reader
by Geoff Shang 13 Jun '18

13 Jun '18

Hi Andrew, On Tue, 12 Jun 2018, Andrew Hodgson wrote: > Just starting to move lists that are mostly used by blind people to > Mailman3. One thing we have found is that when tending to moderation > requests, if you view the message in the web interface it seems > invisible to screen readers when the message is viewed on screen. The > window that comes up with the message and the buttons doesn't seem to > read out for some reason using Chrome or Firefox with the latest version > of Jaws. I have to confess that I've not yet played with Mailman 3. :( Have you tried with NVDA? It should of course work with JAWS, but I have seen situations where one screen reader sees what another does not, and NVDA costs nothing to try. Also, it's a good idea to give specific version numbers instead of "latest", as "latest" doesn't mean much in six months time. Also, browser versions as well. Cheers, Geoff.

1 0

Mailman3 access with a screen reader
by Andrew Hodgson 12 Jun '18

12 Jun '18

Hi all, Just starting to move lists that are mostly used by blind people to Mailman3. One thing we have found is that when tending to moderation requests, if you view the message in the web interface it seems invisible to screen readers when the message is viewed on screen. The window that comes up with the message and the buttons doesn't seem to read out for some reason using Chrome or Firefox with the latest version of Jaws. Has anyone looked at current access with a screen reader with the web interface? It mostly seems to work well. Thanks. Andrew.

1 0

Questions around mm3 plugins/templates
by Andreas Zoellner 08 Jun '18

08 Jun '18

Hello, I am looking into expanding Mailman 3 with a plugins for our use case. I’ve read through the documentation but have a couple of clarifying questions that I’m hoping to get answers for here. 1a) Can I provide templates to generate text/html messages or just plain/text? 1b) if not, would that be something that could be added with a plugin or is that better handled in core? 1c) Can a html template be introduced for a third digest type in addition to mime and plain? 2) Can a template change the subject line or just the body? 3a) Can a plugin add additional fields to a user? e.g. I want to store more specific preferences around topics or maybe day of week for digest delivery or a user title 3b) Can I easily pass those additional fields to a template? 4) How can mm3 be scaled horizontally? Let’s say I have an additional rule that takes a long time to process - Can I parallelize that step somehow? Thank you Andreas

1 0

Idea of subscription options (beside Digest)
by Garreau, Alexandre 02 Jun '18

02 Jun '18

In case you were lacking useful high-level features idea, while arguing recently about good netiquette of citing, not citing, puting or not puting original sender in this or that header, and also less recently about who to exclude/censor/ban or not from a mailing list, I found some that might be useful so to standardize mailing lists working per user instead of per mailing-list, so at subscription propose potential following options, beside “Digest mode”: “Don’t send me mail with ‘X’ and ‘Y’ CW” (CW = content-warning): X being either specified in subject line (more accessible) such as “[CW X, Y]”, or in a specific header (more discrete) such as “X-Content-Warning: X, Y”, where X and Y are tags/abbreviations such as “sex” (for sexually-explicit)/“nsfw”, “politics” / “sexism” / etc. (more shocking or offending stuff), etc. or even maybe generalizing the concept to more common stuff such as “ot” for “off-topic”, “flamewar”, “rp” for “roleplaying” so that to make the concept more widely known and tested. May be really useful to continue threads that might really interest people and strive for democratic debate, without risking to repulse some people from the mailing-list, and without having to ban some people or discussions, and without continuing the discussions in private (that might exclude silent and not-enough-participating people). “Mail me too, altogether as other mailing-list members”: this has become a widely inconsistant behavior for me between mailing lists and mailing-lists softwares, I can never recall it, nor can I recall to configure my user-agent to store a copy of what I sent or not. A such option, instead of making this consistent over a single mailing list or software, would make it consistent per user, and might be more convenient for them. Also could help expliciting the configured default for each mailing-list “Mail me regularely a reminder” (about that I’m subscribed and how to unsubscribe, may be really useful for low-trafic mailing lists) or even “unsubscribe be after X delay of inactivity”. “Don’t mail me again mails that are already also addressed to me” (when the member is already cited in To, Cc, or Bcc for instance) since some people do complain about receiving some mails several times, and it might relieve mailing lists of sending more mails. “Don’t mail me mails from threads I’ve not participated in, except first message”, the most complicated, and would require to keep a list of participant to a mailing-list, or a local mapping of message-id to source mail addresses (so you can check References header instead of recursively Reply-To). But this might encourage a lot of people to join a lot of mailing lists, and some mailing lists to touch a lot more people, as the traffic would be lower, and they might still react to announces and important stuff discussed there. “Don’t mail me mails from threads I didn’t started”: actually a misunderstandement of the previous one that I did explain, also a lot more easy to implement I guess, and that may be useful for mailing lists which don’t allow to send mail through them if you’re not subscribed. May be a disablable option in case you wan’t your subscribers list to stay a list of people who follow your list, and not just a list of people who may want to post, otherwise you might prefer allow everybody to post to your mailing list. Hope I’m encouraging and giving more ideas than I’m disturbing or seeming expectative. I find these would be really lovely features, but not being a lot used to python, nor to going into large unknown code base, I don’t think that would easy for me to improve mailman for those… but I’d like, if you have time and that doesn’t disturb you, to have your opinion on these. Thank you anyway!

2 2