On 2/12/22 08:19, Lucio Chiappetti wrote:
Dear Mark, thanks for your interest.
On Fri, 11 Feb 2022, Mark Sapiro wrote:
This may actually be a bug. I'll have to think about that. I've filed https://gitlab.com/mailman/mailman/-/issues/978 on this.
This is https://gitlab.com/mailman/mailman/-/issues/794 (still open)
Given the time needed to solve the issues (I will anyhow notify the site administrators, hopting they would update mailman when/if resolved), this means we have to find a workaround.
https://gitlab.com/mailman/mailman/-/issues/978 has been fixed. You can apply the fix to mailman/rules/moderation.py from https://gitlab.com/mailman/mailman/-/merge_requests/961/diffs
not sure what you mean by "defer". The non-member options I see are called
List default -- follow the list's default member action. Hold -- This holds the message for approval by the list moderators. Reject -- this automatically rejects the message by sending a bounce notice to the post's author. The text of the bounce notice can be configured by you. Discard -- this simply discards the message, with no notice sent to the post's author. Accept -- accepts any postings without any further checks. Default Processing -- run additional checks and accept the message.
defer is what's called Default Processing in the above list.
But if hold_these_nonmembers takes priority this will be uselesws in the current setting.
True, but if you apply the fix for https://gitlab.com/mailman/mailman/-/issues/978, hold_these_nonmembers won't take priority.
I go to the non-member list, select non-member options and at the bottom see an item Administration options Moderation. The possible values are those I pasted above.
The actual value for most of the imported non-members is "Default processing" while it is "List default" for thoase automatically added afresh, It is "Discard" for a number of imported non-members with spam-looking addresses (I guess they were in some other *_not_members part of the standard 2.1 antispam ... I can't recall me doing something on those)
That all seems exactly what it should be.
Side question: is there a way to operate IN BULK on non-members ? Like it is for members (I exported them to CSV).
No. Postorius doesn't currently support a CSV export for nonmembers as
it does for members, but you could do the equivalent 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
>>> for nonmemb in m.nonmembers.members:
... print(nonmemb.address.email)
...
I am not so concerned of these 189 (or better of the 189 minus the discard ones which should stay) ... anyhow moving them back will be uncomfortable if there is not a bulk operation tool.
I am more concerned of the new cases automatically added.
Apply the patch.
...
(*) by the way do you confirm that if one is subscribed to a list with an address (be it bulk subscription, import or new fast subscription), this person CANNOT change their settings (or address) unless one does a "sign in" to a (Postorius) account ?
That is correct. User's can add multiple addresses to their identity, change addresses and change other settings, but currently that has to be done via Postorius or another web UI that communicates with Mailman Core's REST API.
...>> Addresses still work, and accept_these_nonmembers takes precedence
over hold_these_nonmembers just as in MM 2.1.
This was not my impression when I ran a thorough test of 12 cases. Except the obvious case of the subscriber posting from the subscription address, all messages went on hold.
If a nonmember address is in accept_these_nonmembers, a post from that address should be accepted regardless of hold_these_nonmembers.
Whatever the non-member moderation would be (even if set to reject ! ... but that makes sense if *_these_nonmembers prevail on non-member options), and even if the address was set explicitly in accept_these_nonmembers (should I delete it from the non-member list ?)
You can leave it as a nonmember.
What is the actual order (or flow chart) of choices ?
Without the fix for https://gitlab.com/mailman/mailman/-/issues/978 the order is
- Is the sender a member? If so, apply the member's moderation action or list default.
- The sender is a nonmember, if the address matches one of (accept|hold|reject|discard)_these_nonmembers (checked in that order), apply that action.
- If no match above, apply the nonmember's moderation action - will be
List Defaultfor new nonmembers.
With the fix for https://gitlab.com/mailman/mailman/-/issues/978 the order is
- Is the sender a member? If so, apply the member's moderation action or list default.
- The sender is a nonmember, if the nonmember's moderation action is other than List Default, apply that action.
- If not, if the address matches one of (accept|hold|reject|discard)_these_nonmembers (checked in that order), apply that action.
- If none of the above, apply the list's default nonmember action.
*_these_nonmembers in the order listed in the page (within each in the order of occurrence of regexp's) then non-member options ?
That's the way it works without the fix except the order of regexps/addresses in a *_these_nonmembers list is immaterial. if the address matches any one of them, that action applies.
If I have Name.Surname@inaf.it in accept_these_nonmembers, then hold_these_nonmembers set to
^.+@.+\.it ^.+@.+\.tng\.iac\.es
what do you foresee ?
Assuming Name.Surname@inaf.it is not a member, a post from Name.Surname@inaf.it will not be held for nonmember moderation.
And for different regexps, will processing terminate at the first non-matching one, will they be ANDed or ORed, or what ?
They will all be checked until one matches or none do., I.e., effectively ORed.
I am reluctant to accept inconditionally ^.+\..+@inaf\.it (they may be falsified, only the check on their presence in the other list (issue 794)
I guess I should remove the ^.+@.+\.it regexp AND AT THE SAME TIME change the Default action to take when a non-member posts to the list to Hold instead of Discard.
This way we'll have to check spam (instead of having it auto-discarded), but if people with alternate addresses post, once they are entered in the Non-member list they can be authorized to pass for the future ...
.. would it work ?
I think that would work, but if you just apply the patch from https://gitlab.com/mailman/mailman/-/merge_requests/961/diffs, it will work the way it did in MM 2.1 honoring a nonmember's explicit moderation action before checking *_these_nonmembers.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan