Search results for "sapiro" - lists.mailman3.org

[MM3-users] Re: Handling of Mail from non-subscribers

by Peter Adebahr

On 5/9/20 2:13 AM, Mark Sapiro wrote: > On 5/8/20 5:08 PM, Peter Adebahr via Mailman-users wrote: >> On 5/9/20 1:55 AM, Mark Sapiro wrote: >> >>>> "Hold for moderation" has been set. >>> >>> Set in "Default action to take when a non-member posts to the list"? >> >> yep >> >> >>> >>> If that is the case, find the non-member in Users -> Non-Members and >> >> it does'nt show up there, "list has no nonmembers" > > > Look is var/logs/mailman.log for an error message with a SHUNTING > notation and a Traceback. Shunting seems to be ok: May 09 01:22:38 2020 (1235) SHUNTING: 1588980158.3151...... But immediately before I find the "module 'time' has no attribute 'clock'" which I remember from a thread a couple of days ago, though I cannot remember a solution when mm3 has not been installed from source but via apt-get. My core is V 3.2.2, core python 3.8.2, by the way. > > Also look in var/queue/shunt. You can examine messages you find there > with `mailman qfile`. > ah, learnt how to use that now: ... X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation ... <----- start object 2 -----> { '_parsemsg': False, 'dmarc': True, 'envsender': 'noreply(a)xyzzy-listen.de', 'lang': 'de', 'listid': 'xyzzy-listen.de', 'member_moderation_action': 'hold', 'moderation_reasons': ['The message is not from a list member'], 'moderation_sender': 'peter(a)xyzzy.de', 'original_size': 7640, 'received_time': datetime.datetime(2020, 5, 8, 23, 22, 37, 976364), 'rule_hits': ['nonmember-moderation'], 'rule_misses': [ 'dmarc-mitigation', 'no-senders', 'approved', 'emergency', 'loop', 'banned-address', 'member-moderation'], 'to_list': True, 'version': 3, 'whichq': 'in'} [----- end pickle -----] Does that help?

5 years, 5 months

[MM3-users] Re: Mailman Core 3.3.2 is now out

by Abhilash Raj

On Wed, Nov 25, 2020, at 1:58 AM, Mark Sapiro wrote: > On 11/22/20 1:04 AM, Torge Riedel wrote: > > Am 07.11.20 um 04:24 schrieb Abhilash Raj: > >> I missed it in the original email, but a full list of changes in this > >> version is present here: > >> > >> > >> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.… > >> > > > > Hi, > > > > this link now points to 3.3.3, is there a chance to make this link more > > stable? Maybe > > > > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.… > > > Those links are created by Sphinx and as you note the fragments are not > stable. I don't know if it's possible to tell Sphinx via the .rst source > how to name the fragments. Maybe the best idea is to not use fragments > at all and just point to the document. I think I should keep in mind next time to use the #<heading-name> like `#3.3.2` pointed out by Torge, instead of `#id` (which is what I see when I hover over the Link in browser so I copied ;). You can specify explicit anchor name in .rst too, I think just adding a `.. _news-3.3.2` just above the heading will generate an anchor on the page with #news-3.3.2 (I haven't verified this but I think it will!) which links to the heading. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- thanks, Abhilash Raj (maxking)

4 years, 11 months

[MM3-users] Re: how to delete a list member using the Linux command line

by Mike Wertheim

Thanks! I'm on Debian 10, and the latest Mailman version that's available in the Debian package manager is 3.2.1. I really have no idea how packages get updated in the package manager. Do you know why Mailman 3.3.1 is not yet available in Debian's package manager? (Does someone on the Mailman project need to push it there? Or does someone on the Debian side need to pull it in?) On Fri, Jun 19, 2020 at 1:24 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 6/19/20 7:29 AM, Mike Wertheim wrote: > > I have Mailman 3.2.1 installed (on Debian Linux), using exim4 as the MTA. > > > > I have been trying to figure out how to use the Linux command line to add > > members to a list and delete members from a list, but am having trouble > > with deleting. > > The --delete option to `mailman members` was introduced in Mailman > 3.3.0. Your version doesn't have it. > > Note that as of the next (3.3.2) release, the --add, --delete and --sync > options to `mailman members` are deprecated in favor of new `mailman > addmembers`, mailman delmembers` and `mailman syncmembers` commands. > > It should be possible for you to install the current versions of all of > these without upgrading just by copying the `cli_*members.py` files from > <https://gitlab.com/mailman/mailman/-/tree/master/src/mailman/commands> > to the `mailman/commands/` directory in your current installation. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >

5 years, 4 months

[MM3-users] Re: After server upgrade debian 11→12 and reinstalling everything in (venv), I got this error when accessing → mailman3/lists

by Stephen J. Turnbull

Mark Sapiro writes: > On 9/22/25 05:21, Wikinaut wrote: > > Mark, this is great news, a little bit like expected! > > Thanks again for clarifying the term "generic" here. It's helpful > > to have it for definition of both, "regular" and "digest". > > > > Is this documented somewhere? > > I don't think so. I thought I had seen it "somewhere", but I can't find it now. It should be here: https://docs.mailman3.org/projects/mailman/en/release-3.1/src/mailman/rest/…. See https://gitlab.com/mailman/mailman/-/issues/1243. Besides templates.html, this should be documented briefly in the forms for changing the generic, regular, and digest templates, something as simple as adding "if empty, falls back to generic:template" would do for the regular and digest specific templates, and "shadowed by regular:template and digest:template" for the generic template. Note that that is in the developer's documentation for the REST API. :-( We really need to reorganize the docs to be more discoverable for typical admins. > >I think, I need to create a wiki for mailman3. > We have a wiki at https://wiki.list.org/ for all versions of > Mailman. See the first paragraph at that page for info on obtaining > write access. But note that this is *not* appropriate for the wiki, which is more oriented to FAQs and news. Wikis are fine for formal documentation, but only if that's the ground truth. For better or worse, we chose not to do that. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

1 month, 1 week

[MM3-users] Re: Splitting hosts: mta&core vs postorius

by Mark Sapiro

On 6/24/20 2:10 PM, Ruth Ivimey-Cook wrote: > Mark, > >> You need to set hostname: in mailman.cfg to the actual external IP >> address of the Mailman host machine or to a name which resolves to that >> IP both internally and externally, and also set that host name/IP in the >> MAILMAN_REST_API_URL setting on the Postorius machine. > > I've done that, but there is no observed change in the browser (still > get same 404 error). > > Specifically, I reset hostname to be a newly-added CNAME of the actual > host address, and ensured that the 0.0.0.0 addresses were no longer there. OK, So setting hostname: to this CNAME which resolves to the external IP on the Mailman core host allows the REST interface to listen on that external interface and solves that issue without patching the rest runner. Correct? > A tcpdump now shows the GET of > > /3.1/domains/mailman-web.ivimey.org/lists&advertised=true&count=0&page=1 > > directed at mailman-core and the reply being 404 not found. > > The extract from core's mailman.log is now: > > [24/Jun/2020:20:41:11 +0000] "GET > /3.1/domains/mailman-web.ivimey.org/lists?advertised=true&count=0&page=1 > HTTP/1.1" 404 26 "-" "GNU Mailman REST client v3.3.1" > > And the entry for postorius in mailmansuite.log: > > ERROR 2020-06-24 21:41:11,191 13310 postorius Un-handled exception: > HTTP Error 404: {"title": "404 Not Found"} > Traceback (most recent call last): > File > "/opt/mailman3/lib/python3.6/site-packages/django/core/handlers/base.py", line > 113, in _get_response > response = wrapped_callback(request, *callback_args, > **callback_kwargs) > [snip] > File > "/opt/mailman3/lib/python3.6/site-packages/mailmanclient/restbase/page.py", > line 37, in __init__ > self._create_page() > File > "/opt/mailman3/lib/python3.6/site-packages/mailmanclient/restbase/page.py", > line 62, in _create_page > response, content = self._connection.call(self._build_url()) > File > "/opt/mailman3/lib/python3.6/site-packages/mailmanclient/restbase/connection.py", > line 116, in call > error_msg, response, None) > urllib.error.HTTPError: HTTP Error 404: {"title": "404 Not Found"} > > Note that the mailman-web.ivimey.org address is the newly-added CNAME of > greyarea-web1, mailman-core is likewise the CNAME of greyarea-post. > > There is nothing I can see in the other logs that looks out of the > ordinary. > > I guess this indicates that my earlier wondering if I had something left > over from a past install is dispelled, as that name didn't exist until > today. OK, but you still haven't reported whether you looked at the domains in Django. These are in the Django database on the Postorius server, and I don't know what's there, but if there is a domain there which is not known to core, that could cause this 404. Further if that domain is not fully qualified, something could just be appending the hostname: to it causing that name to be the one requested. Some of this is guesswork and possibly overreaching on my part, but I would like to be assured that there are no extraneous domains in Django's database. I wrote in the post at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > Go to your Django admin web UI and look at your Django Mailman 3 Mail > domains. This will be at a URL like > https://greyarea-web1.cam.ivimey.org/admin/django_mailman3/maildomain/ Have you done that? I want to help resolve this issue, but right now I want to rule out the possibility that there are domains known to Django that aren't known to core. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 4 months

[MM3-users] Re: API access to Hyperkitty

by Abhilash Raj

On Tue, Feb 9, 2021, at 10:44 AM, Mark Sapiro wrote: > On 2/9/21 10:23 AM, Brian Carpenter wrote: > > Is it possible to download Hyperkitty's archives to a remote server via > > an API? Is there documentation that explains how to accomplish this task? > > > > > I don't think there is documentation, but if you look at the target of > any `download` button, it should be obvious. I.e. the link to download > the entire archive for this list is > > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/export/… > > The `mailman-users(a)mailman3.org-2021-02.mbox.gz` part is the name of the > file to download to and the `-2021-02` part can be anything or nothing, > but the name must begin with the list posting address and end with > `.mbox.gz`. > > If the archive is large, this can time out in which case adjust `start` > and `end` to download it in pieces. Hyperkitty also has a traditional REST API, which can be used to ingest archives on a different server that doesn’t necessarily want to deal with mboxes. The documentation comes with Hyperkitty and is typically available at “/api” in Hyperkitty. So something like this on our server: https://lists.mailman3.org/archives/api/ There is also a “HTML” version where you can actually browse through the API like a webpage. It returns Json/XML/txt when you ask for it. The above page should have the details. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- thanks, Abhilash Raj (maxking)

4 years, 8 months

[MM3-users] Re: Set member.moderation_action via REST API as part of message approval?

by Mark Sapiro

On 3/3/25 14:27, Andy Matthews wrote: > We're using Mailman 3.3.9. > > Entity<Form> data = Entity.entity(form, MediaType.APPLICATION_FORM_URLENCODED_TYPE); > response = getTarget().path("lists/" + listId + "/config").request().method("PATCH", data); You are patching the list's config and with that patch you are replacing the old value of `accept_these_nonmembers` with the new, not appending the new value. You would need to retrieve the existing value, update it and PATCH that. However, as you know, that setting is deprecated and exists only to support the regexp and @list type of entries. For explicit email addresses, the intent is to create a nonmember and set the nonmember's moderation_action to `defer` - you normally don't want `accept` because that bypasses all the subsequent checks such as administrivia, implicit-dest, max_recipients, max_size, , no_subject, etc. > The result of these two API calls is that both the subscribers and nonmembers properties of the mailing list are updated to include the new email (let's call it abc(a)123.com) The user can immediately send another email which is not held for moderation. The issue comes when a different nonmember sends an email and is approved (let's call it xyz(a)789.com) For some reason this blows out the "always accept" status of user abc(a)123.com and requires their email to be approved again. > > After some research I believe this is because the `accept_these_nonmembers` property has been deprecated (which seems valid because that property remains an empty array). Additional reading seems to indicate that we can now set `moderation_action` on each individual user which supercedes the mailing list's `default_nonmember_action` property (in our case it is `Action.hold`). That is correct, and that is the intended way to deal with nonmember moderation. > The docs indicate that I should be able to submit a patch request to update the moderation action for any user: > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… > > But it requires the user ID. And when trying to get the user_id for a nonmember it appears that it is not returned by the API. The following call: > `/3.0/addresses/abc(a)123.com` > > returns > ``` > { > "email": "abc(a)123.com", > "original_email": "abc(a)123.com", > "registered_on": "2025-03-03T19:18:35.169703", > "self_link": "https://0.0.0.0:8001/3.0/addresses/abc@123.com", > "http_etag": "\"92c44d0b3b323450f3576e6352acb59b4cc5d6f0a\"" > } > ``` > So I'm not sure how I would be able to update this particular record without a member or user id. > > So, all that said, I'm looking for information on how to do one of the following. > > 1. When submitting a user's email to the `accept_these_nonmembers`, is there a way to indicate that the `member.moderation_action` should be a specific value? No. You can put the email in the appropriate *_these_nonmembers, but that does only that. It doesn't affect the nonmember's moderation_action, nor does it create a nonmember if there isn't one already, but if there is a nonmember with non-None moderation_action, that action takes precedence over *_these_nonmembers. > 2. Retrieve a nonmember record and have it include a member or user id that I can use to explicitly update the `member.moderation_action` value? You must be able to set a nonmember's moderation_action via REST. (The docs may need updating.) Postorius does it, so it can be done, but I don't offhand know the endpoint and I'm leaving the country for vacation tomorrow and don't have time to research it. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 months, 4 weeks

[MM3-users] Re: User settings triggers error

by Mark Sapiro

On 6/16/20 12:18 PM, Mark Dadgar wrote: > On Jun 16, 2020, at 11:47 AM, Mark Sapiro <mark(a)msapiro.net> wrote: >>> File "/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py" in call >>> 99. raise HTTPError(url, response.status, content, response, None) >> >> And gets a 500 from core. >> >> >>> During handling of the above exception (HTTP Error 500: b'A server error occurred. Please contact the administrator.'), another exception occurred: >> >> >> Which we aren't interested in. >> >> The next step is to look in core's mailman.log to see what the rest call >> was and the exception and hopefully traceback the caused the 500 response. > > > Here’s what’s logged during that error: > > Jun 16 12:16:54 2020 (1326) 127.0.0.1 - - "GET /3.1/users/mark(a)pdc-racing.net HTTP/1.1" 200 432 > Jun 16 12:16:54 2020 (1326) REST request handler error: > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context > self.dialect.do_execute( > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute > cursor.execute(statement, parameters) > psycopg2.errors.UndefinedFunction: operator does not exist: text = uuid > LINE 4: WHERE "user"._user_id = '05dcbeb4-b784-45eb-96f8-6f9e4b7ab6c... > ^ > HINT: No operator matches the given name and argument types. You might need to add explicit type casts. > > > The above exception was the direct cause of the following exception: > > Traceback (most recent call last): > File "/usr/lib/python3.8/wsgiref/handlers.py", line 137, in run > self.result = application(self.environ, self.start_response) > File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", line 50, in wrapper > rtn = function(*args, **kws) > File "/usr/lib/python3/dist-packages/mailman/rest/wsgiapp.py", line 218, in __call__ > return super().__call__(environ, start_response) > File "falcon/api.py", line 232, in falcon.api.API.__call__ > File "falcon/api.py", line 229, in falcon.api.API.__call__ > File "falcon/api.py", line 582, in falcon.api.API._get_responder > File "/usr/lib/python3/dist-packages/mailman/rest/wsgiapp.py", line 131, in find > attribute = getattr(resource, name, MISSING) > File "/usr/lib/python3/dist-packages/mailman/rest/users.py", line 203, in _user > return user_manager.get_user_by_id(user_id) > File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", line 85, in wrapper > return function(args[0], config.db.store, *args[1:], **kws) > File "/usr/lib/python3/dist-packages/mailman/model/usermanager.py", line 94, in get_user_by_id > if users.count() == 0: > File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3630, in count > return self.from_self(col).scalar() > File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3355, in scalar > ret = self.one() > File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3325, in one > ret = self.one_or_none() > File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3294, in one_or_none > ret = list(self) > File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3367, in __iter__ > return self._execute_and_instances(context) > File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3392, in _execute_and_instances > result = conn.execute(querycontext.statement, self._params) > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 982, in execute > return meth(self, multiparams, params) > File "/usr/lib/python3/dist-packages/sqlalchemy/sql/elements.py", line 287, in _execute_on_connection > return connection._execute_clauseelement(self, multiparams, params) > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1095, in _execute_clauseelement > ret = self._execute_context( > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1249, in _execute_context > self._handle_dbapi_exception( > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1476, in _handle_dbapi_exception > util.raise_from_cause(sqlalchemy_exception, exc_info) > File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 398, in raise_from_cause > reraise(type(exception), exception, tb=exc_tb, cause=cause) > File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 152, in reraise > raise value.with_traceback(tb) > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context > self.dialect.do_execute( > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute > cursor.execute(statement, parameters) > sqlalchemy.exc.ProgrammingError: (psycopg2.errors.UndefinedFunction) operator does not exist: text = uuid > LINE 4: WHERE "user"._user_id = '05dcbeb4-b784-45eb-96f8-6f9e4b7ab6c... > ^ > HINT: No operator matches the given name and argument types. You might need to add explicit type casts. > > [SQL: SELECT count(*) AS count_1 > FROM (SELECT "user".password AS user_password, "user".id AS user_id, "user".display_name AS user_display_name, "user"._user_id AS user__user_id, "user"._created_on AS user__created_on, "user".is_server_owner AS user_is_server_owner, "user"._preferred_address_id AS user__preferred_address_id, "user".preferences_id AS user_preferences_id > FROM "user" > WHERE "user"._user_id = %(user_id_1)s) AS anon_1] > [parameters: {'user_id_1': UUID('05dcbeb4-b784-45eb-96f8-6f9e4b7ab6cb')}] > (Background on this error at: http://sqlalche.me/e/f405) > Jun 16 12:16:54 2020 (1326) 127.0.0.1 - - "GET /3.1/users/05dcbeb4b78445eb96f86f9e4b7ab6cb/addresses HTTP/1.1" 500 59 > Jun 16 12:16:54 2020 (1326) REST request handler error: > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context > self.dialect.do_execute( > File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute > cursor.execute(statement, parameters) > psycopg2.errors.UndefinedFunction: operator does not exist: text = uuid > LINE 4: WHERE "user"._user_id = '05dcbeb4-b784-45eb-96f8-6f9e4b7ab6c... > ^ > HINT: No operator matches the given name and argument types. You might need to add explicit type casts. This looks like another manifestation of the issue reported at https://gitlab.com/mailman/django-mailman3/-/issues/35 and https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… If you are running django-mailman3 1.3.3 and haven't upgraded to django-mailman3 1.3.4, see the above list post for a workaround. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 4 months

[MM3-users] Re: How to identify the exact reason behind the shunting of the mails ?

by Shashikanth Komandoor

Thank you Mark, Then I will try to upgrade the version Thank you once again. On Fri, Jun 18, 2021 at 8:01 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 6/18/21 6:48 AM, Shashikanth Komandoor wrote: > > Dear Mark, > > > > FYI, I observed this issue with the postfix that receives the > > mails from the previous MTA and hands it over to the mailman. But I fixed > > at postfix by upgrading it to the version postfix 3. > > > > But still Mailman is not able to understand Hindi (Indian > local > > language) in which language the display names of the email ids are there. > > > > So, now what to do at Mailman so that it can also understand > > local languages or any work around or other alternate solutions for these > > sort of cases. > > > As noted in my reply at > > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > the issue is a Mailman bug which is fixed in the next release. It has to > do with the fact that the display names are RFC 2047 encoded and not the > particular encoding. > > Actually, the fix at > https://gitlab.com/mailman/mailman/-/merge_requests/841 depends on > https://gitlab.com/mailman/mailman/-/merge_requests/652 which was > released in Mailman 3.3.2. A complete patch for versions < 3.3.2 is > attached. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- Thanks & Regards, Shashi Kanth.K 9052671936

4 years, 4 months

[MM3-users] Re: Avoiding non-members to be saved.

by Mark Sapiro

On 8/7/21 4:55 AM, Stephen J. Turnbull wrote: > Guillermo Hernandez (Oldno7) via Mailman-users writes: > > > Yesterday I had a problem with a private list. A spammer sent a mail > > forging one address that was a non-member (in fact was an "accept this > > no subscriber mails" from mailman 2.1 import) with very bad intentions > > and it was distributed. > > If you upgrade from Mailman 2 to Mailman 3, the accept_these_nonmembers > list for each list is grandfathered into the Mailman 3 list (from > rules/moderation.py): > > # Check the '*_these_nonmembers' properties first. XXX These are > # legacy attributes from MM2.1; their database type is 'pickle' and > # they should eventually get replaced. > for action_name in ('accept', 'hold', 'reject', 'discard'): > legacy_attribute_name = '{}_these_nonmembers'.format( > action_name) > > > There were no list of "accept this non members" in the Postorius > > config > > If there is no such list in Postorius, I would guess that some > developer thought "OK, this is a legacy feature and I'll get back to > it when we move it to the proper database" (unfortunate, but most of > us have open-subscription member-posts-only lists, and the current > workflow seems to work well, so this feature may not be so salient). Moderation in MM 3 works as follows: Is poster address a member. If so apply the member's moderation action, else Does poster address appear or match a pattern in the legacy (accept|hold|reject|discard)_these_nonmembers (first match in that order). If so, apply the appropriate action, else If the poster address is not a non-member, add it as a nonmember and apply the default nonmember moderation. > > I think it is solved now (deleting all and putting to hold just the > > non-members addresses that I would want to pass messages on) > > This should not be necessary, unless there were pre-approved addresses > that are no longer appropriate. But Mailman can't know that! The import21 process imports *_these_nonmembers by adding any regexps to the corresponding MM 3 *_these_nonmembers and adding any addresses as nonmembers with the appropriate moderation action. > > The fact is that any sender address of mails sent to the list is saved > > as a "non member", and it make me nervous as it will grow despite it is > > a legitimate message or not. This is the way MM 3 works. The only reason *_these_nonmembers exists in MM 3 is to support the legacy regexps from MM 2.1. For non-regexp addresses the address is a nonmember with the appropriate moderation action. I actually find this convenient. When a nonmember posts spam to a list and that spam is held, I discard the spam in Postorius and at the same time set the nonmember's moderation action to discard so I never see any more from that address. Also, when someone who I recognize as a list member posts from an alternate nonmember address, I can accept that post and set the nonmember address moderation action to default processing. > As far as I can see there is no other rule except that legacy rule > (and the rule that accepts all posts, which is rarely used) that will > accept a post from nonmembers. As I note above, nonmembers and members alike have a moderation action which can be any of Hold, Reject (with notice), Discard (no notice), Accept (without any further checks), Default Processing (continue with additioal checks) or the list's default action for (non)members. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 2 months

Search results for query "sapiro"