- Mailman-users - lists.mailman3.org

server/accounts/confirm-email/ lacks skinning (css)
by Wikinaut July 30, 2025

July 30, 2025

The newly installed mailman3 systems works, however the page accounts/confirm-email/ lacks the css. Can someone confirm my observation? Is there a fix?

2 1

Upgrading other python packages than the mailman ones in a venv results in dependency conflicts
by Ulf R. July 29, 2025

July 29, 2025

Hello, I know this should be the way to upgrade: https://docs.mailman3.org/en/latest/upgrade-guide.html I have 3.3.10 installed. I saw that some python packages are outdated an tried this which install all outdated packages in a row: pip list --outdated --format=json | jq '.[].name' | xargs -n1 pip install -U One outdated package was django and this part happened: ------------------------------- vDownloading Django-5.1.4-py3-none-any.whl (8.3 MB) Installing collected packages: Django Attempting uninstall: Django Found existing installation: Django 4.2.16 Uninstalling Django-4.2.16: Successfully uninstalled Django-4.2.16 ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts. hyperkitty 1.3.12 requires django<5.1,>=4.2, but you have django 5.1.4 which is incompatible. mailman-web 0.0.9 requires django<4.3,>=4.0, but you have django 5.1.4 which is incompatible. postorius 1.3.13 requires django<5.1,>=4.2, but you have django 5.1.4 which is incompatible. django-mailman3 1.3.15 requires django<5.1,>=4.2, but you have django 5.1.4 which is incompatible. Successfully installed Django-5.1.4 ------------------------------- So I made a roll back. Is this really the only secure way to update the venv?: pip install -U mailman postorius django-mailman3 hyperkitty mailman-web May be yes and I have to ignore the rest? ;-) Thank you und regards

5 6

Missing Archived emails - Hyperkitty - CERT Issue
by willie.castillo＠caemilusa.com July 29, 2025

July 29, 2025

Looks like "hyperkitty" stopped archiving right after the CERT for the mailman3 website expired, How can I make the missing archives visible on the website? I see there "*pck" files in the/opt/mailman/mm/var/archives/hyperkitty/spool/ directory. The list archive does not show that last posting [of 25 July 2025. ~$ ll -t /opt/mailman/mm/var/archives/hyperkitty/spool/ -rw-rw---- 1 mailman mailman 98215 Jul 25 12:01 1753459289.7901242+f3fd7ee77272862f8c1023394bf88d0d4bbe9053.pck -rw-rw---- 1 mailman mailman 98109 Jul 25 12:01 1753459289.7726512+ee1264c36a194eb0ec1a52089f053e6963f24369.pck -rw-rw---- 1 mailman mailman 88479 Jul 25 12:01 1753459289.7564857+2e27f35a57f757f058dc95e34c56722a76307900.pck The CERT on the website is now up-to-date

5 11

PGP - S/MIME signed messages
by Peter Adebahr July 29, 2025

July 29, 2025

Hi * we are receiving a few PGP-signed posts as a S/MIME attachment. Some final recipients check these, and as mailman3 does not munge them - the original mail is signed, not mailman3's final posts - those get rejected. Does anyone have a idea how to handle this elegantly? Thank you Peter

4 3

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]

2 5

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

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