Mailman 3 April 2021 - 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

Core new release?
by Danil Smirnov July 6, 2021

July 6, 2021

Hi, As per public Gitlab stats for Mailman Core repo, 25 issues have been closed in April so far, which is the record of the last 12 months and beats the previous four months total. From a merge requests perspective, it is the record too, and the merged requests number pace is growing by ~15% over the last four months, reaching a quarter of a hundred in April. I know that it's just a month from the previous Mailman Core release, but given the stats above should the next release be planned earlier than usual? Best regards, Danil Smirnov

3 6

[Mailman-cabal] Invitation to the CERT Vendor Meeting 2021 [General-7305] - mailman
by Stephen J. Turnbull April 23, 2021

April 23, 2021

Hi, There was recently a mail on the (closed) Mailman security list from the CERT Coordination Center which had this strange CC field: CC: '@mail.python.org, C(a)mail.python.org, E(a)mail.python.org, R(a)mail.python.org, T(a)mail.python.org, o(a)mail.python.org, r(a)mail.python.org, d(a)mail.python.org, i(a)mail.python.org, n(a)mail.python.org, a(a)mail.python.org, t(a)mail.python.org, e(a)mail.python.org, c(a)mail.python.org, "", "."@mail.python.org, g(a)mail.python.org I guess those are "conformant" email addresses, but they seem unlikely to be mailboxes at python.org. I'm not sure if these addresses were added by the generating software at CERT, some MTA, or Mailman. Has anybody seen anything like this before? P.S. I hope I'm not spoiling this for any amateur sleuths who wanted to figure it out for themselves, but yes, except for the apostrophe and the empty address, those are the letters in "CERT Coordination Center <cert(a)cert.org>", in order, with dupes eliminated. P.P.S. It's about a conference, not a CVE. Hakuna matata! Steve

2 2

Long lines in mail composed by HyperKitty
by Stephen J. Turnbull April 21, 2021

April 21, 2021

Hi, [I prefer discussion be directed to mailman-developers, so Reply-To is set. But if you're not subscribed to -developers, following up here is OK, and I'll eventually summarize to -developers. Just don't followup to both.] I just noticed that among the agents that send non-conformant long lines[1] is HyperKitty. Nowadays violating the 80 octet limit is common and MUAs mostly handle it, but the 1000 octet limit is enforced by many MTAs[2] I think that HyperKitty should format mail per RFC 3676 format=flowed https://tools.ietf.org/html/rfc3676#section-4. However, I don't use "modern" (aka crappy HTML-oriented) clients, so I don't know whether they handle format=flowed properly. Discussion greatly desired. Steve Footnotes: [1] RFC 5321: MTAs MAY impose a limit >= 1000 octets including CRLF. RFC 5322: MUST be <= 1000 octets including CRLF, SHOULD be <= 80 octets including CRLF. [2] In practice, most (?) MTAs just break the line at 998 octets and insert CRLF rather than reject the message. I assume they would break happily in the middle of a multi-byte character, i.e., any non-ASCII in a UTF-8 text.

2 2

X-Mailman-Original-DKIM-Signature
by Alessandro Vesely April 15, 2021

April 15, 2021

Hi, I discovered this just today, after a list I'm subscribed to enabled it. I have a filter which tries to validate original signatures by removing footers and subject tags. Removing "X-Mailman-Original-" is going to be the next addition. I guess the purpose of this option is to spare a dkim=fail result in the recipient's header. However, for documentation purposes[*], I'd be comforted by some document, discussion, or even a crispy comment about the intended usefulness of masking existing signatures. Google found nothing. Any pointer? TIA Ale -- [*] I try and document that original signature validation here: https://tools.ietf.org/html/draft-vesely-dmarc-mlm-transform

3 2

Mailman server showing internal server error (500)
by Prashant Pandey April 8, 2021

April 8, 2021

I was using the mailman's development environment for a long time to understand the working and codebase. But today without changing anything I got a mailman server error 500. Is there any problem with mailman core? What troubleshooting is needed to fix this issue?

2 1

[GSoC] Some Questions in List Configuration Tool
by Steven Chen April 8, 2021

April 8, 2021

Dear Mailman Developers, I am currently working on the proposal of List Configuration Tool in GSoC idea list. As I thought in the details of several functions of the tool, I wonder what kind of configurations should be exported, and what should not. Q1. We can get nearly all the configurations for a list from the core's REST API (https://mailman.readthedocs.io/en/release-3.1/src/mailman/rest/docs/listcon…), but some of the data should not be exported, such as `created_at`, `last_post_at`, and etc. Hence, we may need a filter to extract out the meaningful configurations to export out. I wonder whether we have a more convenient way to get all meaningful configurations, and what kind of configuration fields are expected to be exported from the user's perspective? Q2. Besides all the configurations obtained from the listconf mentioned in Q1, we have more configurations for a list, such as member list. In the Idea Page (https://wiki.list.org/DEV/Google%20Summer%20of%20Code%202021), it says that the membership roster should not be included by default. Since we already have the `list_mass_subscribe` method for importing a lot of subscriptions at once, so should the list configuration tool include the functionality to handle membership automatically or just does not include the memberships in the exported configuration? For Q1, I do have some thinking for some important configuration fields that should not be exported: owner_address: should be filtered out, since only the list owner can import the configuration template, the owner_address should be set when the owner apply the configuration template to the list instead of import from the previous configuration. mail_host, fqdn_listname: should be filtered out, since lists are created under the domains, domains should be created before the lists are created. Hence, only the name before the domain should be included in the exported configuration, and the full fqdn_listname can be generated when creating the list. I do need more suggestions on what to choose in the configuration that can be exported. Any suggestion is welcome. Regards, Steven1677

2 1