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

[MM3-users] Re: Problem creating list members using REST API

by Stephen Daniel

The REST API documentation is a bit informal. As someone who is not familiar with mailman, and who doesn't know python, they are a bit of a slog. One day it would be nice to augment the documentation with a formal and complete reference document. Something like this one <https://infosight.hpe.com/InfoSight/media/cms/active/public/pubs_REST_API_R…>. A formal reference manual needs a complete listing of every type of object, all possible operations on each object, and all required and optional parameters. Since creating a formal document like that is probably out of scope, at a minimum it would be good to specify that boolean values are passed as JSON strings, not JSON booleans. It might be worth seeing if the code can be enhanced to allow the boolean values to be sent in using JSON booleans as well as JSON strings. Thanks again for the prompt response! -- Stephen On Tue, Jan 18, 2022 at 4:25 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 1/18/22 10:53 AM, Stephen Daniel wrote: > > 2nd follow-up. Apologies for spamming this list. > > > > I went wandering through the code as suggested by the traceback. I > > discovered that thee "as_boolean" routine is expecting a string argument > > but getting a boolean argument. > > > > So, If I send the booleans as strings, with values "true" or "false", all > > is well. > > This is not what the API documentation suggests I should do. Can someone > > either fix the documentation or the code? > > > Those snippets in the documentation are doctests. That code is actually > executed by unit testing and passes. In all those snippets, dump_json is > passing the second argument as `data` to > mailman.testing.documentation.dump_json() which in turn calls > mailman.testing.documentation.call_http() which calls > mailman.testing.helpers.call_api() which ultimately calls > requests.request() with the same `data` argument. > > So basically, the issue is the difference between how requests.request() > handles that `data` dictionary in creating the POST data and whatever > you are doing. > > Possibly we could add some caveat to > < > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/docum…> > > or possibly elsewhere. Do you have a suggestion as to what? > > > -- > 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/ >

4 years, 9 months

[MM3-users] Re: digest summary heavily cluttered with hrml code

by Mohsen Masoudfar

Hi Mark, Thanks again for your help! Yes, I meant "Today's Topic". I checked the link you sent, but could not see the solution to the issue. You mentioned: " They are in order of priority, list based, address based and global" Is this in descending or ascending priority? If I set it at list level, does it overwrite the member setting (address based?? )? I set them along with "Delivery mode" at the member level and saved it, but when I get back to it, it still shows "Regular" and other fields like: acknowledge_posts, delivery_status, hide_address, receive_list_copy, receive_own_postings are empty, even though I set them and saved. Thanks Mohsen -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Wednesday, October 14, 2020 12:21 PM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: digest summary heavily cluttered with hrml code [EXTERNAL EMAIL] On 10/14/20 8:46 AM, Mohsen Masoudfar wrote: > Hi, > > I am running Mailman 3.1.1 on Ubuntu 18.04. > > The user complains that the digest summary is cluttered with HTML code. What does 'summary' mean in this context? Are you referring to the 'Today's Topics:' list or the messages themselves? Is this perhaps <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.co…>? > I thought, I may fix it by: > Members > {user} > Member options > Delivery mode set to [Plain Text Digest]. After setting the value and clicking [save changes], I tried to check the value by getting back to Members setting for the user, it shows the value as "Regular", which was the value before I tried to update it. There are actually 3 sets of user preferences. They are in order of priority, list based, address based and global. You can see these if you are logged in to the web UI as the user and go to 'Mailman settings' in the pull down at the top right. There are issues in Postorius if a user is a member of a list with more than one role - see <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.co…>. > Question 1: How may I be sure that the value is set, if it is set? Examine the settings with `mailman shell` > Question 2: How may set it for all members of the list? Create a `mailman shell` script. > Question 3: Is there a CLI way to do this? I tried "mailman members " command. But it seems not supporting this option. Again, `mailman shell`, but this is low level and requires some knowledge of Mailman internals. -- 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mai…

6 years

[MM3-users] Re: Getting rid of held messages from the command line

by Mark Sapiro

On 03/14/2018 03:04 AM, Aymeric Mansoux wrote: > > So far so good, however, for some reasons, a couple of our lists have started to accumulate held messages that cannot be manipulated via the REST API. Regardless if we use the web interface or mailmanclient, it ends up with: > > Mar 14 10:58:32 2018 (24287) REST request handler error: > Traceback (most recent call last): > File "/usr/lib/python3.5/wsgiref/handlers.py", line 137, in run > self.result = application(self.environ, self.start_response) > File "/usr/local/lib/python3.5/dist-packages/mailman/database/transaction.py", line 50, in wrapper > rtn = function(*args, **kws) > File "/usr/local/lib/python3.5/dist-packages/mailman/rest/wsgiapp.py", line 214, in __call__ > return super().__call__(environ, start_response) > File "/usr/local/lib/python3.5/dist-packages/falcon/api.py", line 244, in __call__ > responder(req, resp, **params) > File "/usr/local/lib/python3.5/dist-packages/mailman/rest/post_moderation.py", line 167, in on_get > resource = self._make_collection(request) > File "/usr/local/lib/python3.5/dist-packages/mailman/rest/helpers.py", line 159, in _make_collection > for resource in collection] > File "/usr/local/lib/python3.5/dist-packages/mailman/rest/helpers.py", line 159, in <listcomp> > for resource in collection] > File "/usr/local/lib/python3.5/dist-packages/mailman/rest/post_moderation.py", line 157, in _resource_as_dict > resource = self._make_resource(request.id) > File "/usr/local/lib/python3.5/dist-packages/mailman/rest/post_moderation.py", line 70, in _make_resource > resource = super()._make_resource(request_id) > File "/usr/local/lib/python3.5/dist-packages/mailman/rest/post_moderation.py", line 39, in _make_resource > results = requests.get_request(request_id) > File "/usr/local/lib/python3.5/dist-packages/mailman/database/transaction.py", line 85, in wrapper > return function(args[0], config.db.store, *args[1:], **kws) > File "/usr/local/lib/python3.5/dist-packages/mailman/model/requests.py", line 120, in get_request > result.data_hash, expunge=False) > File "/usr/local/lib/python3.5/dist-packages/mailman/database/transaction.py", line 85, in wrapper > return function(args[0], config.db.store, *args[1:], **kws) > File "/usr/local/lib/python3.5/dist-packages/mailman/model/pending.py", line 138, in confirm > value = json.loads(keyvalue.value) > File "/usr/lib/python3.5/json/__init__.py", line 319, in loads > return _default_decoder.decode(s) > File "/usr/lib/python3.5/json/decoder.py", line 339, in decode > obj, end = self.raw_decode(s, idx=_w(s, 0).end()) > File "/usr/lib/python3.5/json/decoder.py", line 355, in raw_decode > obj, end = self.scan_once(s, idx) > json.decoder.JSONDecodeError: Unterminated string starting at: line 1 column 1 (char 0) > Mar 14 10:58:32 2018 (24287) 127.0.0.1 - - "GET /3.1/lists/xx(a)xx.xx/held HTTP/1.1" 500 59 > > Is there a way to manipulate/see/remove these mails differently? Right now this prevent moderation of any held messages (note: some lists do not suffer from this and the held panel or mailmanclient works perfectly fine). We've seen this issue before with a different underlying cause. See <https://gitlab.com/mailman/mailman/issues/256>. There are a couple of problems here. The serious problem is if there is a held message which somehow throws an exception in processing in mailman/rest/post_moderation.py, that totally breaks the Postorius held messages view for that list. We need to fix that. Also it would be good to see the problem message. Here are some things you can do in 'mailman shell' (aka mailman withlist). It is not clear what might not work, but you can try mailman shell -l list@domain which will respond Welcome to the GNU Mailman shell The variable 'm' is the list@domain mailing list >>> Then you should be able to do at the >>> prompts: >>> req_db = IListRequests(m) >>> reqs = list(req_db.held_requests) reqs is now a list of the held requests and you can do something like >>> for req in reqs: ... print('{}: {}'.format(req.id, req.request_type)) ... or since req_db.held_requests is a generator >>> for req in rdb.held_requests: ... print('{}: {}'.format(req.id, req.request_type)) ... either of which will produce a list like 1: RequestType.held_message with the IDs and types of each request. You can handle these requests with something like >>> from mailman.app.moderator import handle_message >>> handle_message(m, 1, Action.defer) where the second argument is the ID of the message and the action is one of Action.defer, Action.hold, Action.discard, Action.reject or Action.accept, the first two of which do nothing, but the others will do the indicated action. You can see the actual messages like this >>> msg_db = getUtility(IMessageStore) then >>> key = req[0].key >>> msg_db.get_message_by_id(key) which will return the actual held message that is in this case index 0 in the list of held_requests. You may have to do >>> commit() when done, although if you don't do abort(), just exiting with control-D should do a commit(). I hope you find this helpful, and if you do determine the content of the offending message(s), it will be helpful if you post that. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 7 months

[MM3-users] Re: Receiving Email from ListName-bounce@Domain for Unsubcribe

by Marin Sok

Hi Mark, Yes, the notification email for unsubscribe from the list from test1-bounces@doamin. Agree with you that it should come from LIST-owner address. Fo example test1-owner@domain. Should I try to modify the code in file notifications.py in line 137. Screenshot. def send_goodbye_message(mlist, address, language): """Send a goodbye message to a subscriber. Prepending to the standard goodbye message template is the mailing list's goodbye message, if there is one. :param mlist: the mailing list :type mlist: IMailingList :param address: The address to respond to :type address: string :param language: the language of the response :type language: ILanguage """ goodbye_message = wrap(expand(getUtility(ITemplateLoader).get( 'list:user:notice:goodbye', mlist, language=language.code), mlist, dict( user_email=address, # For backward compatibility. user_address=address, fqdn_listname=mlist.fqdn_listname, list_name=mlist.display_name, list_requests=mlist.request_address, ))) with _.using(language.code): msg = UserNotification( address, mlist.bounces_address, _('You have been unsubscribed from the ${mlist.display_name} ' 'mailing list'), goodbye_message, language) msg.send(mlist, verp=as_boolean(config.mta.verp_personalized_deliveries)) Thanks, Marin <http:\\probonoweek.lalawlibrary.org> [http://www.lalawlibrary.org/sigimages/logo-sig.png] Marin Sok IT Director P 213.785.2556 | F 213.680.1727 http://www.lalawlibrary.org/<http://www.lalawlibrary.org/> | MSok(a)lalawlibrary.org Access to Information = Access to Justice <http://probonoweek.lalawlibrary.org/> Follow us: [http://www.lalawlibrary.org/sigimages/facebook.png] <http://facebook.com/LALAWLIBRARY> [http://www.lalawlibrary.org/sigimages/twitter.png] <http://twitter.com/LALAWLIBRARY> [cid:SocialLink_Instagram_32x32_dc37fa34-8ab4-41db-9940-9cb519436518.png] <https://www.instagram.com/lalawlibrary> ________________________________ From: Mark Sapiro <mark(a)msapiro.net> Sent: Monday, February 16, 2026 10:54 AM To: Stephen J. Turnbull <steve(a)turnbull.jp>; Marin Sok <MSok(a)lalawlibrary.org> Cc: mailman-users(a)mailman3.org <mailman-users(a)mailman3.org> Subject: Re: [MM3-users] Receiving Email from ListName-bounce@Domain for Unsubcribe [You don't often get email from mark(a)msapiro.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] On 2/16/26 10:09, Stephen J. Turnbull wrote: > > Do you mean the notification email from the list is From > test1-bounces@domain? Are you sure it is from "test1-bounces@domain"? > It should be from "test1-owner@domain". Most notifications to users > come from the "LIST-owner" address. Actually, in this case it is From: the list bounces address. See <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/app/notificati…<https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/app/notificati…>>. There are other user notices From: the list bounces as well. See <https://gitlab.com/mailman/mailman/-/issues/1260<https://gitlab.com/mailman/mailman/-/issues/1260>>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: image/png Name: SocialLink_Instagram_32x32_dc37fa34-8ab4-41db-9940-9cb519436518.png Replaced multipart/alternative part with first alternative.

8 months

[MM3-users] Re: Mailman 3, postfix domains, and postgresql cannot authenticate user

by Keith Christian

Mark, RE: The `mailman aliases` command generates the postfix_domains and postfix_lmtp files and calls the configured postmap_command (default /usr/sbin/postmap) to create the .db files. `mailman start` also generates these files by default. I ran mailman aliases and the first try got can't read main.cf. I granted read-only access to other on the file, the next mailman aliases command ran without errors, but I don't know if it did anything or not, e.g. nothing in postfix_domains or the lmtp files. How can I verify that "mailman aliases" worked? Thanks, ---------- Keith On Wed, Jul 3, 2024 at 2:52 PM Mark Sapiro <mark(a)msapiro.net> wrote: > > On 7/3/24 09:22, Keith Christian via Mailman-users wrote: > > --------------------------------------------------------------------------- > > First issue:Postfix v3.5.8 on RHEL 8. > > The below is from journalctl -xe: > > --------------------------------------------------------------------------- > > Jul 03 08:12:04 somehost.somedomain postfix/qmgr[947499]: error: open > > database /opt/mailman3/mm/var/data/postfix_domains.db: No such file or > > directory > > Jul 03 08:12:42 somehost.somedomain postfix/smtpd[947510]: error: open > > database /opt/mailman3/mm/var/data/postfix_domains.db: No such file or > > directory > > Jul 03 08:12:42 somehost.somedomain postfix/smtpd[947510]: error: open > > database /opt/mailman3/mm/var/data/postfix_lmtp.db: No such file or > > directory > > > > I manually created the var_dir: /opt/mailman3/mm/var directory > > specified in the mailman.cfg file. > > How do I find out how to populate the postfix_domains.db files, and > > the postfix_lmtp.db file? > > > The `mailman aliases` command generates the postfix_domains and > postfix_lmtp files and calls the configured postmap_command (default > /usr/sbin/postmap) to create the .db files. `mailman start` also > generates these files by default. > > > > --------------------------------------------------------------------------- > > Second issue: Postgresql authentication. > > PostgreSQL v10.23. > > --------------------------------------------------------------------------- > > I have this in the active mailman3.cfg file, where xxxxxxxxxx is the > > same complex password in the mailman3 config file: > > url: postgresql://mailman3:xxxxxxxxxx@localhost/mailman3/mailman3 > > > I don't think you should have two /mailman3 at the end > > the form is `postgresql://user:password@host:port/database_name` The > default port is 5432. > > -- > 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/ > Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to keith1christian(a)gmail.com

2 years, 3 months

[MM3-users] Re: Mailman REST API not available. Please start Mailman Core.

by Shashikanth Komandoor

Thank you Mark for your response. I understood that gunicorn is a front end that is used like web server like nginx. But I don't think I am using it instead I am using the httpd to redirect requests to postorius. And I am starting the mailman-suite with the command "python manage.py runserver 0.0.0.0:8000 --insecure &". Hope this does not use gunicorn (which of course I don't know what it is until now). Please correct me if any point I am mentioning is wrong. So, in this case, do you think configuring gunicorn as below would work: *calling gunicorn.cfg in mailman.cfg as below * *[webservice]* *configuration: /var/lib/mailman/mailman/src/mailman/config/gunicorn.cfg* *and content of gunicorn.cfg as below* *(venv3) [root@lsmgr mailman]# cat /var/lib/mailman/mailman/src/mailman/config/gunicorn.cfg[gunicorn]# All the options that can be put here are available at# http://docs.gunicorn.org/en/stable/settings.html#settings <http://docs.gunicorn.org/en/stable/settings.html#settings># No of seconds to wait before killing the worker processes.* *workers = 4graceful_timeout = 90* Also what is the difference between timeout and graceful_timeout ? Please help me if I can increase the management better. Any guide is also helpful for me. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Thu, Jul 23, 2020 at 4:10 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 7/22/20 9:21 AM, Shashikanth Komandoor wrote: > > Hi Mark, > > > > Never mind please I am sending to you only instead of group as I am > > sending you the production content along with the mail. > > > See my other reply. > > > > I have configured the workers count as 4 and timeout as 900 in > > mailman.cfg under [webservice]. This is FYI. > > You can't configure Mailman's REST gunicorn workers directly in the > [webservice] section of mailman.cfg. The only thing you can configure > there is: > > configuration: /path/to/gunicorn.cfg > > That file, which is separate from your web server gunicorn.cfg, is where > you put things like > > [gunicorn] > timeout = 900 > > It also will not work to put a gunicorn section in mailman.cfg. It must > be in a separate file pointed to by webservice.configuration. > > Increasing the number of workers won't help this issue. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > -- Thanks & Regards, Shashi Kanth.K 9052671936

6 years, 2 months

[MM3-users] Re: Mailman 3 Privacy Policies, GDPR, etc and social logins

by Jered Floyd

This was what I was using as well, but it failed to meet their requirements for some ineffable reason. I had a few back-and-forths with someone for whom English was not their first language, and got them to accept a slightly modified version that I posted at https://www.convivian.com/mailman-privacy.html Now, the latest is that I have a new message noting that apps requesting user data (e.g. email address) must be linked to Business Profiles (text below). Django-allauth is cool, but I think it's not going to be long for this world and we'll just have to do internal auth. Disappointing from a workflow perspective, but I'm happy to dissuade subscribers to not use Facebook. Regards, --Jered P.S. The fresh hell from Facebook: You are receiving this message because Mailman List Manager is not connected to a verified Meta Business Account. On Feb 1, 2023 Meta began requiring business verification for apps that request access to data from users (for some apps this is called advanced access). Learn more about this requirement. [https://developers.facebook.com/blog/post/2023/02/01/developer-platform-req…] Here’s what a person with full control of your Business Account needs to do by Feb 2, 2024 to maintain access: Connect the app to a Business Account, if you haven't already. Complete business verification for the Business Account. Business Accounts connect your Facebook Pages, Instagram accounts and the people who work on them, so you can manage them all in one place. ----- On Sep 19, 2023, at 5:00 PM, Mark Sapiro mark(a)msapiro.net wrote: > On 9/19/23 6:22 AM, Jered Floyd wrote: >> >> This is a bit of a headache. Do we have a draft of a community Privacy Policy >> for a vanilla Mailman 3 install that meets Facebook's requirements? Is this >> going to be a constantly unraveling thread of future GDPR and Right to Be >> Forgotten troubles, since there doesn't seem to be an easy way to scrub a >> subscriber from Hyperkitty archives if they request so? How have others >> addressed this situation? > > > I use https://www.list.org/privacy.html which appears to satisfy Facebook. > > -- > 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/ > Archived at: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to jered(a)convivian.com

3 years

[MM3-users] Re: Missing Base64 encoding from control message reply

by Jana Berger

On 24.09.2023 16:52, Mark Sapiro wrote: > On 9/24/23 07:20, Stephen J. Turnbull wrote: >> >> The only thing I can think of at the moment that might move the >> discussion forward is if Mark knows how to run his test in your Docker >> environment to see if it also produces >> Content-Type: text/plain; charset="US-ASCII" >> Content-Transfer-Encoding: 7bit > > Assuming there is not something like > ``` > [language.en] > charset: utf-8 > ``` > in your mailman.cfg overriding the default us-ascii charset for > English, if you send a message From: yourself to > list-confirm-xxxxxxx(a)example.com with Subject: Re: Your confirmation > is needed to join the list(a)example.com mailing list (replacing list > and example.com with the actual list and domain), you should receive a > response like (some headers removed) > ``` > Subject: The results of your email commands > From: list-bounces(a)example.com > To: mark(a)example.com > MIME-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > Message-ID: <169556563227.2592.7908020161516725770(a)example.com> > Date: Sun, 24 Sep 2023 07:27:12 -0700 > Precedence: bulk > X-Mailman-Version: 3.3.9b1 > List-Id: A test list <list.example.com> > List-Help: <mailto:list-request@example.com?subject=help> > List-Owner: <mailto:list-owner@example.com> > List-Subscribe: <mailto:list-join@example.com> > List-Unsubscribe: <mailto:list-leave@example.com> > > The results of your email command are provided below. > > - Original message details: > From: Mark Sapiro <mark(a)example.com> > Subject: Re: Your confirmation is needed to join the > list.example.com mailing list. > Date: Sun, 24 Sep 2023 07:27:10 -0700 > Message-ID: <20230924142710.GA23819(a)example.com> > > - Results: > Confirmation token did not match > > - Done. > > ``` > What do you get? > Well, that confirms it. I send the mail from an account at GMX and received the Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 with a properly (!) base64-encoded message body. I then send the mail both from my own mail system (which is also the one being used by Mailman) and got Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" with no encoding on the message. Lastly, I send the same mail from a GoogleMail account, which also received Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" with no encoding. ... which means this is almost surely a bug in the MTA of GMX, which will be much, much more difficult and unlikely to be fixed - that is why I had hoped for this to be an issue in/with Mailman ;) Thank you for the pointers and help!

3 years

[MM3-users] Re: converting bulk accept_these_nonmembers in migration from mailman 2 to 3

by Mark Sapiro

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 Default` for 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(a)inaf.it in accept_these_nonmembers, then > hold_these_nonmembers set to > > ^.+@.+\.it > ^.+@.+\.tng\.iac\.es > > what do you foresee ? Assuming Name.Surname(a)inaf.it is not a member, a post from Name.Surname(a)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 ^.+\..+(a)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(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 8 months

[MM3-users] Re: The message is larger than the 40 KB maximum size

by Mohsen Masoudfar

Hi Mark, Thank you Mark and Phil for your help. It seems I got stuck! 1- I tried to set up the max_message_size in WUI under: listname > settings > Message Acceptance > Maximum message size to 0. After hitting save button, I got the error message: " An error occured: Unknown attribute: max_message_size" 2- I checked the python files and found this file, where, it seems, the default value is defined: /usr/lib/python3/dist-packages/mailman/styles/base.py : mlist.max_message_size = 40 I changed this value to 0, saved the file, restarted the mailman and postgresql (not sure if needed) and sent an email with a large attachment to my test list with just two members. I got the response email: The message is being held because: The message is larger than the 40 KB maximum size 3- I totally agree that the most important issue is the fact that the message vanished with the production list. I repeated the same with a (test) list which has two members, I got the email mentioning the 40 KB limit and I could release it. This is how I am running my tests now. I repeated it with the original list (with 197 members) the message disappeared again. I can send an email to the list with 197 members, without this attachment and it works. 4- I checked the folders, under /var/lib/mailman3/queue/, all folders are empty: archive/ bad/ bounces/ command/ digest/ in/ nntp/ out/ pipeline/ retry/ shunt/ virgin/ Thanks Mohsen -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Friday, September 18, 2020 4:00 PM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: The message is larger than the 40 KB maximum size [EXTERNAL EMAIL] On 9/18/20 12:48 PM, Phil Stracchino wrote: > On 2020-09-18 15:32, Mohsen Masoudfar wrote: >> Hi, >> >> I am trying to find how I may change this. I have an attachment of 800 KB, and when I post it to the list, I do not get any response and nothing is hold. It looks like the message is just dropped. > > > Assuming that this works roughly the same in mm3 as it does in mm2, > you can set max_message_size in your list configuration. It defaults > to 40; units are KB. Yes, and you can set it to zero for "unlimited", but even if that is a satisfactory workaround, the much more interesting question, at least to me, is why does the message "disappear". -- 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mai…

6 years

Search results for query "sapiro"