Mark, please correct if I'm wrong but is the log data below produced by LMTP via Mailman core? This is from the Mailman smtp.log file. Could this somehow be an issue with how we've configured Mailman for LMTP?

Feb 01 21:36:45 2022 (289) ('127.0.0.1', 36132) >> b'LHLO aeedf7ad9f48.caltech.edu' Feb 01 21:36:45 2022 (289) ('127.0.0.1', 36132) >> b'MAIL FROM:<snap_wl-bounces+mailman=caltech.edu@caltech.edu> SIZE=4289' Feb 01 21:36:45 2022 (289) ('127.0.0.1', 36132) sender: snap_wl-bounces+mailman=caltech.edu@caltech.edu Feb 01 21:36:45 2022 (289) ('127.0.0.1', 36132) >> b'RCPT TO:<mailman@lists.caltech.edu>' Feb 01 21:36:45 2022 (289) ('127.0.0.1', 36132) recip: mailman@lists.caltech.edu Feb 01 21:36:45 2022 (289) ('127.0.0.1', 36132) >> b'DATA' Feb 01 21:36:45 2022 (289) ('127.0.0.1', 36132) >> b'QUIT'

Yes, we understand that those logs are normal. And indeed we have a list called "mailman"... Could that be confusing the software somewhere??

The thing is that we have a pretty convoluted setup for handling mailing lists messages, but it's always the same for all messages. That's why we don't understand why only a small fraction of all the moderation messages get misdelivered at random times for random lists.

I think what Dan was getting at is: Are there any other logs that would show us how a message that:

a) was accepted by Postfix on the Mailman server for local delivery to list-owner@lists.caltech.edu;

b) was therefore piped into the Mailman software;

c) came out of that processing as needing to be now delivered (remotely) to mailman@caltech.edu, rather than the actual address of the owner of the original list?

Or maybe we can turn on more verbose logging or something?

Thanks.

PS: Not to confuse things (because it doesn't apply in my example), but what happens when a list has no owner and a message is sent to list-owner?

On 2/3/22 18:55, Philippe B wrote:

Yes, we understand that those logs are normal. And indeed we have a list called "mailman"... Could that be confusing the software somewhere??

I doubt it.

Note that the log excerpt posted at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/... only shows the handling of a message sent from snap_wl-bounces+mailman=caltech.edu@caltech.edu. The envelope sender is VERPed and indicates that this message was intentionally sent to mailman@caltech.edu. I.e., when the snap_wl list created this message it intended it to go to mailman@caltech.edu.

The thing is that we have a pretty convoluted setup for handling mailing lists messages, but it's always the same for all messages. That's why we don't understand why only a small fraction of all the moderation messages get misdelivered at random times for random lists.

I think what Dan was getting at is: Are there any other logs that would show us how a message that:

a) was accepted by Postfix on the Mailman server for local delivery to list-owner@lists.caltech.edu;

b) was therefore piped into the Mailman software;

But according to the header excerpt I quote at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/... it isn't sent directly from Postfix to Mailman's LMTP runner. It gets there via ec2-12-34-56-78.us-west-2.compute.amazonaws.com

I think that's where the issue occurs. It appears that isn't even on the Mailman host, the no Mailman logging is going to help.

c) came out of that processing as needing to be now delivered (remotely) to mailman@caltech.edu, rather than the actual address of the owner of the original list?

Or maybe we can turn on more verbose logging or something?

PS: Not to confuse things (because it doesn't apply in my example), but what happens when a list has no owner and a message is sent to list-owner?

Mail to list-owner is resent by Mailman to the list owners and moderators. If there are no owners or moderators the message goes to the configured site_owner https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/handlers/owner_...

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 2/7/22 16:11, Philippe B wrote:

I think that your last sentence helped us figure out what's going on.

When Mailman generates a moderation message "To: LIST-owner" it actually delivers it to the address(es) of the LIST's moderator(s), which makes sense.

No, it delivers the message to the union of the sets of owner addresses and moderator addresses.

In all the cases where we've seen that behavior, it turns out that the list involved didn't have any moderator, and we have site_owner set to "mailman"...

You don't need to have moderators. The owners get the message too.

However, the lists had an owner, and we're not seeing those moderation messages being sent to their owner (instead). Is that something that needs to be configured explicitly somewhere?

The only things that might affect this are if Settings -> Automatic Responses -> Autorespond to list owner is Respond and discard message or if the owners delivery_status is other than DeliveryStatus.enabled.

Note that finding an owner's delivery status is tricky. The owner can find it in Postorius by going to https://www.example.com/mailman3/accounts/subscriptions/ and clicking on the entry for the list with role owner. This delivery status is not the same as the delivery status for the same address with a member role if there is one.

For an admin you could do

$ bin/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
>>> owner = m.owners.get_member('user@example.com')
>>> owner.delivery_status
<DeliveryStatus.enabled: 1>

If you needed to set it here, you could do

>>> owner.preferences.delivery_status = DeliveryStatus.enabled
>>> commit()
>>>

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 2/8/22 17:57, Philippe B wrote:

Thanks. I'm getting:

 >>> owner.delivery_status
 <DeliveryStatus.by_moderator: 4>

for the 2 lists with that odd behavior (as opposed to <DeliveryStatus.enabled: 1> for several other lists I checked).

What does that 4 mean?

It means that owner's delivery was disabled by moderator action[1]. You want to set it enabled as I indicated in my prior post at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/.... That is why the owners don't get notices, and you need to set their delivery status enabled so they will. Note that this only affects notices. It doesn't affect list posts assuming they are list members. That is controlled by the member's delivery status

And because there are no eligible owner or moderator recipients the notices go to the configured site_owner.

[1] The disabled by moderator status can occur in the following way for a list imported from Mailman 2.1. If the address in MM 2.1 is both an owner or moderator and also a list member, and the list member's delivery was disabled in MM 2.1, both the imported member and owner/moderator will have delivery disabled. This is really a bug in import21 as in Mailman 2.1, owner/moderator delivery couldn't be disabled, it shouldn't be imported as disabled. I have just created https://gitlab.com/mailman/mailman/-/issues/977 for this.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 2/9/22 16:12, Philippe B wrote:

Ah, thanks for that.

I've done owner.preferences.delivery_status = DeliveryStatus.enabled for those 2 lists.

Is there an easy way to find out all the other owners that don't have <DeliveryStatus.enabled: 1> ?

$ bin/mailman shell
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.

 >>> for mlist in getUtility(IListManager).mailing_lists:
...     for admin in mlist.administrators.members:
...         if admin.delivery_status != DeliveryStatus.enabled:
...             print(f'List: {mlist.list_name}, '
...                   f'Admin: {admin.address.email}, '
...                   f'Role: {admin.role}, '
...                   f'Status: {admin.delivery_status}')

And optionally,
...             admin.preferences.delivery_status = DeliveryStatus.enabled
...             print('Enabled.')
...
(output here)
 >>> commit()
 >>>

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan