On 9/17/25 10:08, Lindsay Haisley wrote:
On Wed, 2025-09-17 at 10:57 -0500, Lindsay Haisley wrote:
On Wed, 2025-09-17 at 05:54 -0700, Mark Sapiro wrote:

The entry is just the list name, not the full list address.

Mailman barfs on this, and refuses to accept just the list name,
complaining with "Error: Bad email address for option
regular_include_lists: plist". The full instructions for the setting
specify that this should be the full email address of the linked
list.


Sorry, my bad. The entry is the list posting address, not the bare list name.

Is it possible, because this setting MUST be an email address, that the
umbrella list (ulist) must be listed as an unmoderated subscriber to
plist?, Or v.v.?

No, the regular_include_lists feature is an alternative to umbrella lists. It doesn't require any settings other than the list address in regular_include_lists with one exception. If a regular_include_list is in a different domain from the including list you must have

ALLOW_CROSS_DOMAIN_SIBLING = True

in mm_cfg.py. This does not eliminate the requirement that all the lists must be in the same Mailman instance, but it applies if the instance supports multiple domains and the regular_include_list is in a different domain from the including list.


Is it possible that that the code for ulist sends out a "list-request
email to plist, subject of "who pwd", and parses the subscriber list
from the (rather chatty) reply? From a security standpoint, something
this would definitely make sense, since there MUST be some way for the
mailman code supporting plist knows that ulist is authorized to do the
jiggery pokery necessary to obtain the subscriber list from plist.


It doesn't work that way at all. The code instantiates the regular_include_list and gets it's regular members which is why it has to be in the same Mailman instance.


https://wiki.list.org/DOC/What%20is%20an%20Umbrella%20list%20-%20and%20why%20doesn%27t%20it%20do%20what%20I%20want%3Fhttps://wiki.list.org/DOC/What%20is%20an%20Umbrella%20list%20-%20and%20why%20doesn%27t%20it%20do%20what%20I%20want%3F

is instructive, but I may need to update to MM 2.1.10. My current 2.1.8
has some serious patches which I wrote which may not apply to 2.1.10.


Your OP said "I'm running Mailman 2.1.18-1". Which is it? If it's really 2.1.8, sibling lists aren't supported at all, but then there would be nothing in the GUI about them and the fact that there is and a bare list name throws the error says it is.

Also, 2.1.18-1 seems to be a third party package designation. Maybe there's an issue there.

The process that does this is the do_include() function in Mailman/Handlers/CalcRecips.py. Does yours have that?

Also note that digest members of the included list are not included, only regular members.

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

------------------------------------------------------
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/
Member address: arch...@jab.org

Reply via email to