- Mailman-users - lists.mailman3.org

RFC-2369 List-Unsubscribe header missing
by Sparks, Paul July 16, 2025

July 16, 2025

I forgot to include the mailing list in a reply to Stephen and I wantied to follow up here in case what I learned is helpful to others. One of the things Stephen suggested was that postfix was filtering the headers. That was true in my case. The configuration code I inherited had the following lines in /etc/postfix/header_checks /^List-Unsubscribe:/ IGNORE /^List-Subscribe:/ IGNORE > How are you capturing mail at postfix? For capturing the email at postifx I used the following steps I found on another website to defer SMTP sending so I could look at emails while they were "in process" by postfix. postconf -e defer_transports=smtp; postfix reload # send the email to the server mailq # Use ID from mailq to examine the email using postcat postcat -vq C23D82B60024 # Re-enable SMTP sending postconf -e defer_transports=; postfix reload; postfix flush As for the question about debugging in rfc-2369.py, I did have additional log.debug calls in the "process" method, but was not seeing anything from them. Perhaps they were not getting called as Stephen suggested. Stephen also mentioned in a private email to me about RFC 8058 "One-Click Leave" which is intended to make it easier for folks to unsubscribe from lists. We don't have an implementation in Mailman 3 yet, but it looks like a reasonable protocol (ie, not that easy to abuse, though not impossible). It can probably be implemented in Postfix (but it might not be straightforward). https://datatracker.ietf.org/doc/html/rfc8058 ________________________________ The contents of this e-mail, including attachments, are intended for use by the named addressee only and may contain information that is confidential or private according to applicable law. If you received this electronic transmission in error, please notify the sender by a reply to sender only message, permanently delete the original message and any attachments from your electronic device and keep this message confidential. Unauthorized use, copying, review and/or distribution to unauthorized persons is strictly prohibited and subjects the user to penalty of law. Thank you for your cooperation.

1 0

The RequestOptions.auto_parse_form_urlencoded option is deprecated.
by Odhiambo Washington July 16, 2025

July 16, 2025

Hello Admins, The subject appears as part of the output of `systemctl status mailman3`. Anyone fixed it? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

2 2

New Lists Appear in HyperKitty Archives, But No Mail Data is Shown
by Asif Muzammil July 14, 2025

July 14, 2025

Hello, I have been troubleshooting an issue with our Mailman 3 archives. I have made a key observation that has helped narrow down the problem. While a newly created list appears in the HyperKitty archives, no email data is shown inside that list. *Problem:* When I create a new mailing list in Mailman Core and then visit the HyperKitty archives, the list is correctly displayed. However, when I send an email to that list, no mail data (messages) are shown inside it. The message count for the list remains at zero in the archives UI. *Expected Behavior:* I expect that when a new list is created, it should appear in the archives, and any emails sent to it should also be correctly displayed within that list. *System Environment:* - *Mailman Version:* Mailman 3.x - *Archiver:* HyperKitty - *Web Interface:* Postorius - *Database:* PostgreSQL - *Setup:* Mailman Core (/opt/mailman/venv) and the web components (venv_hk) are running in separate virtual environments on the same server. *Troubleshooting Steps Taken:* 1. *List Synchronization:* Creating a new list in Mailman Core immediately makes it visible in the HyperKitty archives, which confirms that the mailmanweb service is correctly communicating with the hyperkitty_mailinglist table. 2. *Email Injection Test:* I used the mailman shell to inject a test email directly into a list. The inject_message function executed without errors. 3. *Configuration Check:* I have verified that the base_url in the Mailman archiver configuration (mailman-hyperkitty.cfg) and the MAILMAN_ARCHIVER_KEY in the HyperKitty settings file (settings.py) are correctly set and match. Could this be due to an API key or permissions issue preventing the data from being written, even though the tables exist? Any advice on what to check next would be extremely helpful. Thanks

4 9

Re: RFC-2369 List-Unsubscribe header missing
by Stephen J. Turnbull July 14, 2025

July 14, 2025

Hi Paul Glad you got that sorted! I wonder why those filters were in there? Not really the kind of thing I'd expect Postfix to be doing out of the box! Looks like you didn't send to the list (at least, I got my copy via personal mail, not the list). Replying for the benefit of Mailman-Users (nothing new to you here). Sparks, Paul writes: > Postfix was filtering the headers. I was not familiar with this > postfix functionality. > > For others who might see this, the filter lines were in /etc/postfix/header_checks > /^List-Unsubscribe:/ IGNORE > /^List-Subscribe:/ IGNORE > > How are you capturing mail at postfix? > > For capturing the email at postifx I used the following to defer SMTP sending. > postconf -e defer_transports=smtp; postfix reload That swooshing sound is that concept returning to hover over my head. > # send the email to the server > mailq > # Use ID from mailq to examine the email using postcat > postcat -vq C23D82B60024 > # Re-enable SMTP sending > postconf -e defer_transports=; postfix reload; postfix flush That's potentially useful in a lot of situations! Steve -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

1 0

RFC-2369 List-Unsubscribe header missing
by paul.sparks＠us.idemia.com July 12, 2025

July 12, 2025

Thanks to Mark Sapiro and others who have answered questions on this list. It has made my job easier. I'm hoping someone can help with another issue I'm seeing. I'm setting up a new mailman 3 server and doing some test posts to a list. This server is intended only as an announcement list with limited members allowed to post. The resulting emails coming from the list do not include the List-Unsubscribe header although other "List-XXX" headers are included. I'm trying to figure out why the header is missing. It seems clear from the code that the header should be included. Here is partial text of the email source as received from the list. I've tried viewing in Outlook.com, Thunderbird, and even captured the email text at postfix prior to sending to look for the missing header. My domain has been replaced with "example.com" throughout. This is from the postfix capture ________ ... To: "test1(a)example.com" <test1(a)example.com> Thread-Topic: Post 8 test Thread-Index: AQHb8oBBzPBOYgrDxUOIiAxhvUzthA== Date: Fri, 11 Jul 2025 16:24:38 +0000 Accept-Language: en-US Content-Language: en-US msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=example.com; MIME-Version: 1.0 Message-ID-Hash: FWHZCRE4EA6IFP4BZTPIF23DKAKVRMDT X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Content-Filtered-By: Mailman/MimeDel 3.3.10 From: "Somewhere1, SW" <test1(a)example.com> X-Mailman-Version: 3.3.10 Precedence: list Reply-To: no-reply(a)example.com Subject: [Test1] Post 8 test List-Id: "Somewhere1, SW" <test1.example.com> List-Help: <mailto:test1-request@example.com?subject=help> List-Owner: <mailto:test1-owner@example.com> List-Post: NO Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20250711163343.017C31DBB79(a)example.com> Body text ... __________ Details on my test setup: # Mailman version. __version__ = '3.3.10' OS: Amazon Linux 2023 (RHEL 9 compatible) MTA: postfix-3.7.2 I am using the following code with mailman shell to configure the list. include_rfc2369_headers is left at the default value of True (verified via mailman shell) ____________ # Description value must be passed as a parameter def configure_list(ml, description): #ml.accept_these_nonmembers = allowed_to_post ml.admin_immed_notify = False ml.advertised = False ml.allow_list_posts = False ml.anonymous_list = True ml.archive_policy = ArchivePolicy.never ml.bounce_info_stale_after = datetime.timedelta(days=90) ml.bounce_notify_owner_on_disable = False ml.bounce_notify_owner_on_removal = False ml.bounce_score_threshold = 3 ml.bounce_you_are_disabled_warnings = 0 ml.default_member_action = Action.discard ml.default_nonmember_action = Action.discard ml.description = description ml.digests_enabled = False ml.filter_content = True ml.first_strip_reply_to = True ml.forward_auto_discards = False ml.max_days_to_hold = 1 ml.max_message_size = 0 ml.nntp_prefix_subject_too = False ml.pass_extensions = [] ml.pass_types = ['text/plain','multipart/alternative'] ml.reply_goes_to_list = ReplyToMunging.explicit_header ml.reply_to_address = "no-reply(a)example.com" ml.require_explicit_destination = False ml.respond_to_post_requests = False # Allow select members to post to list for mbr in ml.members.members: if str(mbr.address) in allowed_to_post: mbr.moderation_action = Action.defer print('end',mbr.address,mbr.moderation_action) _______________ /etc/mailman3/mailman.cfg file: # /etc/mailman3/mailman.cfg # These settings override the defaults in the following 2 config files # /opt/mailman/lib/python3.9/site-packages/mailman/config/schema.cfg # /opt/mailman/lib/python3.9/site-packages/mailman/config/mailman.cfg [paths.custom] var_dir: /data/lib/mailman pid_file: /data/lib/mailman/pid/master.pid lock_file: /data/lib/mailman/pid/master.lock [mailman] layout: custom # This address is the "site owner" address. Certain messages which must be # delivered to a human, but which can't be delivered to a list owner (e.g. a # bounce from a list owner), will be sent to this address. It should point to # a human. site_owner: ml-owner(a)example.com [database] class: mailman.database.postgresql.PostgreSQLDatabase url: postgresql:///mailman # No archiving enabled [archiver.prototype] enable: no [archiver.hyperkitty] enable: no [shell] history_file: $var_dir/history.py [mta] verp_confirmations: yes verp_personalized_deliveries: yes verp_delivery_interval: 1 [passwords] # When Mailman generates them, this is the default length of passwords. password_length: 15 [logging.debug] path: debug.log level: debug ______________ With debug enabled I see the rfc-2369 pipeline being run when processing the post to the list. Jul 11 17:51:32 2025 (444088) [IncomingRunner] starting oneloop Jul 11 17:51:32 2025 (444088) [IncomingRunner] processing filebase: 1752256291.9136803+bfd305a28151ce750dde5114b413b351fa4d1284 Jul 11 17:51:32 2025 (444088) [IncomingRunner] processing onefile Jul 11 17:51:32 2025 (444090) [OutgoingRunner] starting oneloop Jul 11 17:51:32 2025 (444090) [OutgoingRunner] ending oneloop: 0 Jul 11 17:51:32 2025 (444097) [DigestRunner] starting oneloop Jul 11 17:51:32 2025 (444097) [DigestRunner] ending oneloop: 0 Jul 11 17:51:32 2025 (444088) [IncomingRunner] finishing filebase: 1752256291.9136803+bfd305a28151ce750dde5114b413b351fa4d1284 Jul 11 17:51:32 2025 (444088) [IncomingRunner] doing periodic Jul 11 17:51:32 2025 (444088) [IncomingRunner] committing transaction Jul 11 17:51:32 2025 (444088) [IncomingRunner] checking short circuit Jul 11 17:51:32 2025 (444088) [IncomingRunner] ending oneloop: 1 Jul 11 17:51:32 2025 (444088) [IncomingRunner] starting oneloop Jul 11 17:51:32 2025 (444088) [IncomingRunner] ending oneloop: 0 Jul 11 17:51:32 2025 (444087) [CommandRunner] starting oneloop Jul 11 17:51:32 2025 (444087) [CommandRunner] ending oneloop: 0 Jul 11 17:51:32 2025 (444091) [PipelineRunner] starting oneloop Jul 11 17:51:32 2025 (444091) [PipelineRunner] processing filebase: 1752256292.373131+a372784a3ff7a76a662ed1c62c224a53a8008b8b Jul 11 17:51:32 2025 (444091) [PipelineRunner] processing onefile Jul 11 17:51:32 2025 (444096) [VirginRunner] starting oneloop Jul 11 17:51:32 2025 (444096) [VirginRunner] ending oneloop: 0 Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: validate-authenticity Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: mime-delete Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: tagger Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: member-recipients Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: avoid-duplicates Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: cleanse Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: cleanse-dkim Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: cook-headers Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: subject-prefix Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: rfc-2369 Jul 11 17:51:32 2025 (444091) RFC 2369 process Jul 11 17:51:32 2025 (444091) RFC 2369 process continue 1 Jul 11 17:51:32 2025 (444091) RFC 2369 process headers extend Jul 11 17:51:32 2025 (444091) RFC 2369 process header for loop Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: to-archive Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: to-digest Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: to-usenet Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: after-delivery Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: acknowledge Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: dmarc Jul 11 17:51:32 2025 (444091) <20250711175131.B8CEC1DA51B(a)example.com> pipeline default-posting-pipeline processing: to-outgoing Jul 11 17:51:32 2025 (444091) [PipelineRunner] finishing filebase: 1752256292.373131+a372784a3ff7a76a662ed1c62c224a53a8008b8b Jul 11 17:51:32 2025 (444091) [PipelineRunner] doing periodic Jul 11 17:51:32 2025 (444091) [PipelineRunner] committing transaction Jul 11 17:51:32 2025 (444091) [PipelineRunner] checking short circuit Jul 11 17:51:32 2025 (444091) [PipelineRunner] ending oneloop: 1 Jul 11 17:51:32 2025 (444091) [PipelineRunner] starting oneloop Jul 11 17:51:32 2025 (444091) [PipelineRunner] ending oneloop: 0 Jul 11 17:51:32 2025 (444085) [ArchiveRunner] starting oneloop Jul 11 17:51:32 2025 (444085) [ArchiveRunner] ending oneloop: 0 Jul 11 17:51:33 2025 (444090) [OutgoingRunner] starting oneloop Jul 11 17:51:33 2025 (444090) [OutgoingRunner] processing filebase: 1752256292.8885148+5e5c4a68eacfead13561df616fe7ca19e1d1d182 Jul 11 17:51:33 2025 (444090) [OutgoingRunner] processing onefile Jul 11 17:51:33 2025 (444097) [DigestRunner] starting oneloop Jul 11 17:51:33 2025 (444097) [DigestRunner] ending oneloop: 0 Jul 11 17:51:33 2025 (444090) [outgoing] <function deliver at 0x7f21ed7b1310>: <175225629286.444091.14942604217243398224(a)ip-10-0-0-168.us-gov-west-1.compute.internal> Jul 11 17:51:33 2025 (444088) [IncomingRunner] starting oneloop _____________ I tried inserting some log.debug calls into lib/python3.9/site-packages/mailman/handlers/rfc_2369.py to see where headers were being removed and added. I modified: log = logging.getLogger('mailman.debug') and inserted log.debug throughout the process function and one in the top level. ___________ ... @public @implementer(IHandler) class RFC2369: """Add the RFC 2369 List-* headers.""" name = 'rfc-2369' description = _('Add the RFC 2369 List-* headers.') log.debug('RFC 2369 processing') def process(self, mlist, msg, msgdata): """See `IHandler`.""" process(mlist, msg, msgdata) __________ When running with debug enabled, I see this top level message many times at the top of the debug.log file during mailman startup, but not after that. I don't see any of my other debug messages. _____________ Jul 11 16:03:36 2025 (409226) RFC 2369 processing Jul 11 16:03:40 2025 (409244) RFC 2369 processing Jul 11 16:03:41 2025 (409250) RFC 2369 processing Jul 11 16:03:49 2025 (409271) RFC 2369 processing Jul 11 16:03:50 2025 (409271) [DigestRunner] starting oneloop Jul 11 16:03:50 2025 (409271) [DigestRunner] ending oneloop: 0 Jul 11 16:03:50 2025 (409261) RFC 2369 processing Jul 11 16:03:50 2025 (409261) [BounceRunner] starting oneloop Jul 11 16:03:50 2025 (409261) [BounceRunner] ending oneloop: 0 Jul 11 16:03:50 2025 (409264) RFC 2369 processing Jul 11 16:03:50 2025 (409267) RFC 2369 processing Jul 11 16:03:51 2025 (409262) RFC 2369 processing Jul 11 16:03:51 2025 (409262) [CommandRunner] starting oneloop Jul 11 16:03:51 2025 (409262) [CommandRunner] ending oneloop: 0 Jul 11 16:03:51 2025 (409266) RFC 2369 processing Jul 11 16:03:51 2025 (409266) [PipelineRunner] starting oneloop Jul 11 16:03:51 2025 (409266) [PipelineRunner] ending oneloop: 0 ... __________ Any suggestions on where else I can look? Any thoughts on why my debug calls are not showing in the logs?

2 1

Displaying addresses in emails from a Mailman 3 installation
by Steve Brown July 5, 2025

July 5, 2025

In a list I administer, the From line in an incoming email shows [Poster's Name] via [List Name] <address for posting a reply> . I use Outlook as my client, but at least some other clients behave similarly. However, I have at least one subscriber who uses Mozilla's Thunderbird as his client, and periodically the format changes to something else, most recently to just [List Name <address for posting a reply> . I suspect this occurs from some combination of the way Thunderbird parses the header and the way it populates some kind of address book that makes autofill work, but I'm not sure. Is this a known problem? Is there an easy fix that will be stable? In the past, putting an association in his address book and removing others worked, but it didn't hold and he is frustrated.

3 12

Caching problem with templates
by Mark June 29, 2025

June 29, 2025

Caching problem with templates. GNU Mailman 3.3.10 Python 3.11.2 Postorius Version 1.3.13 Venv installation per docs Hi All, A footer template is created and initially it works as expected. Editing the footer template sees the new content written to the database, In addition to viewing the edited content in the database, the new template can also be viewed in Lynx on localhost at: http://localhost:8000/mailman3/api/templates/list/<IDENTIFIER>/list:member:regular:footer The problem is that the original template is being cached somewhere and the old footer persists in new emails. In trying to get the edited footer to show in the emails I've restarted mailman3/mailmanweb, rebooted the server - but no joy. Any advice on how to flush the cache or hammer this gremlin greatly appreciated. Thanks, Mark

2 12

redirecting -bounces replies
by Hirayama, Pat June 26, 2025

June 26, 2025

Greetings, Is it possible to redirect the -bounces alias of a specific list so that it also goes to a person, in addition to the normal bounces processing for that list? In Mailman2, I know that I could do that by modifying the aliases table. I've been poking around in Mailman3, but haven't managed to figure out which container I need to be looking at. And rather than keep spinning, I figured that I'd ask the hive mind, since I'm sure one of you can quickly point me to the correct location. Thanks! -p Pat Hirayama Pronouns: he/him/his Systems Engineer IT | Systems Engineering - Infrastructure Fred Hutch Cancer Center O 206.667.4856 phirayam(a)fredhutch.org<mailto:phirayam@fredhutch.org>

5 14

Change the default value for the General Archive Policy
by Markus Grandpré June 26, 2025

June 26, 2025

Dear list, currently, when I create a new mailing list with MM3 the value for "Archive policy" is always set to "Public archives". I'd like to change the default value for "Archive policy" to "Do not archive this list". How can I do this? In Debian 12 I find in </usr/lib/python3/dist-packages/postorius/forms/list_forms.py>: mlist_properties = ['archivers'] archive_policy_choices = ( ('public', _('Public archives')), ('private', _('Private archives')), ('never', _('Do not archive this list')), ) archive_rendering_mode_choices = ( ('text', _('Plain text')), ('markdown', _('Markdown text')), ) archive_policy = forms.ChoiceField( choices=archive_policy_choices, widget=forms.RadioSelect, label=_('Archive policy'), help_text=_('Policy for archiving messages for this list'), ) but have no idea how to change the settings here. Your help is very appreciated. Best regards, Markus Grandpré -- Markus Grandpré Universität Konstanz Kommunikations-, Informations- und Medienzentrum (KIM) Abteilung IT-Dienste Forschung, Lehre und Infrastruktur Sachgebiet Diensteadministration Tel: ++49 7531 88 4342

4 6

Creating users via RestAPI / User-Management - a bunch of questions
by Christian Schneider June 23, 2025

June 23, 2025

Dear Mark and companions, somehow I can not cope with the user management... (I am running a venv-installation, latest stable versions) I read this manual: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… and played with the RestAPI calls... I know about the fine grained differences between user and member, admin/owner, superuser... and about the two user databases in PostgreSQL and Django-Framework. What I stumble upon is the RestAPI calls to create a "working" user (with the ability to login via WebUI). When I follow the manual (from the url above) I create a user (including password) that appears in the PostgreSQL database. (And this user is visible on the User-URL (https://example.com/mailman3/users)) Even when I (via WebUI) set the user as "approved" this user is not able to log in... I assume this restriction is in accordance to the fact that there is not equivalent Django user. (There was a mail in the archive of the MM3 user group...stating that one has to use the Django RestAPI to create the appropriate user) When I create the user using the WebUI (https://example.com/accounts/signup/?next=/mailman3/lists/) the new user is created in the right (complete) way...appearing in the PostgreSQL database and as a user in Django. How is this sync between the two databases realized? (The Django user also has the correct status (no staff status / no superuser status / just active status) how is this realized?) As I am not very familiar with python programming (I know Perl/Java/C++ and have an (maybe outdated) concept of OOP), is there a quick way to implement this kind of sync by copying the register logic from mailman's python action script for registering? Other questions: Will there be a create_admin_user-script that is callable via CLI (like createsuperuser or create_list)? (This script ought create a user in PostgreSQL and as Django user) How will a social account provider (like oidc) linkage (in Django) fit in this concept? Will oidc-accounts be copied to the Django's user database (or PostgreSQL db) or is it an on-the-fly check against the oidc-provider? (I assume second option) What are the status-flags (staff status/superuser status/active status) of the linked oidc-accounts? (Can I specify the status flags?) A conceptual thought: When "user1" (with email user1(a)example.com) is known to django via oidc linkage and I create "user1" (also with email user1(a)example.com) via RestAPI calls (following the url https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…) do I have a "complete" user then? I mean a user who is able to login and who can be assigned to a list as admin (e.g.) (In this case I would not have to care about the Django user database... ;-)) Thank you for some clarifying hints... :-) Chris

3 3