Mailman-users

Download

mailman-users@mailman3.org

October 2022

29 participants
62 discussions

All addresses in a bounced list posting seem to be considered as bouncing
by Andy Smith Oct. 1, 2022

Oct. 1, 2022

Hi, I noticed this happened (bounce.log): Jul 09 12:46:51 2022 (71506) Member xxxxx(a)xxxxx.force9.co.uk already scored a bounce on list users.mailman.bitfolk.com today. Jul 09 12:46:51 2022 (71506) Bounce message for a non subscriber: Email users-leave(a)mailman.bitfolk.com is not a subcriber of users.mailman.bitfolk.com Jul 09 12:46:51 2022 (71506) Member andy(a)bitfolk.com on list users.mailman.bitfolk.com, bounce score = 1. Jul 09 12:46:51 2022 (71506) Bounce message for a non subscriber: Email users(a)mailman.bitfolk.com is not a subcriber of users.mailman.bitfolk.com What happened here is that a reply to one of my posts was rejected by subscriber xxxxx(a)xxxxx.force9.co.uk at smtp time (Exim mainlog): 2022-07-09 12:46:13 1oA9qc-007qOx-0T ** xxxxx(a)xxxxx.force9.co.uk R=dnslookup T=remote_smtp H=mx.avasin.plus.net [212.159.8.200] X=TLS1.2:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=yes DN="businessCategory=Private Organization,jurisdictionOfIncorporationCountryName=GB,serialNumber=03279013,C=GB,L=Sheffield,O=Plusnet plc,CN=mx.avasin.plus.net": SMTP error from remote mail server after end of data: 552 Spam Message Rejected The message contained my email address (andy(a)bitfolk.com) in quoted text, since it was a reply to a message of mine, and also contained addresses from the list's footer, which accounts for the log messages about users-leave(a)mailman.bitfolk.com and users(a)mailman.bitfolk.com. I'm concerned that Mailman seems to have scored my address as bouncing even though it isn't, merely because it appears inside a message that was rejected. Is that expected? Is there any way to avoid it? I see that Mailman has a bunch of heuristics to parse bounce messages. In this case though, there shouldn't have been a bounce message received to users-bounces@, as this was an SMTP-time rejection. Mailman seems to have parsed addresses out of the actual mail it was sending, rather than only scoring the subscriber address it was trying to send a list posting to. Cheers, Andy

3 11

Help addressing some issues with mailman 3 docker images
by Clark Boylan Oct. 1, 2022

Oct. 1, 2022

Hello, Some of us at opendev.org are looking to migrate to mailman 3 for our list servers. We've got about 98% of things sorted out using maxking's docker images (thank you for publishing those along with excellent documentation). There are however a small number of things that we've run into that we'd like to address before we take this to production. * Mailman 3 relies on lynx to convert html email to txt email. Lynx isn't currently installed in the docker images, but I've pushed a PR to add it to the images. https://github.com/maxking/docker-mailman/pull/552 * There are some user and group inconsistencies between the images. Not a deal breaker, but would be good to understand if these are intentional or if they can be changed without massively impacting people. https://github.com/maxking/docker-mailman/issues/550 * Issues with ALLOWED_HOSTS settings making assumptions about the environment and its inputs. We've worked around these by bind mounting in our own settings.py with these problems addressed, but it would be good to address them in case anyone else has run into this too. Details in these github issues: https://github.com/maxking/docker-mailman/issues/548 https://github.com/maxking/docker-mailman/issues/549 Ideally we'd avoid forking the images downstream and modifying them ourselves, but it seems the docker image repo is not getting a ton of attention recently. Totally understand that this may not be the biggest priority. We're happy to help address these by writing fixes and sending pull requests, but guidance would be appreciated before we head too far down that road. Once again thank you for the great documentation and images. They have already gotten us most of the way to production and the issues we've found are relatively minor. Clark

2 1