Hi!
Thank you, Mark, for giving me something to go on! I'll dig further.
Cheers,
David
On Wed, 2021-06-23 at 06:59 -0700, Mark Sapiro wrote:
On 6/23/21 6:30 AM, David Partain via Mailman-users wrote:
Hi,
Firstly, a repeat that I have a relatively broken (and soon to be fixed, I hope) installation of mailman3 based on Ubuntu 18.04 distrib packages (3.1.1-9) that stumbles along by me dealing with a bunch of things by hand that I hope'll go away once I'm up to the current version.
In this set-up, I get a fair number of items shunted. Since I have this wonky version where stuff isn't always exposed in the web interface, I have to fix these things by hand. An example is that something gets shunted because of too many recipients, where I do:
sudo -u list mailman withlist somemailmanlist
m.max_num_recipients = 0
commit()
sudo -u list mailman unshunt
I've managed to find a number of these, such as m.max_message_size, m.require_explicit_destination, and m.administrivia.
There is some other issue here as these things should only cause a
message to be held, not shunted. Some exception is being thrown in the
process of holding the messgage, and thaty is the real issue. What are
the tracebacks in Mailman's mailman.log for these shunts?
My questions are undoubtedly foolish, but here goes:
- Is there any way to print the entire 'm' structure? If so, I'd perhaps be able to figure out the answers to my other questions.
dir(m)
or maybe you want
for x in dir(m):
... if not x.startswith('_'):
... print(f'{x}: {m.__getattribute__(x)}')
...
- Is there a way for me to correct the following shunt-ing issues with 'withlist'? I've been unable to figure out how...
a. 'moderation_reasons': [ 'Message has no subject'] / 'rule_hits': ['no-subject']
b. Some things get caught as 'rule_hits': ['nonmember-moderation']. However, if I look in the (web-based) config, it shows that non-members should be accepted but the messages are shunted nonetheless. I don't know what to look for in 'm' or how I might clear these messages.
As I note above, these things are reasons to hold the message. The
shunting occurs because something is going wrong in the holding process.
Find the errors and tracebacks in Mailman's mailman.log to see what the
real issue might be.
- I have no idea what these are telling me to do about digest messages. Suggestions? This is the entire info I get from 'mailman qfile':
------------------------------------------------------snip snip----------------------------------------------
[----- start pickle -----]
<----- start object 1 ----->
<----- start object 2 ----->
{ '_parsemsg': False,
'digest_number': 457,
'digest_path': '/var/lib/mailman3/lists/somelist/digest.31.457.mmdf',
'lang': 'en',
'listid': 'somelistid',
'version': 3,
'volume': 31,
'whichq': 'digest'}[----- end pickle -----]
------------------------------------------------------snip snip----------------------------------------------
That is telling you there was in issue in sending the digest, the
mailbox for which is
/var/lib/mailman3/lists/somelist/digest.31.457.mmdf. Unshunting that
will retry sending that digest.
I have some that have 'rule_hits': [] (it's empty) but are shunted nonetheless. I can't see anything weird other than one of the messages has a utf-8 subject. Any ideas?
Some messages that were sent to -request addresses (e.g., subscribe messages, confirm, approve messages) are being shunted. What should I do with these?
You need to find the errors in the log and figure out what the
underlying issue is. I'm guessing it's a permissions issue, possibly
because of having at one time rum mailman start as root causing files
to be created and owned by root and not be readable/writable by the
Mailman user.