Mailman 3 March 2022 - 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

GSoC for working professionals
by Christopher 23 Mar '22

23 Mar '22

Hi everyone Nice to meet you all! I am interested in GSoC 2022 and I discovered that Mailman might be one of the interesting projects I would like to contribute to. However, I am not a student, but I am working as a software engineer full time (10-6 on weekdays). I would like to start contributing to open source projects and stumbled upon GSoC which I thought it's a great opportunity to get started. If I am able to churn out 14.5 hours of work per week (by working on the weekends) across 12 weeks (summing up to 175 hours), do I stand a chance to be accepted as a GSoC participant? Thanks, Christopher Chong

3 6

--- in DMARC From: rewritings
by Дилян Палаузов 22 Mar '22

22 Mar '22

Hello, the DMARC Mitigation action “Replace From: with list address” is evaluated in mailman/handlers/dmarc.py:munged_headers(). In the case, where From: is a non-member email address, without display part, which non-member may post, this happens: realname = email realname = re.sub(r'@([^ .]+\.)+[^ .]+$', '---', realname) with _.using(mlist.preferred_language.code): via = _('${realname} via ${mlist.display_name}') display_name = str(Header(via, mlist.preferred_language.charset)) value = [('From', formataddr((display_name, mlist.posting_address)))] In short, if a@b is a non-member, who may post to mailing list “E <c@d>”, and b is DMARC-protected, the final distrubuted email will have From: "a--- via E <c@d>" Reply-To: a@b compare to the IETF mailing lists, which would send: From: <a=40b@d> where a and b are from a@b, d is from c@d The bottom of https://answers.uillinois.edu/illinois/page.php?id=86787 describes the mitigariton options offered by Sympa: display name From: User Name <listName(a)lists.illinois.edu> display name and e-mail From: “User Name” (userEmail(a)address.com) < listName(a)lists.illinois.edu > email “via Mailing List” From: “User Name” (userEmail(a)address.com via listName Mailing List) <listName(a)lists.illinois.edu> name “via Mailing List” From: “User Name” <listName(a)lists.illinois.edu> (the website likely means:) From: “User Name via listName” <listName(a)lists.illinois.edu> As can be seen, the other MLMs do not replace domains with --- . I find ugly the --- , inserted by mailman. In my real-world case the From: is aaa(a)example.org, the ML name is aaa(a)l.example.org (localname is the same, the domains are different). The result is: From: aaa--- via Aaa <aaa(a)l.example.org> So there is twice trippe-A and @example.org disappeared. Mentioning twice AAA in the display name in this case really has to added value. That said, I propose removing now the line realname = re.sub(r'@([^ .]+\.)+[^ .]+$', '---', realname) and in the future offer as options: From: User Name <listName(a)lists.illinois.edu> From: “User Name” (userEmail(a)address.com) < listName(a)lists.illinois.edu > From: “User Name” (userEmail(a)address.com via listName Mailing List) <listName(a)lists.illinois.edu> From: “User Name via listName” <listName(a)lists.illinois.edu>

3 6

GSoC - Support for REST Callbacks in Core
by Christopher 21 Mar '22

21 Mar '22

Hi guys, I am interested in this project "Support for REST Callbacks in Core", can I know more details about it? Thanks, Christopher Chong

1 0

Creating an event catching plugin
by Дилян Палаузов 11 Mar '22

11 Mar '22

Hello, can you point me to existing, open-source mailman plugins? I want to write a plugin, which fires on all subscriptions, unsubscriptions and configuration changes. This code: def subscribe_events(e): print('EVENT', e) @implementer(IPlugin) class SievePlugin: def __init__(self): print('XXX') zope.event.subscribers.append(subscribe_events) def post_hook(self): print('YYY') zope.event.subscribers.append(subscribe_events) prints: XXX EVENT x(a)example.org joined zzz.udoma.bapha.be EVENT ab c <mm(a)example.org> joined zzz.udoma.bapha.be or XXX EVENT x(a)example.org left zzz.udoma.bapha.be on `mailman addmembers/mailman delmembers`. But it does not trigger a UnsubscriptionEvent or SubscriptionEvent. Greetings Дилян

2 4

New MM3 plugin: mailman_sieve
by Дилян Палаузов 11 Mar '22

11 Mar '22

Hello, I have published a new Mailman 3 plugin at https://mail.aegee.org/cgit/mailman_sieve/tree/ . It generates for each mailing list a Sieve script. When the Sieve script is evaluated during the SMTP dialog, it would reject some emails, which otherwise would be bounced by Mailman. Less bounces means less backscatters and better IP reputation. For the record, I do the evaluation of the Sieve scripts during the SMTP dialog with https://mail.aegee.org/cgit/aegee-milter . Since the latter is not documented yet, you cannot use it. The mailman_sieve plugin is not useful, unless you have software to evaluate the Sieve Scripts during the SMTP dialog. This is a very first version, which does what it is supposed to do. Some optimizations are possible, like not including the subscriber addresses in the Sieve scripts for announce-only mailing lists. I am not good at writing setuptools configuration. Neither do I understand the mailman system very good right now, creating possibly shorter scripts. But the plugin is there to keep by IP reputation good! See https://mail.aegee.org/cgit/mailman_sieve/tree/README.md . My reading of the mm3 source code is that there is no event triggered, when the mailing list configuration changes, like adding a new moderator, or switching the announce-only status. In the lack of such event triggers, the Sieve scripts are not updated. When the code improves, the plugin could be published in PyPi or in mailman/contrib . Greetings Дилян

2 1

GNU Mailman in Google Summer of Code 2022!
by Stephen J. Turnbull 10 Mar '22

10 Mar '22

Hi all, We are participating in Google Summer of Code 2022 (GSoC) under the Python Software Foundation (PSF). We did apply as a separate organization, but didn't get in. Many thanks to the PSF's GSoC organization for picking us up at the last minute! You can find our ideas page at https://wiki.list.org/DEV/Google%20Summer%20of%20Code%202022, and item on the PSF ideas page under https://python-gsoc.org/ideas.html (which isn't so interesting about Mailman, but you can check out who else is under the PSF banner there). Discussion and development of project ideas will take place on mailman-developers(a)python.org. If you have a developed idea not already listed that you're willing to discuss and advocate, and you're willing to grab the template (last item on our ideas page on list.org) and fill it out, please post it to mailman-developers(a)python.org. (This a deliberate hoop-jumping exercise to filter in "serious" ideas.) You can put more weight on it by expressing interest in mentoring the project, and even more by actually volunteering! ;-) If you have a half-baked idea, and/or you want to get input from other Mailman users, of course you should feel free to discuss it on mailman-users(a)mailman3.org. We *might* pick it up from there, even if it's just a drive-by post with little support from the list members. But no promises about that, most of our attention will go to mailman-developers. If you feel some idea should get more love, polish it a little and post that to mailman-developers (don't cross-post, please). Again, we'd love to have more mentors, including backup mentors. We currently only have two mentors. Although we're both core developers, and I'm on an academic schedule and can devote plenty of time to the student during the summer, not so for Abhilash. Volunteering at this stage is not a promise to do more than look at student proposals. You would only be asked to look at the proposals, and volunteer as mentor for that project if you have interest and some level of knowledge to contribute to it. Even if you're a site admin with little Python programming experience, vetting interns' brainstorms about list admin-visible features and holding their hands until the "pros from Dover" arrive is quite helpful in making the student feel at home in our community. Many students are shy about blogging and communicating about their projects to the community -- just talking to them about their project and suggesting that they blog what they told you is helpful. Coding skills and knowledge of some part of the Mailman 3 code base are most welcome, of course, but you can make your mentor role what you want it to be. Regards, Steve

1 0