- Mailman-users - lists.mailman3.org

Mailman appears to send an email to a closed list, from a member who was removed from that list
by Andy Matthews July 18, 2025

July 18, 2025

My project is doing testing of our mailing lists and came across what appears to be a bug. I believe it's not but she insists that it is. So before I do a bunch of research I wanted to post my steps to reproduce and ask for input. I'm including the full (redacted) mailing list config at the bottom of this post for reference. * I have a closed mailing list, acme-closed(a)foo.com * That mailing list has multiple subscribers, including user-1. I confirmed this by shelling into our server and running `mailman members acme-closed(a)foo.com --role=any` on the OS command line. This showed all of the subscribers, including user-1. * I sent an mail FROM user-1 TO acme-closed, and it was received. And by that I mean I received an email TO acme-closed, FROM user-1. I also received the same email emails sent to the other subscribers since I use a catch all address for local testing. * In our system I closed user-1's account (which removes that user from the mailing list). I confirmed this by running the `mailman members` command and noting that user-1 was no longer a subscriber. * I sent another mail FROM user-1 TO acme-closed, and received two emails. One showed what appears to be a successful send to the mailing list. It showed acme-closed as the TO address, and user-1 as the sender. But I also received a second email TO user-1 FROM acme-closed whose body reads "Your message to the Acme-closed mailing-list was rejected for the following reasons: The message is not from a list member. The original message as received by Mailman is attached." So my PM is insistent that the first email is proof that there's a bug. "No e-mail sent from an e-mail address for a closed account should be sent to the mailing list." I on the other hand am arguing that the second email is proof that the email _wasn't_ actually sent to the list, and was instead a sort of bounceback to the user, However it's tough to argue with her logic because I agree the first email seems to have been incorrectly sent. Can you help me understand why the first email was sent, and if there's a way to prove with certainty that Mailman is behaving correctly? ``` accept_these_nonmembers: [] acceptablealias: [] admin_immed_notify: True admin_notify_mchanges: True administrators: [5 <Members>] administrivia: True advertised: False allow_list_posts: True anonymous_list: False archive_policy: ArchivePolicy.private archive_rendering_mode: ArchiveRenderingMode.text autorespond_owner: ResponseAction.none autorespond_postings: ResponseAction.none autorespond_requests: ResponseAction.none autoresponse_grace_period: 90 days, 0:00:00 autoresponse_owner_text: autoresponse_postings_text: autoresponse_request_text: bounce_info_stale_after: 7 days, 0:00:00 bounce_matching_headers: bounce_notify_owner_on_bounce_increment: False bounce_notify_owner_on_disable: True bounce_notify_owner_on_removal: True bounce_score_threshold: 5 bounce_you_are_disabled_warnings: 3 bounce_you_are_disabled_warnings_interval: 7 days, 0:00:00 bounces_address: acme-closed-bounces(a)foo.com collapse_alternatives: True convert_html_to_plaintext: False created_at: 2025-07-18 17:22:54.921936 data_path: /var/mailman/lists/acme-closed.(a)foo.com default_member_action: Action.accept default_nonmember_action: Action.reject description: closed digest_is_default: False digest_last_sent_at: None digest_members: [] digest_send_periodic: True digest_size_threshold: 30.0 digest_volume_frequency: DigestFrequency.monthly digests_enabled: True discard_these_nonmembers: [] display_name: Acme-closed dmarc_addresses: [] dmarc_mitigate_action: DMARCMitigateAction.munge_from dmarc_mitigate_unconditionally: False dmarc_moderation_notice: dmarc_wrapped_message_text: domain: <Domain @foo.com> emergency: False encode_ascii_prefixes: False filter_action: FilterAction.discard filter_content: False filter_extensions: [] filter_types: [] first_strip_reply_to: None forward_auto_discards: True forward_unrecognized_bounces_to: UnrecognizedBounceDisposition.discard fqdn_listname: acme-closed(a)foo.com gateway_to_mail: False gateway_to_news: False hold_these_nonmembers: [] id: 2 include_rfc2369_headers: True info: join_address: acme-closed-join(a)foo.com last_digest_recipients: [] last_post_at: 2025-07-18 17:26:28.155475 leave_address: acme-closed-leave(a)foo.com linked_newsgroup: list_id: acme-closed.(a)foo.com list_name: acme-closed mail_host: @foo.com max_days_to_hold: 0 max_message_size: 20000 max_num_recipients: 0 member_moderation_notice: member_roster_visibility: RosterVisibility.moderators members: [6 members] metadata: MetaData() moderator_password: None moderators: [5 Members] newsgroup_moderation: NewsgroupModeration.none next_digest_number: 1 next_request_id: 1 nntp_prefix_subject_too: True no_reply_address: noreply(a)foo.com nonmember_rejection_notice: nonmembers: [2 Members] obscure_addresses: True owner_address: acme-closed-owner(a)foo.com owner_chain: default-owner-chain owner_pipeline: default-owner-pipeline owners: [] pass_extensions: [] pass_types: [] personalize: Personalization.none post_id: 2 posting_address: acme-closed(a)foo.com posting_chain: default-posting-chain posting_pipeline: default-posting-pipeline preferred_language: <Language [en] English (USA)> process_bounces: False regular_members: [6 Members] reject_these_nonmembers: [] reply_goes_to_list: ReplyToMunging.no_munging reply_to_address: None request_address: acme-closed-request(a)foo.com require_explicit_destination: True respond_to_post_requests: False scrub_nondigest: False send_goodbye_message: False send_welcome_message: False subject_prefix: [Acme-closed] subscribe_address: acme-closed-subscribe(a)foo.com subscribers: 13 Members] subscription_policy: SubscriptionPolicy.moderate topics: [] topics_bodylines_limit: 5 topics_enabled: False unsubscribe_address: acme-closed-unsubscribe(a)foo.com unsubscription_policy: SubscriptionPolicy.confirm usenet_watermark: None volume: 1 ```

1 0

Enforcing SSO and subscription options
by dlb-ml＠anl.gov July 18, 2025

July 18, 2025

Contrary to the messages I found in the archive, rather trying to delete or remove the social login portion of the sign in page, I'm looking to see if there's any way to isolate the third-party login section and prevent local account sign in and sign up. This way, we can ensure that the people within our organization are using a stronger auth method that prioritizes MFA, rather than just username/password. To do this, our plan is to block signups using "ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter'" and to remove the portions of the login template such that the username/password/forgot password fields are removed, leaving just the button to our SSO instance. I'm anticipating that this should be sufficient to block username/password sign ins, and is resistant to page manipulation due to CSRF tokens, but I wanted to ask to see if there was a better way, like an official configuration (which I have not found yet). I did see that there is the SOCALACCOUNT_ONLY option, as provided by allauth (https://docs.allauth.org/en/latest/socialaccount/configuration.html) but that broke any attempt to display the sign in page, and I'm assuming is not supported with the current version of MM3. Is my plan to modify the templates viable? Additionally, because external users would not have access to their own dashboards within the web UI, and since we are planning on disabling anonymous subscriptions with "SHOW_ANONYMOUS_SUBSCRIBE_FORM=False", the only two viable ways to subscribe to a list for them would be: 1) Send a request directly to the list owner or a superadmin to subscribe/unsubscribe the address 2) Allow email commands to subcribe/unsubscribe users (i.e. $LISTNAME-join@$DOMAIN) Given the discussions on disabling the anonymous subscription form, are the email commands a less spam-susceptible solution or are they just as vulnerable as the form? Thanks

4 5

Customize subjects
by johannes.wolf＠kaaw.de July 17, 2025

July 17, 2025

Hi there, we have just started with internal tests around Mailman3 before we want to use it productively. Our instance runs on a virtualised Debian server. We have now started to work with the templates and created a new template ‘list:user:action:subscribe.txt’ under /var/lib/mailman3/templates/site/de. Unfortunately, we can't find out how to customise the subject of the email. Can anyone help us here? Regards Johannes

4 7

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