Bulk changes to delivery mode and moderation action
I fat-fingered a command in the Postorius UI and accidentally unsubcribed all members of a list. Oops.
Have added them back using Mass operations/Mass subscribe but this raised three questions:
In Users/Members, moderation action for the newly resubscribed users shows as "None". Is there a method, either in the UI or the command line, to change this to "Default processing" for all users?
Although Delivery Mode shows as "Regular" for all users in Users/Members list, clicking on a member's name shows all options such as delivery status, delivery mode, etc., as undefined.
Similar question: How to set subscriber options for all members in one go?
- As a subscriber to this list, I received email notification that I'd been unsubscribed. Where is the control for enabling/disabling subscription notifications?
Settings/Member Policy/Un-subscription Policy is set to Confirm, but I don't think that's relevant here since I unsubscribed users as the Django superuser.
Thanks.
dn, chastened
On 1/7/22 11:06 AM, David Newman wrote:
- In Users/Members, moderation action for the newly resubscribed users shows as "None". Is there a method, either in the UI or the command line, to change this to "Default processing" for all users?
I assume you don't want to set Default action to take when a member posts to the list to Default Processing because you want new member
posts to be held. This is a good practice. To set all members to default
processing in mailman shell
$ mailman shell -l list.example.com
Welcome to the GNU Mailman shell
Use commit() to commit changes.
Use abort() to discard changes since the last commit.
Exit with ctrl+D does an implicit commit() but exit() does not.
The variable 'm' is the list.example.com mailing list
>>> from mailman.interfaces.action import Action
>>> for mbr in m.members.members:
... mbr.moderation_action = Action.defer
...
>>> commit()
>>>
- Although Delivery Mode shows as "Regular" for all users in Users/Members list, clicking on a member's name shows all options such as delivery status, delivery mode, etc., as undefined.
They show as undefined, but if you look at your own settings by
selecting Mailman settings from the dropdown under your username at
the upper right in Postorius, you will see you have Global Mailman
preferences, Address-based preferences and List-based preferences. If a
list based preference is unset for a list, it falls back to the address
based preference for the address and if that's unset, to the global
preference.
When you as an admin look at a user, you only see the user's list based preferences.
Similar question: How to set subscriber options for all members in one go?
Per the above, you only need to set the user's preferences if they don't have address based preferences and the preference differs from the global (default) preferences.
However, if you want to set the member's list preferences, you could add to the beginning of the above:
>>> from mailman.interfaces.member import DeliveryMode, DeliveryStatus
>>> english = getUtility(ILanguageManager).get('en')
and to the for loop in the above:
... mbr.preferences.acknowledge_posts = False
... mbr.preferences.delivery_mode = DeliveryMode.regular
... mbr.preferences.delivery_status = DeliveryStatus.enabled
... mbr.preferences.hide_address = False
... mbr.preferences.preferred_language = english
... mbr.preferences.receive_list_copy = False
... mbr.preferences.receive_own_postings = True
Or whatever you think these settings should be.
- As a subscriber to this list, I received email notification that I'd been unsubscribed. Where is the control for enabling/disabling subscription notifications?
Settings -> Automatic Responses
Settings/Member Policy/Un-subscription Policy is set to Confirm, but I don't think that's relevant here since I unsubscribed users as the Django superuser.
Correct.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 1/7/22 12:06 PM, Mark Sapiro wrote:
On 1/7/22 11:06 AM, David Newman wrote:
- In Users/Members, moderation action for the newly resubscribed users shows as "None". Is there a method, either in the UI or the command line, to change this to "Default processing" for all users?
I assume you don't want to set
Default action to take when a member posts to the listto Default Processing because you want new member posts to be held. This is a good practice. To set all members to default processing in mailman shell
..
OK, thanks
- Although Delivery Mode shows as "Regular" for all users in Users/Members list, clicking on a member's name shows all options such as delivery status, delivery mode, etc., as undefined.
They show as undefined, but if you look at your own settings by selecting
Mailman settingsfrom the dropdown under your username at the upper right in Postorius, you will see you have Global Mailman preferences, Address-based preferences and List-based preferences. If a list based preference is unset for a list, it falls back to the address based preference for the address and if that's unset, to the global preference.When you as an admin look at a user, you only see the user's list based preferences.
Thanks. This makes sense, but something's wrong with this particular list.
I was able to change preferences using the shell commands you kindly provided. All list member now have regular delivery and default moderation.
However, there's no evidence test messages to the list are going out. (Nondelivery was the reason I was mucking around in the admin panel in the first place.)
The Postfix log shows delivery to the list address.
MM3's smtp.log shows the usual handshake.
However, I do not then see messages going out to subscribers in the Postfix log, and as one of those subscribers I do not receive a copy even though my preferences are set to receive my own posts.
The admin panel shows 0 messages held for moderation.
Another mailing list in the same domain on the same server delivers mail to all subscribers OK.
This is surely config problem on my end, but which log(s) and/or admin panel setting(s) to check?
Thanks again.
dn
Similar question: How to set subscriber options for all members in one go?
Per the above, you only need to set the user's preferences if they don't have address based preferences and the preference differs from the global (default) preferences.
However, if you want to set the member's list preferences, you could add to the beginning of the above:
>>> from mailman.interfaces.member import DeliveryMode, DeliveryStatus >>> english = getUtility(ILanguageManager).get('en')and to the
forloop in the above:... mbr.preferences.acknowledge_posts = False ... mbr.preferences.delivery_mode = DeliveryMode.regular ... mbr.preferences.delivery_status = DeliveryStatus.enabled ... mbr.preferences.hide_address = False ... mbr.preferences.preferred_language = english ... mbr.preferences.receive_list_copy = False ... mbr.preferences.receive_own_postings = TrueOr whatever you think these settings should be.
- As a subscriber to this list, I received email notification that I'd been unsubscribed. Where is the control for enabling/disabling subscription notifications?
Settings -> Automatic Responses
Settings/Member Policy/Un-subscription Policy is set to Confirm, but I don't think that's relevant here since I unsubscribed users as the Django superuser.
Correct.
On 1/7/22 1:51 PM, David Newman wrote:
However, there's no evidence test messages to the list are going out. (Nondelivery was the reason I was mucking around in the admin panel in the first place.)
The Postfix log shows delivery to the list address.
MM3's smtp.log shows the usual handshake.
However, I do not then see messages going out to subscribers in the Postfix log, and as one of those subscribers I do not receive a copy even though my preferences are set to receive my own posts.
Are the messages in Mailman's var/queue/shunt queue? Are there errors and tracebacks in var/logs/mailman.log?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 1/7/22 2:48 PM, Mark Sapiro wrote:
On 1/7/22 1:51 PM, David Newman wrote:
However, there's no evidence test messages to the list are going out. (Nondelivery was the reason I was mucking around in the admin panel in the first place.)
The Postfix log shows delivery to the list address.
MM3's smtp.log shows the usual handshake.
However, I do not then see messages going out to subscribers in the Postfix log, and as one of those subscribers I do not receive a copy even though my preferences are set to receive my own posts.
Are the messages in Mailman's var/queue/shunt queue?
There are 24 messages in the shunt queue, the most recent of which is a digest from 0000 hours today. The test messages I sent later today are not there.
There are also 13 messages in the out queue. I can't read these as the filenames appear to change on every invocation of ls.
Are there errors and tracebacks in var/logs/mailman.log?
Not in response to today's test messages. Here is an entry of a test message I sent going to Hyperkitty.
Jan 07 12:49:03 2022 (252309) HyperKitty archived message <6e88ec49-1326-92f9-aa17-1d4c1d6828be@domain.tld> to https://lists.domain.tld/archives/list/listname@lists.domain.tld/message/FHY...
But the Postfix log doesn't show it being distributed to me or anyone else.
Oddly, neither of the two list owner emails (me and someone else) show this message in the archive via the admin panel. However if I log in as the list owner directly to the archives:
https://lists.domain.tld/archives/
I can see today's test posts if logged in as the list member, but do not see the posts if logged directly into the archive as the Django superuser.
The nondelivery of list mail is more serious than the archive problem, though.
Thanks in advance for further troubleshooting clues.
dn
On 1/7/22 3:41 PM, David Newman wrote:
There are 24 messages in the shunt queue, the most recent of which is a digest from 0000 hours today. The test messages I sent later today are not there.
There are also 13 messages in the out queue. I can't read these as the filenames appear to change on every invocation of ls.
I suspect an issue trying to connect to the MTA to send the messages. This can be caused by permission errors. Check permissions on Mailman's var/templates/*
Are there errors and tracebacks in var/logs/mailman.log?
Every message in the shunt queue should have an exception and traceback logged in mailman.log.
But the Postfix log doesn't show it being distributed to me or anyone else.
Is there a 'Cannot connect to SMTP server ... on port ...' anywhere in mailman.log?
Oddly, neither of the two list owner emails (me and someone else) show this message in the archive via the admin panel. However if I log in as the list owner directly to the archives:
https://lists.domain.tld/archives/
I can see today's test posts if logged in as the list member, but do not see the posts if logged directly into the archive as the Django superuser.
That seems strange, I don't know why the superuser would not be able to see things in the archive that a list owner or member can.
The nondelivery of list mail is more serious than the archive problem, though.
Archiving is separate from delivery. messages can be archived and still fail delivery in the out runner which is what's happening here. The question is why?
I suspect you have one or more 'Cannot connect to SMTP server ... on port ...' messages in mailman.log? and I suspect this is a misleading issue in this case caused by an inability to read some file in Mailman's var/templates/lists/<list_id>/en directory.
I also suspect the shunted messages are from some prior condition which
has possibly been fixed, but I can't be sure without exceptions and
tracebacks from mailman.log (should be timestamped the same as the mod
time if the shunted file). You can view them with mailman qfile and
unshunt (reprocess) them with mailman unshunt.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 1/7/22 4:32 PM, Mark Sapiro wrote:
On 1/7/22 3:41 PM, David Newman wrote:
There are 24 messages in the shunt queue, the most recent of which is a digest from 0000 hours today. The test messages I sent later today are not there.
There are also 13 messages in the out queue. I can't read these as the filenames appear to change on every invocation of ls.
I suspect an issue trying to connect to the MTA to send the messages. This can be caused by permission errors. Check permissions on Mailman's var/templates/*
Bingo. This list had regular and digest footer templates with 0644 permissions owned by root:root, and there was an exception and traceback for the most recent message in shunt about the permissions issue.
I've changed ownership to mailman:mailman and restarted the mailman3 service.
As soon as I fixed this, my inbox filled with test messages...
Are there errors and tracebacks in var/logs/mailman.log?
Every message in the shunt queue should have an exception and traceback logged in mailman.log.
But the Postfix log doesn't show it being distributed to me or anyone else.
Is there a 'Cannot connect to SMTP server ... on port ...' anywhere in mailman.log?
Yes, lots. This might or might not be a different issue.
As I mentioned earlier, the most recent message in shunt was from 0000 hours today. There are many "Cannot connect" messages since then, but none since fixing the issue above.
Oddly, neither of the two list owner emails (me and someone else) show this message in the archive via the admin panel. However if I log in as the list owner directly to the archives:
https://lists.domain.tld/archives/
I can see today's test posts if logged in as the list member, but do not see the posts if logged directly into the archive as the Django superuser.
That seems strange, I don't know why the superuser would not be able to see things in the archive that a list owner or member can.
Seems OK now. The superuser sees all posts after the unshunt action.
Thanks very much for your help with this.
dn
The nondelivery of list mail is more serious than the archive problem, though.
Archiving is separate from delivery. messages can be archived and still fail delivery in the out runner which is what's happening here. The question is why?
I suspect you have one or more 'Cannot connect to SMTP server ... on port ...' messages in mailman.log? and I suspect this is a misleading issue in this case caused by an inability to read some file in Mailman's var/templates/lists/<list_id>/en directory.
I also suspect the shunted messages are from some prior condition which has possibly been fixed, but I can't be sure without exceptions and tracebacks from mailman.log (should be timestamped the same as the mod time if the shunted file). You can view them with
mailman qfileand unshunt (reprocess) them withmailman unshunt.
On 1/7/22 6:07 PM, David Newman wrote:
On 1/7/22 4:32 PM, Mark Sapiro wrote:
I suspect an issue trying to connect to the MTA to send the messages. This can be caused by permission errors. Check permissions on Mailman's var/templates/*
Bingo. This list had regular and digest footer templates with 0644 permissions owned by root:root, and there was an exception and traceback for the most recent message in shunt about the permissions issue.
That comes from running mailman import21 as root. Always run
mailman commands as the Mailman user.
I've changed ownership to mailman:mailman and restarted the mailman3 service.
As soon as I fixed this, my inbox filled with test messages...
Good!
Is there a 'Cannot connect to SMTP server ... on port ...' anywhere in mailman.log?
Yes, lots. This might or might not be a different issue.
It is exactly this issue which is now corrected.
As I mentioned earlier, the most recent message in shunt was from 0000 hours today. There are many "Cannot connect" messages since then, but none since fixing the issue above.
The Cannot connect messages are from the issue of ownership of the templates and Mailman's out runner continually retrying the send. This is separate from the shunted messages.
Seems OK now. The superuser sees all posts after the unshunt action.
So it appears that you ran mailman unshunt and the shunted messages
were successfully processed, so whatever caused them to be shunted in
the first place is fixed. Individual messages don't get shunted because
of this template ownership issue, but it may be that digests do get
shunted for this reason.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
David Newman -
Mark Sapiro