Mailman 3 October 2017 - 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.25 released
by Mark Sapiro 23 Nov '17

23 Nov '17

I am pleased to announce the release of Mailman 2.1.25. Python 2.4 is the minimum supported, but Python 2.7 is strongly recommended. This is a routine bug fix release with a minor new feature and some accessibility improvements for screen readers. 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.25 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

Use of the public suffix list
by Alessandro Vesely 04 Nov '17

04 Nov '17

Hi all, I noticed (from a DMARC mitigation utility that Lindsay extracted) that Mailman features its own approach to using the PSL. Of course, development must go on, and sometimes it is a waste of time trying to make a super-duper scaffolding for a job that can be carried out complying to the KISS principle. At any rate, what is the future of DMARC lookups in Mailman? * The specs say that "DMARC should be amended to use [a method better than PSL] as soon as it is generally available" [1]. I believe that sentence refers to RDAP, which was released more or less at the same time (March 2015) [2]. [1] https://tools.ietf.org/html/rfc7489#appendix-A.6 [2] https://datatracker.ietf.org/wg/weirds/documents/ * There are various Python packages for domain name splitting. They obviously use the PSL, but supposedly would transparently switch to a better method in case. If Mailman used one such package, a practical advantage for users would be to update the PSL in only one place, if they happened to use the same dependency. I found six packages. tldextract [3] is the only one of them which caches a JSON object rather than the original textual representation of the list. It uses a frozenset. tld [4] and publicsuffixlist [5] also build a set. publicsuffix[6] and publicsuffix2 [7] build lists of nested dictionaries from all the labels. dnspy [8] builds a dictionary of FQDNs, somewhat like Mailman. How does the time to build the structure compare with the time taken by DSN queries? [3] https://pypi.python.org/pypi/tldextract [4] https://pypi.python.org/pypi/tld [5] https://pypi.python.org/pypi/publicsuffixlist [6] https://pypi.python.org/pypi/publicsuffix [7] https://pypi.python.org/pypi/publicsuffix2 [8] https://pypi.python.org/pypi/dnspy * Debian distributes a publicsuffix package which brings a textual version of the list. Since stretch, it also brings a "dafsa" version. Nowadays, most C implementations (Firefox, Chromium) use dafsa. They build the structure using offsets rather than pointers, so that the blob can be defined in a source file as a literal static array of chars, in order to minimize loading time. That strategy works well as long as the relevant package is upgraded more frequently than the PSL. Otherwise, as for libpsl, one ends up using obsolete data. Surprisingly, the publisuffix package itself is not upgraded as frequently as the PSL. This bug [9] is what prompted me to write this message. I guess you, as Mailman developers, have pondered this subject and I'd be interested to know what you think. [9] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879008 TIA for any reply Ale --

3 4

Re: [Mailman-Developers] Signing commits with gpg
by Barry Warsaw 26 Oct '17

26 Oct '17

On Oct 24, 2017, at 16:52, Abhilash Raj <maxking(a)asynchronous.in> wrote: > > Gitlab now supports verification of commit signatures and it would be > awesome if we start signing commits. It is a relatively painless process > and happens automatically with little configuration. Very cool that GL has enabled this! Thanks for sending the recipe too. I definitely encourage folks (especially core devs) to start signing commits. Cheers, -Barry

5 6

Signing commits with gpg
by Abhilash Raj 24 Oct '17

24 Oct '17

Hi All, Gitlab now supports verification of commit signatures and it would be awesome if we start signing commits. It is a relatively painless process and happens automatically with little configuration. Spoofing authors in git is quite easy, actually provided as a command line option (--author, --reset-author), and I believe it would be a good practice to sign all the commits (even outside of Mailman). Here are steps for how you can do that: 1. Add your public key to Gitlab (https://gitlab.com/profile/gpg_keys) 2. Commit with `-S` (capital S) Here is the relevant section of `.gitconfig` to auto-sign every commit you make (no need for step 2 if you do this): ``` [user] name = Abhilash Raj email = raj.abhilash1(a)gmail.com signingkey = 541EA0448453394FF77A0ECC9D9B2BA061D0A67C [commit] gpgsign = true ``` Once you have pushed a signed commit to Gitlab and have uploaded your gpg public key, you will see a green "Verified" button alongside every commit. (See https://gitlab.com/maxking/mailman/commits/msapiro/mailman-pending) -- Abhilash Raj maxking(a)asynchronous.in

1 0

Re: [Mailman-Developers] Renaming a list
by Mark Sapiro 24 Oct '17

24 Oct '17

On 10/23/2017 05:02 PM, Abhilash Raj wrote: > On Mon, Oct 23, 2017, at 08:59 AM, Barry Warsaw wrote: >> On Oct 23, 2017, at 11:48, Aurelien Bompard <aurelien(a)bompard.org> wrote: >>> >>> I wanted to rename a list (only the list_name, not the list_id) and I >>> figured I would make the transition smoother by adding an "AcceptableAlias" >>> with the old name. I did that and realized that the acceptable aliases are >>> not added to the postfix_lmtp file, as a result emails sent to the old >>> address are just bounced at the Postfix level. >>> Is this the intended behavior ? >> >> It is. The thinking is that whatever email addresses end up funneling to >> a list is really outside of Mailman’s control. That’s really part of >> your MTA’s configuration, and acceptable aliases are just a way of >> telling Mailman to expand its implicit address logic. > > As I understand, AcceptableAliases are defined as regular expressions, > what if Mailman put the values that are a valid list name to > transport_maps? Converting regex to a listname doesn't sound like a > straight forward thing to me though. I think that's going to be too complex and error prone. > This most definitely adds some complexity for unique checks of > Listnames. I am not sure if we already check acceptable alias rules for > existing mailing lists to make sure they don't match any new list > created. We'd have to do it if we start putting acceptable aliases in > transport maps. We don't and it doesn't matter for what acceptable_aliases is intended to be used for. The background is a list can be configured (and is by default) to require_explicit_destination. which is intended as an anti-spam measure. I.e. it requires the list posting address to appear in To: or Cc: of the message and stops "To: undisclosed recipients:;" type of mail. > As a feature, it could be helpful to have multiple posting addresses for > a single List. Are there any major downsides to doing this? You can, either by aliases, .forwards or other MTA type configurations. And that's exactly what acceptable_aliases is for - to accept those alternate posting addresses as valid explicit destinations. But, I think it should be up to the installation to configure their MTAs or whatever for this. I don't thing we should be trying to generate MTA configurations for alternate list names bases on acceptable_aliases. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 1

Re: [Mailman-Developers] Renaming a list
by Barry Warsaw 24 Oct '17

24 Oct '17

On Oct 23, 2017, at 11:48, Aurelien Bompard <aurelien(a)bompard.org> wrote: > > I wanted to rename a list (only the list_name, not the list_id) and I > figured I would make the transition smoother by adding an "AcceptableAlias" > with the old name. I did that and realized that the acceptable aliases are > not added to the postfix_lmtp file, as a result emails sent to the old > address are just bounced at the Postfix level. > Is this the intended behavior ? It is. The thinking is that whatever email addresses end up funneling to a list is really outside of Mailman’s control. That’s really part of your MTA’s configuration, and acceptable aliases are just a way of telling Mailman to expand its implicit address logic. > BTW, changing the list_name attribute is sufficient to rename a list, > right? I didn't find anything else to change since everything seems to be > keyed to the list_id but I thought I'd check with you. Correct. List name is mutable but list-id is not, even if you move it to a different domain! -Barry

2 1

Renaming a list
by Aurelien Bompard 23 Oct '17

23 Oct '17

Hey folks! I wanted to rename a list (only the list_name, not the list_id) and I figured I would make the transition smoother by adding an "AcceptableAlias" with the old name. I did that and realized that the acceptable aliases are not added to the postfix_lmtp file, as a result emails sent to the old address are just bounced at the Postfix level. Is this the intended behavior ? BTW, changing the list_name attribute is sufficient to rename a list, right? I didn't find anything else to change since everything seems to be keyed to the list_id but I thought I'd check with you. Thanks! Aurélien

1 0

DMARC mitigation code question
by Lindsay Haisley 20 Oct '17

20 Oct '17

Mark, et al While configuring the MM 2.1 DMARC mitigation code for use in Courier- MTA I note that the return from _DMARCProhibited(..) for a detected policy of "p=none" is True, just as it is for "p=quarantine" and "p=reject". Why is this? I would assume that if this code is reached, and p=none, that no From munging would be required. -- Lindsay Haisley | "The first casualty when FMP Computer Services | war comes is truth." 512-259-1190 | http://www.fmp.com | -- Hiram W Johnson

2 4

Extracting some Mailman code
by Lindsay Haisley 17 Oct '17

17 Oct '17

Hey folks, This is a request for a pointer to some code rather than an offering for Mailman, but I hope my cred with the Mailman developers will fetch me a bit of help. I can read code and find this out myself, but one of the Mailman devs can probably give me some pointers that will save me a lot of time, time being the only human resource which is truly limited! I'm running Courier-MTA, an excellent MTA around which I've built FMP's small ESP services. Courier has the ability to do a simple email redirect using an alias address in a flat file, in a special directory, containing only the email address to which email should be redirected. Courier also has the ability to interpret lines in this file starting with "|" as programs to which the body of an email can be submitted via stdin and any required processing done therein. I'm the author of courier-to-mailman.py in the contrib collection in Mailman 2's current standard code which works this way. I'm seeing increasing problems with DMARC rejection of emails sent through this simple redirection mechanism, for obvious reasons, and I'm thinking that I might borrow code from Mailman to re-write the From address just as Mailman does when handling a list with from_is_list set to "Munge From", and then pipe emails for selected ESP clients through this filter. Said filter must: * detect whether or not the sending domain publishes a DMARC "p=reject" or "p=quarantine" record * If so, parse out the From address in the email and rewrite it in the general form Mailman uses with "on behalf of ..." giving the origianl sender and specifying the mail server's DN in the sender address. ... after which the email will be sent on to the recipients _real_ address. The management of the message body, the piping and such is handled quite well by Courier. I assume that this would mitigate the DMARC issue for redirections through our mail server, just as it does for Mailman. So, if someone could give me a few pointers to the relevant code in Mailman 2, and any suggestions which might save me some time, I can take it from there. I'm python-literate and have hacked our copy of Mailman here in the past - perhaps more than is wise since every time I upgrade I need to apply a number of patches to bring my mods along with the upgrade :) Thanks for any help you can give me. If it's too much bother, tell me so and I'll put on my hacker's hat and go read code :) Ciao, -- Lindsay Haisley | "Behold! Our way lies through a FMP Computer Services | dark wood whence in which 512-259-1190 | weirdness may wallow!” http://www.fmp.com | --Beauregard

5 12