On 7/28/20 6:35 AM, Pawel Grzywaczewski wrote:

Hello,

I have few questions regarding usage of Mailman3:

1. We have list1 and list2 with members. Can we specify that all members of list1 can post messages to list2?

This is a Mailman 2.1 feature that does not currently exist in Mailman 3.

2. In explanation of “Accept these non-members” it’s written: “While non-regexp addresses can be entered here, it is preferred to add the address as a nonmember and set the nonmember's Moderation to Default Processing”.

I noticed that if someone posts to a list then he is added automatically to non-members. Which means that next time he will be able to post. My understanding is that it’s better to use the feature “Accept these non-members”. Am I correct?

You are mistaken. When a non-member attempts to post to a list she is automatically added to non-members with a moderation action of list default, which means that this and subsequent posts will be handled according to the list's "Default action to take when a non-member posts to the list"

If you want to accept a non-member's posts you need to set that non-member's moderation action to "Default Processing" to still apply other tests that might hold the message or to "Accept" if you want to accept anything from that non-member.

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

I'm not Mark, but .... :-) "Plans", you ask? Hmm....

Pawel Grzywaczewski writes:

Any plans to implement message acceptance based on another list?

I think that most Mailman 2.1 features are plausible proposals for Mailman 3. While we don't make decisions based on user voting, we do care about user requests. If you want to make a formal request, post a request for enhancement (ie, issue) on our GitLab issue tracker, and post a link here so other interested people can follow it.

What about adding list1 as member to list2? In Mailman 2.1 there was an 'umbrella' feature I think it doesn't exist in Mailman3. Any plans to add it?

Same as above. I don't know Mark's plans, but he's been active on these lists. I myself hope to have some time for development later in the summer, but I've been away from the code for quite a while, and have at least two prior projects I've expressed interest in. I have no idea about Abhilash or Terri's time, except that they're always busy, and there are a couple of other developers who might drift back in at some point if something exciting starts happening.

However, these kinds of additions described above are somewhat more complicated in Mailman 3 than they were in Mailman 2. We have added the ability to identify groups of lists as domains (and therefore have multiple lists by the same name if they are each in a different domain), and the ability to identify groups of email addresses as users. This means that there are more opportunities for unfortunate things to happen.

For example, a user might have a particular address for posting to a particular list, and be unhappy if they were accidentally "unmasked" when they posted by a different address, and that post was accepted because those addresses are both owned by the same user. Whether you think this one is a "real problem" or not, we need to do more than a little thinking about such things as we improve Mailman.

We missed the window for GSoC this year. We've had excellent success in getting students (I don't think we were ever denied a slot we asked for), so prospects for next year are good. I myself am looking at mandatory retirement in a couple of years, and am planning to ramp up development/consulting activity over this period. So I know a year is a long time, but we are actively supporting existing features, and intend to continue development for the foreseeable future.

Finally, Brian Carpenter and EMWD are actively developing alternatives to Postorius and HyperKitty. (Affinity and Empathy, respectively; I believe Affinity is already in beta, Empathy I don't know about status). You can find out more about them in the Mailman Developers mailman-developers@python.org archives and in the archives of this list. These are independent friendly projects, not hostile forks. You may find them to provide more straightforward access to configurations you want, although they do depend on Mailman core for much "back office" functionality, and obviously they're less mature than Postorius and HyperKitty. But they have the advantage of targeting a much more mature Mailman core, so they'll catch up fast. EMWD hosts a lot of Mailman lists and hosts, so I for one would consider a request for features from Affinity developers to be representative of many list owners.[1]

Footnotes: [1] Not to deprecate Empathy, but the relationship between core and any archiver is pretty much "arm's length". Archiver features are mostly independent of the core.

Stephen J. Turnbull wrote:

...

Any plans to implement message acceptance based on another list? I think that most Mailman 2.1 features are plausible proposals for Mailman 3. While we don't make decisions based on user voting, we do care about user requests. If you want to make a formal request, post a request for enhancement (ie, issue) on our GitLab issue tracker, and post a link here so other interested people can follow it.

I am also quite interested in sibling lists feature for mailman 3 (regular_include_lists in mailman 2).

Pawel, did you ever posted a request for enhancement in gitlab, as Stephen suggested?

Thanks a lot for your answer!