Mailman 3 January 2019 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett Nov. 7, 2022

Nov. 7, 2022

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

GSoC deadlines approaching fast!
by Stephen J. Turnbull Feb. 27, 2019

Feb. 27, 2019

Hey all We need to decide if we're going to go under the PSF umbrella or if we want to go standalone. The real advantages to the standalone are two tickets (most expenses paid by Google) to the Mentor Summit, and the $500/student gift to Mailman. But it's more work and lower chance of acceptance. For PSF, we need to have project and idea pages up by Monday IIRC. I think Google's deadline is a couple days later. Steve

3 5

Postorius 1.2.3 and MailmanClient 3.2.1 is now out
by Abhilash Raj Jan. 25, 2019

Jan. 25, 2019

Hi All, I am very pleased to announce (a bit late) that Postorius 1.2.3 and MailmanClient 3.2.1 is now out. The full set of changelog can be found in the documentation[1][2]. The most notable feature that I can think of is non-member management in Postorius. New releases are available on PyPI[3][4]. Thanks to all the contributors who made this release possible! :) [1]: https://postorius.readthedocs.io/en/latest/news.html#id2 [2]: https://mailmanclient.readthedocs.io/en/latest/src/mailmanclient/docs/NEWS.… [3]: https://pypi.org/project/mailmanclient/ [4]: https://pypi.org/project/postorius/ -- thanks, Abhilash Raj (maxking)

1 0

[MM3-users] Re: digests are created but not sent out
by Stephen J. Turnbull Jan. 17, 2019

Jan. 17, 2019

This subthread moved from Mailman3 Users list. ASIDE: This got caught for several days in a mismatch between Exim and greylisting. If you're an Exim user, recent versions are pretty aggressive about using the PIPELINING and CHUNKING extensions to SMTP, and one or both of those seems to be a problem. The symptom was repeated 4xx rejections of each message, and communicating with Postmaster revealed that the greylist software complained about possible PIPELINING after a BDAT command (which is part of the CHUNKING protocol). If you're running a low-traffic MTA you might want to disable these extensions. That's general advice if you use any MTA that implements them, not limited to Exim. Mark Sapiro writes in that thread: > self._charset is the character set of the lists > preferred_language. The footer can't contain characters not in the > character set of the list's preferred_language. For English (en) > this is us-ascii. For German (de) it is iso-8859-1. These are > artifacts from Mailman 2.1 ISO-8859-15 (has EURO SIGN substituted for generic CURRENCY SYMBOL and other minor changes) should probably be considered for substitution for ISO-8859-1 in Mailman 2. What do Western Europeans think? If someone's concerned, I can look up the other differences from ISO-8859-1. I believe they're quite minor populations of users compared to the Euro sign users, but backward compatibility, etc. > You can change this for English by putting > > [language.en] > charset: utf-8 > > in your mailman.cfg. This works because us-ascii is a proper subset of > utf-8. > > For other languages, a change like this might require recoding of > templates and/or a message catalog, but since we don't currently ship > any non-English templates or message catalogs, that is moot at the > moment. We should simply declare that template files in Mailman 3 MUST be encoded in UTF-8 (or US-ASCII). I'll file an RFE shortly, including a suggestion that we provide a detection (report only!) and conversion utility.

1 0