- Mailman-users - lists.mailman3.org

Hyperkitty error - not archiving
by Odhiambo Washington July 26, 2025

July 26, 2025

I am seeing the error below and wondering what's the cause: Jul 25 13:35:05 2025 (944) Could not archive the message with id < CO1PR06MB798076961F096CAA4DB9A2FCBB59A(a)CO1PR06MB7980.namprd06.prod.outlook.com > Jul 25 13:35:05 2025 (944) archiving failed, re-queuing (mailing-list testlist.my.domain, message < CO1PR06MB798076961F096CAA4DB9A2FCBB59A(a)CO1PR06MB7980.namprd06.prod.outlook.com >) Jul 25 13:35:05 2025 (944) Exception in the HyperKitty archiver: <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Server Error</title> <link rel="shortcut icon" href="/static/postorius/img/favicon.ico"> <link rel="stylesheet" href="/static/postorius/libs/bootstrap/css/bootstrap.min.css"> <link rel="stylesheet" href="/static/django-mailman3/css/main.css"> <link rel="stylesheet" href="/static/postorius/css/style.css"> </head> <body> <div class="container"> <h1>Server error</h1> <div class="alert alert-danger">An error occurred while processing your request.</div> </div> </body> </html> Jul 25 13:35:05 2025 (944) Traceback (most recent call last): File "/opt/mailman/venv/lib/python3.11/site-packages/mailman_hyperkitty/__init__.py", line 158, in _archive_message url = self._send_message(mlist, msg) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/mailman_hyperkitty/__init__.py", line 228, in _send_message raise ValueError(result.text) ValueError: -- 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]

1 0

Advice on how to set announcement only lists?
by Sparks, Paul July 25, 2025

July 25, 2025

Here's the basics of what I'm trying to set up: The Web UI is not available. CLI tools are being used for configuration and ongoing maintenance functions. The server instance is ephemeral, but has persistent storage for postfix / mailman configuration. There are a series of notification lists list-0000(a)example.com, list-0001(a)example.com, etc. Users can subscribe / unsubscribe via email. A list-all(a)example.com list can be used to send posts to all lists (this is rare). A siteadmin(a)example.com email address is the only sender allowed to post to any list. A list-admin(a)example.com list is defined. This list should be copied on all posts that are sent to any of the notification lists. The admin list membership is maintained via CLI tools by list admins Below are a couple of ideas I've played around with, but haven't gotten a good solution. Suggestions would be welcome. I've had a little experience with the CLI tools, but I'm not having luck with trying to add non-members. Idea 1 Have list-all(a)example.com be an umbrella list with all notifications lists as members. list-admin(a)example.com is added to all lists as a member siteadmin(a)example.com is added to all notification lists as a member with moderation_action = Action.defer to allow sending posts. ues-all(a)example.com is added to all notification lists as a member with moderation_action = Action.defer to allow "nested" sending to members of the list-all list. There seem to be issues with having the senders as members of the list. Having them as non-members might be a solution, but I haven't yet figured out how to add non-members via CLI. Idea 2 Use cron with CLI tools to extract all notification list members and update (mailman syncmembers) the list-all membership. Use script to add all list-admin users to each notification list. Update all notification lists when the list-admin membership changes. This is somewhat problematic since individuals could be direct members of notification lists and removal from list-admin would remove the direct membership. siteadmin(a)example.com is added to all lists as a member with moderation_action = Action.defer to allow sending posts. ________________________________ 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

Relay Access Denied
by jkoral＠luc.edu July 23, 2025

July 23, 2025

I have recently migrated my lists from an old mailman2 server to a new mailman3 server. The new server is named listservnew and the old server is called lists. Everything is working on the new server using the new name, but after changing the DNS of lists to point to the new server, I am getting Relay Access Denied. We are running this through an F5 and the RCPT from unknown is the F5 IP address. When I add that IP to the main.cf under mynetworks, I get a different error. Error before changing main.cf: 2025-07-20T22:14:30.381945-05:00 lstprdls01 postfix/smtpd[3713490]: NOQUEUE: reject: RCPT from unknown[10.18.3.105]: 454 4.7.1 <joetest(a)lists.luc.edu>: Relay access denied; from=<jkoral(a)luc.edu> to=<joetest(a)lists.luc.edu> proto=ESMTP helo=<DM1PR04CU001.outbound.protection.outlook.com> Error after adding F5 IP to mynetworks: 2025-07-22T11:27:13.885111-05:00 lstprdls01 postfix/smtp[174935]: AB1C11C0229: to=<joetest(a)lists.luc.edu>, relay=lists.luc.edu[147.126.1.184]:25, delay=0.16, delays=0.11/0.01/0.04/0, dsn=5.4.6, status=bounced (mail for lists.luc.edu loops back to myself) Any help would be greatly appreciated.

4 10

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

July 21, 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 7

Block members from sending cc's and bcc's
by Cathryn McGuire July 19, 2025

July 19, 2025

Hi everyone, Using Mailman 3 with Affinity web interface and we want to stop our members from sending to cc: or bcc: We've found the Header Filter and cc and bcc appear in it. Tried to configure it to "hold for moderation," but it hasn't worked. Partly because we don't understand what to put in the Pattern input box. I put in cc: because it requires something. Can anyone advise? Cheers, Cathryn

2 10

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 ```

5 9

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