Can disabled users enable themself?
Hi,
users can get disabled if there are too many bounces.
Is there an easy possibility for the disabled users to enable themself on their own? I checked the email they get, however, there is no link. Only the owner's email address.
What is the solution in such a case?
Thank you for the information.
Flo
On July 1, 2026 11:20:02 AM PDT, Flo via Mailman-users <mailman-users@mailman3.org> wrote:
Hi,
users can get disabled if there are too many bounces.
Is there an easy possibility for the disabled users to enable themself on their own? I checked the email they get, however, there is no link. Only the owner's email address.
Assuming you have Postorius or another web list management UI, the user can go to the web UI and set their list delivery enabled.
You can create a custom list.user.notice.warning template to include instructions in the email.
-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.
On 7/1/26 9:16 PM, Mark Sapiro wrote:
On July 1, 2026 11:20:02 AM PDT, Flo via Mailman-users <mailman-users@mailman3.org> wrote:
Hi,
users can get disabled if there are too many bounces.
Is there an easy possibility for the disabled users to enable themself on their own? I checked the email they get, however, there is no link. Only the owner's email address.
Yes, that's true, however, an account needs to be set up. I see this as unrealistic for a regular user of the list I am thinking of.
I was hoping for a links where I can choose immediately after clicking if I want to be enabled or stay disabled.
I see an email to the owner as only realistic possibility. Or is there mail command for getting enabled? I can't find any, either ...
Assuming you have Postorius or another web list management UI, the user can go to the web UI and set their list delivery enabled.
I have Postorius.
You can create a custom list.user.notice.warning template to include instructions in the email.
That's a good idea, whatever the solution is.
Thank you for your help.
Flo
On 7/1/26 12:46 PM, Flo via Mailman-users wrote:
Yes, that's true, however, an account needs to be set up. I see this as unrealistic for a regular user of the list I am thinking of.
Yes, that can be a difficulty for some users.
I was hoping for a links where I can choose immediately after clicking if I want to be enabled or stay disabled.
Currently, there is no such link.
I see an email to the owner as only realistic possibility. Or is there mail command for getting enabled? I can't find any, either ...
And, there currently is no email command to enable delivery.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
depending on your problem/setup, the VERP-probes-feature might be worth a look:
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/model/docs/...
Am 02.07.26 um 01:53 schrieb Mark Sapiro:
On 7/1/26 12:46 PM, Flo via Mailman-users wrote:
Yes, that's true, however, an account needs to be set up. I see this as unrealistic for a regular user of the list I am thinking of.
Yes, that can be a difficulty for some users.
I was hoping for a links where I can choose immediately after clicking if I want to be enabled or stay disabled.
Currently, there is no such link.
I see an email to the owner as only realistic possibility. Or is there mail command for getting enabled? I can't find any, either ...
And, there currently is no email command to enable delivery.
On 7/2/26 12:57 PM, Alexander Inzinger-Zrock via Mailman-users wrote:
depending on your problem/setup, the VERP-probes-feature might be worth a look:
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/model/ docs/bounce.html#verp-probes
Other than myself not being familiar with this interface it looks to me that it doesn't meet my needs.
I have a low volume list with is only used occasionally. If bounces are coming back on one occasion it should probe these addresses every other month four times. This means after eight months it should be removed, if no bounces appear anymore, it should be set back to normal.
I will go the way to tell the user in the disabled email that he/she needs to email the list owner to be enabled on the list again.
Flo
On 7/2/26 1:30 PM, Flo via Mailman-users wrote:
Other than myself not being familiar with this interface it looks to me that it doesn't meet my needs.
That may not be the case. It depends on why the user's mail is bouncing.
With verp probes enabled, when a user's bounce score reaches threshold, instead of disabling delivery, Mailman sends a probe message and only disables delivery if the probe bounces.
The idea is if the user's MTA is bouncing the mail because of spam filtering or something similar, the probe will hopefully not bounce.
There is another setting to disable attaching the bounce DSN to the probe in cast the bounce DSN itself contains things that cause the bounce. See <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/config/schema.c...>.
I have a low volume list with is only used occasionally. If bounces are coming back on one occasion it should probe these addresses every other month four times. This means after eight months it should be removed, if no bounces appear anymore, it should be set back to normal.
What are your list settings for bounce processing? With a list that apparently only gets one post in a few months, the default settings
Bounce score threshold = 5 Bounce info stale after = 7d
will not disable delivery for any one as disabling would require 5 bounces with no more than 7 days between any two bounces.
For your above scenario, you might want something like
Bounce score threshold = 4 Bounce info stale after = 60d
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 7/2/26 11:06 PM, Mark Sapiro wrote:
What are your list settings for bounce processing? With a list that apparently only gets one post in a few months, the default settings
Bounce score threshold = 5 Bounce info stale after = 7d
will not disable delivery for any one as disabling would require 5 bounces with no more than 7 days between any two bounces.
For your above scenario, you might want something like
Bounce score threshold = 4 Bounce info stale after = 60d
To make it more clear: This list is promoting events, 2-3 in spring and 2 in fall and two towards the end of the year. For each event one (or maybe two) emails are sent.
I thought I will use the following settings: Bounce score threshold 2 Bounce info stale after 60d Bounce disabled warnings interval 60d Bounce disable warnings 5
If there are bounces at two events the account will be disabled. Afterwards mailman should check every 60d if this continues. In this case it is done by sending out emails. Then I'd wish that the user is enabled if email doesn't bounce anymore. But since this is not the way it works, the user needs to take action and email the owner of the list to be enabled again. If this is not done (IE: mails are still bouncing), the user is to be removed. That's my plan.
Flo
On 7/4/26 2:09 PM, Flo via Mailman-users wrote:
I thought I will use the following settings: Bounce score threshold 2 Bounce info stale after 60d Bounce disabled warnings interval 60d Bounce disable warnings 5
If there are bounces at two events the account will be disabled. Afterwards mailman should check every 60d if this continues. In this case it is done by sending out emails. Then I'd wish that the user is enabled if email doesn't bounce anymore. But since this is not the way it works, the user needs to take action and email the owner of the list to be enabled again. If this is not done (IE: mails are still bouncing), the user is to be removed. That's my plan.
With those settings, if a user records two bounces within 60 days their delivery will be disabled. At that point the user will be sent a notice and as long as delivery is not manually enabled, will be sent 4 additional notices at 60 day intervals. Then if delivery is still disabled by bounces after another 60 days (300 days total), the user will be unsubscribed.
The notice the user is sent is built from the list.user.notice.warning template, you may want to create a custom version in Postorius. The default is
Your subscription has been disabled on the $listname mailing list
because it has
received a number of bounces indicating that there may be a problem
delivering
messages to $sender_email. You may want to check with your mail
administrator
for more help.
If you have any questions or problems, you can contact the mailing list
owner at
$owner_email
Regarding
Afterwards mailman should check every 60d if this continues.
Mailman doesn't actually do any checking. It just sends the notices. It does nothing further whether or not they bounce.
You may also want to set Bounce disabled warnings interval to a value less than 60 days.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 7/5/26 3:06 AM, Mark Sapiro wrote:
The notice the user is sent is built from the list.user.notice.warning template, you may want to create a custom version in Postorius. The
Now I did this. However, the subject is still English. Can this be changed as well?
Interestingly the final unsubscribe message has a German subject but no body. Can I change that in Postorious?
Regarding
Afterwards mailman should check every 60d if this continues.
You may also want to set Bounce disabled warnings interval to a value less than 60 days.
Good idea, I'll change it to 30d/10
Thank you for your help, Flo.
On 7/5/26 6:21 AM, Flo via Mailman-users wrote:
Now I did this. However, the subject is still English. Can this be changed as well?
It should be translated. The German translation is at <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/messages/de/LC_...>, however it is translated in the user's preferred language, not the list's. What is the user's preferred language?
Interestingly the final unsubscribe message has a German subject but no body. Can I change that in Postorious?
Yes, this is the list:user:notice:goodbye template which is empty by default, however this is sent for all unsubscribes, not just those due to bounces.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 7/5/26 6:42 PM, Mark Sapiro wrote:
On 7/5/26 6:21 AM, Flo via Mailman-users wrote:
Now I did this. However, the subject is still English. Can this be changed as well?
It should be translated. The German translation is at <https:// gitlab.com/mailman/mailman/-/blob/master/src/mailman/messages/de/ LC_MESSAGES/mailman.po#L125-L126>, however it is translated in the
Line 101 is the same as line 126. While 101 is the correct translation for line 100, it's wrong for line 125. But this is no explanation for not translating.
user's preferred language, not the list's. What is the user's preferred language?
This field is empty at the user's settings, it should default to the list's language. This works for the unsubscription message, though.
Flo
On 7/5/26 1:34 PM, Flo via Mailman-users wrote:
Line 101 is the same as line 126. While 101 is the correct translation for line 100, it's wrong for line 125. But this is no explanation for not translating.
If you want to help with the German translations, you are welcome to contribute at https://hosted.weblate.org/projects/gnu-mailman/ or to contact the last translator listed in the .po file.
user's preferred language, not the list's. What is the user's preferred language?
This field is empty at the user's settings, it should default to the list's language. This works for the unsubscription message, though.
If the user's preferred language for the list is empty, fallback is to the user's address based settings and then to their global Mailman settings.
The unsubscription message to the user is also in the user's preferred language, so that probably isn't the issue.
Is the Subject message translated in your
mailman/massages/de/LC_MESSAGES/mailman.po file? if so, is the
corresponding mailman.mo up to date (if in doubt, use msgunfmt to
examine it)?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 7/6/26 12:25 AM, Mark Sapiro wrote:
On 7/5/26 1:34 PM, Flo via Mailman-users wrote:
Line 101 is the same as line 126. While 101 is the correct translation for line 100, it's wrong for line 125. But this is no explanation for not translating.
If you want to help with the German translations, you are welcome to contribute at https://hosted.weblate.org/projects/gnu-mailman/ or to contact the last translator listed in the .po file.
I will do.
user's preferred language, not the list's. What is the user's preferred language?
This field is empty at the user's settings, it should default to the list's language. This works for the unsubscription message, though.
If the user's preferred language for the list is empty, fallback is to the user's address based settings and then to their global Mailman settings.
How can I find these settings in Postorius? There is only a user's language and a list's language.
At the user's settings Postorius says:
Preferred language for your interactions with Mailman. When this is set,
it will override the MailingList's preferred language. This affects
which language is used for your email notifications and such.
The unsubscription message to the user is also in the user's preferred language, so that probably isn't the issue.
Is the Subject message translated in your mailman/massages/de/ LC_MESSAGES/mailman.po file? if so, is the corresponding mailman.mo up to date (if in doubt, use
msgunfmtto examine it)?
I found this file and also the translated message:
#: src/mailman/app/notifications.py:254
#, python-brace-format
msgid "Your subscription for ${mlist.display_name} mailing list has been
disabled"
msgstr "Sie wurden von der Mailingliste ${mlist.display_name} abgemeldet"
I can't see any wrong such that it doesn't translate.
Finally I had a look into the code of https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/app/notificatio... . This was not very efficient as I don't know Python but I found out that if I add
with _.using(language.code):on line 266 and do the correct intends below it translates. I found this by comparing send_user_disable_warning with send_goodbye_message . I also got confused by wrap and expand once being inside and once outside but apparently it works both ways.
I leave it to you how to do the changes as, having already said, I don't know Python and for me everything is like guessing instead of knowing.
Flo
On 7/6/26 6:33 AM, Flo via Mailman-users wrote:
How can I find these settings in Postorius? There is only a user's language and a list's language.
You have to be logged in as the user. Then you can go to https://example.com/mailman3/accounts/mailmansettings/ and see Global Mailman preferences, Address-based preferences and List-based preferences.
Finally I had a look into the code of https://gitlab.com/mailman/ mailman/-/blob/master/src/mailman/app/notifications.py . This was not very efficient as I don't know Python but I found out that if I add
with _.using(language.code):
on line 266 and do the correct intends below it translates.
Thank you. This is a bug and you have found the correct solution. The
issue is that although language is provided in the call to
UserNotification, that doesn't affect the translation of the Subject.
This is now reported at
https://gitlab.com/mailman/mailman/-/work_items/1287 and I will fix it.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
On 7/6/26 6:33 AM, Flo via Mailman-users wrote:
How can I find these settings in Postorius? There is only a user's language and a list's language.
You have to be logged in as the user. Then you can go to https://example.com/mailman3/accounts/mailmansettings/ and see Global Mailman preferences, Address-based preferences and List-based preferences.
To be precise, the list owner can see (and I believe set) the *user's* *subscription* preference. They can't see the global and address preferences. Do you know if the superuser can access and mutate the latter? I couldn't figure it out from a quick look at the templates.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Flo via Mailman-users writes:
How can I find these settings in Postorius? There is only a user's language and a list's language.
For the user: I visit
https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
At the bottom of the page it tells me: Primary Address (steve@turnbull.jp) ... Manage Subscription ...
Click on the "Manage Subscription" button, I get a page with links Subscriptions Global Mailman preferences Address-based preferences List-based preferences across the top under the "Mailman Settings stephenjturnbull" title.
For "Global Mailman preferences" there is a page with all of the settings documented, and "Preferred language" is the last setting. For "Address-based preferences" and "List-based preferences", there is a table, with "Preferred language" the rightmost column. Do you not see that?
For the list owner: I go to https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/members... to see the members, click on a member (I accessed your subscription since I logged in as myself, hope you don't mind) and see a full page with your subscription options. There is no way for you as *list* owner to see the users' Global or Address settings.
As *site* owner (superuser) you probably can, but can't test, I don't have that privilege on a running Mailman 3 at the moment. I don't know enough about the relevant views to be sure you can access that, but usually "superuser" allows you to Manage All The Things.
Hope that helps.
Due to GSoC evaluations, I don't have time to get up to speed to help with the other issues you're seeing. Mark probably will figure it out much more quickly, anyway. :-)
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On 7/5/26 6:42 PM, Mark Sapiro wrote:
It should be translated. The German translation is at <https:// gitlab.com/mailman/mailman/-/blob/master/src/mailman/messages/de/ LC_MESSAGES/mailman.po#L125-L126>, however it is translated in the
I created a weblate account and changed it. Now I checked the repository: There is the correct translation, however, it comes after "" and takes 3 lines. Maybe this is correct, however, it looks different than the others.
Flo
On 7/9/26 07:33, Flo via Mailman-users wrote:
I created a weblate account and changed it. Now I checked the repository: There is the correct translation, however, it comes after "" and takes 3 lines. Maybe this is correct, however, it looks different than the others.
It's just the way long lines are handled. In this case the content of the three lines
msgstr ""
"Ihre Mitgliedschaft in der Mailingliste ${mlist.display_name} wurde "
"deaktiviert"
will be concatenated into a single string. There won't be any actual line breaks unless there are '\n' in the string.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Flo via Mailman-users writes:
I was hoping for a links where I can choose immediately after clicking if I want to be enabled or stay disabled.
There is a mechanism that can be adapted for this (RFC 8058 <https://datatracker.ietf.org/doc/html/rfc8058/> "One-Click Leave"). However, this is not yet implemented in Mailman. (It is on my personal to-do list if nobody else gets there first.)
But I don't see how it solves your problem, because the user is very unlikely to receive the link in a timely fashion. The RFC 8058 links expire fairly quickly (a day or so) so that they are not likely to inadvertantly or maliciously unsubscribe the user. That means that they can't look in their saved mail for the link, assuming they even keep it. On the other hand, if Mailman sends mail to your user for any reason, and it does *not* bounce, they will be re-enabled automatically. In that case the link is unnecessary. Let me know if I'm missing something about your users.
If you want to continue to look for improvements in service to your "naive" users, I'd be happy to explore them. For example, if your users use Gmail or other state-of-the-art providers, then they have access to a "social account" that can be used to log in to Mailman as well. I have *not* thought this through, so no promises, but it might be reasonable to use a RFC 8058-style link to one-click link a "social account" to their Mailman account. It's not quite "single sign-on", but it's one less password, etc. Of course how useful that is depends on exactly why you think setting up and logging in to an account is a blocker for your users, but if you describe that we may come up with some ideas.
I personally can devote very little time to work on this until Summer of Code is over, though.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On 7/4/26 6:13 AM, Stephen J. Turnbull wrote:
On the other hand, if Mailman sends mail to your user for any reason, and it does *not* bounce, they will be re-enabled automatically.
I don't think this is correct unless you have some local modification to do this. Even then, how would it work? A bounce might come from downstream MTA and possibly not for days.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
On 7/4/26 6:13 AM, Stephen J. Turnbull wrote:
On the other hand, if Mailman sends mail to your user for any reason, and it does *not* bounce, they will be re-enabled automatically.
I don't think this is correct unless you have some local modification to do this.
Thank you for the correction.
Likely I misremembered that it would be re-enabled. I guess the stock process is the bounce count gets reset to zero after a time period with no bounces, but this isn't immediate and doesn't reenable.
When the bounce count is reset, if it's "disabled by bounce", we could then re-enable. That's like a two-line change. Perhaps with a more complex algorithm (eg, store an indicator of that Address's recent bounce history in the database, and re-disable more quickly if it has a history of bouncing recently). A complex algorithm would be more invasive (database schema addition) and I'm not suggesting that yet.
Even then, how would it work? A bounce might come from downstream MTA and possibly not for days.
Nothing that depends on bounce by DSN is reliable though. Heck, you can't even be sure that that status "250 OK" isn't somebody treating you like a spammer and eating your mail. And if you're heavy on Gmail and Yahoo users, most bounces are likely to come very quickly and reliably. It might work pretty well for some lists and horribly for others. I guess we'd have to do more parsing of the local MTA's DSNs in that case, though. Hmmm. At least we know the stock behavior of the four we support.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
participants (4)
-
Alexander Inzinger-Zrock -
Flo -
Mark Sapiro -
Stephen J. Turnbull