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

[MM3-users] Re: Header Filter madness

by Brian Carpenter

On 1/13/21 3:05 PM, Mark Sapiro wrote: > On 1/12/21 9:57 PM, Mark Sapiro wrote: >> On 1/11/21 6:14 PM, Brian Carpenter wrote: >>> On 1/11/21 8:48 PM, Mark Sapiro wrote: >>>> On January 11, 2021 5:50:04 PM MST, Brian Carpenter >>>> <brian_carpenter(a)emwd.com> wrote: >>>>> I have a client whose header filters seemed to have stop working. No >>>>> matter what I try, it seems none of their header filters are being >>>>> applied. Other lists on the same server that use header filters, are >>>>> working fine. This particular header is the subject header. I can >>>>> duplicate their problem but only with their list. If I create the exact >>>>> same header on a test list using the exact same subject line, the >>>>> header >>>>> filter does its job (moderate). Just not with this one list. >> >> What's in the X-Mailman-Rule-* headers of the post that should be but >> isn't held? >> >> Are there other header filter rules besides the one that doesn't work? > Also, on your test list, did you copy/paste the regexp or retype it. If > the latter, there is possibly trailing whitespace that breaks it. Thanks Mark. I am currently waiting for feedback from my client. -- Brian Carpenter Harmonylists.com Emwd.com

5 years, 9 months

[MM3-users] Re: Subscription request cannot be moderated: 404 Not Found

by Mark Sapiro

On 1/16/21 9:46 AM, Eric Broens via Mailman-users wrote: > Hi Mark, > Unfortunately the provided options didn't work out either: > > 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 ************* mailing list >>>> ISubscriptionManager(m).confirm('4d6b4b11266c7332684c5a492eb3f92c531f761b') > Traceback (most recent call last): > File "<console>", line 1, in <module> > File "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/subscriptions.py", line 578, in confirm > workflow.restore() > File "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/workflow.py", line 142, in restore > raise LookupError(self.token) > LookupError: 4d6b4b11266c7332684c5a492eb3f92c531f761b It appears that although the token was in the pended table, it wasn't in the workflowstate table. I have no clue how this happened. > I noticed that the mail address was also listed as a non-member. > After deleting it there, I could not accept the subscription either. > Next, I have rejected the subscription and added it using the mass subscription option in the WebUI. > > I'll monitor if such cases will happen again. Hopefully it won't happen again, but at least you have 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, 9 months

[MM3-users] Re: Mailman3 is wrongly display name a list member

by Mark Sapiro

On 1/11/22 9:24 AM, Allan Hansen wrote: > Thank youi, Stephen. > > Oops. When I wrote below that I set the name 'B' in the account, I did describe it wrongly. Sorry. > The member just wants one name, 'A' for all her subsriptions. Somehow the 'B' got into the system when we upgraded from Mailman 2 to Mailman 3. > > I removed the address from all the lists, set the account display name to 'A' in Django, verified that she was not subscribed to any list at all, and then resubscribed her again as 'A'. In other words, no 'B' anywhere - straight 'A's. > Nevertheless, the new subscriptions still show up as 'B'. A user has a user record and one or more address records. Each of these has a display name. Removing users from lists does not remove these records. If you have recent Postorius, you should have a `users` item at the top of Postorius pages. Go there, find the user and click "Manage". You can change Display Name there. Otherwise, in `mailman shell` for example ``` >>> usr = getUtility(IUserManager).get_user('user(a)example.com') >>> usr.display_name = 'First Last' >>> for adr in usr.addresses: ... adr.display_name = 'First Last' ... >>> commit() ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 9 months

[MM3-users] Re: A few more MM3 questions

by Mark Sapiro

On 5/29/24 9:48 AM, Marc SCHAEFER wrote: > > May I just modify those files, and is there any way to see, in the web GUI, > where those files are referenced? Yes, you may modify them. The search algorithm for templates is described at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/utilities/i18n… however, this is only for templates which have no entry or a mailman:/// entry in the template table in the database. Also see https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… > In the database itself, the template table is empty (as seen in the GUI) and I > did not see the text "web_page_url" in a dump of the database, so I have some > issues to understand how this is used by Mailman (except direct file access > to /var/lib/mailman3/templates?) It is by direct access following the search algorithm. If you are looking at templates in Postorius, these can be created and will place the template in the postorius_emailtemplate table in the database and an entry in the templates table with a URI beginning with the POSTORIUS_TEMPLATE_BASE_URL setting to retrieve the template via the Postorius API. The Postorius template UI should show the current value for a template not yet set in Postorius, but it doesn't. See https://gitlab.com/mailman/postorius/-/issues/366. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 4 months

[MM3-users] Re: Cannot Run Web Frontend

by Mark Sapiro

On 12/23/25 10:18, dap1--- via Mailman-users wrote: > I'm having trouble getting my web frontend working. When I try to access http://localhost/mailman3 I get a 503 error and the following in the apache2 error.log: > > [Tue Dec 23 13:08:41.584412 2025] [proxy:error] [pid 132768] (111)Connection refused: AH00957: http: attempt to connect to 127.0.0.1:8000 (127.0.0.1:8000) failed > [Tue Dec 23 13:08:41.584578 2025] [proxy_http:error] [pid 132768] [client 2600:1700:5cac:4600:fc36:9a27:6e66:44b:49658] AH01114: HTTP: failed to make connection to backend: 127.0.0.1 Is mailman-web running? If so, what is the content of /etc/mailman3/uwsgi.ini if you are using uwsgi or /etc/mailman3/gunicorn.conf if you are using gunicorn? What do you get from `http://127.0.0.1:8000/mailman3`? > This is the relevant part of apache2's 000-default.conf: > > <IfModule mod_proxy.c> > ProxyPreserveHost On > ProxyPass "/mailman3" "http://127.0.0.1:8000/mailman3" > ProxyPass "/archives" "http://127.0.0.1:8000/archives" > ProxyPass "/accounts" "http://127.0.0.1:8000/accounts" > ProxyPass "/admin" "http://127.0.0.1:8000/admin" > ProxyPass "/user-profile" "http://127.0.0.1:8000/user-profile" > </IfModule> > > What is a bit confusing but probably unrelated is this is in the virtual section for port 80 rather than port 443. I don't see any errors anywhere else. It needs to be there to support http://localhost/mailman3, but for https://localhost/mailman3, it needs to be in the port 443 section. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

9 months, 3 weeks

[MM3-users] Re: Missing bits of French translation

by Mark Sapiro

On 5/12/26 17:30, iMark wrote: > > 3. Page text fails. eg. > ENGLISH: You have to sign in to visit the archives of this list. > FRENCH: Is in English. > > Looking at the .po file ... > > /opt/mailman/venv/lib/python3.11/site-packages/mailman/messages/fr/LC_MESSAGES/mailman.po > > "PO-Revision-Date: 2024-06-25 17:09+0000\n" That file is out of date. It may or may not be from the latest Postorius released version but it has been subsequently updated for the next release. That particular string is marked fuzzy in the current .po - see <https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/locale/fr/…> It is marked fuzzy because the msgid was changed at some point from ``` msgid "You have to login to visit the archives of this list." ``` to ``` msgid "You have to sign in to visit the archives of this list." ``` The translations are managed at Weblate. The particular French translation for Postorius is at <https://hosted.weblate.org/projects/gnu-mailman/postorius/fr/>. The above string is one of 19 that are marked for edit. You are more than welcome to create an account at Weblate and fix whatever needs fixing in the French translation and Weblate will submit a merge request to update the .po on GitLab. We would be grateful for your help. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 months, 1 week

[MM3-users] Re: 500 error on Held Messages page

by Mark Sapiro

On 9/20/22 19:54, Dan Caballero wrote: > I'm getting an unexpected error when I try to clear all the held messages. Any ideas what could be wrong here? > ``` > (mailmanve) mailman@11f52637274a:/var/www/mailman-www$ mailman shell -l jewishlife(a)caltech.edu > 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 jewishlife(a)caltech.edu mailing list >>>> from mailman.app.moderator import handle_message >>>> requestdb = IListRequests(m) >>>> for req in requestdb.held_requests: > ... if req.request_type == RequestType.held_message: > ... handle_message(m, req.id, Action.discard) > ... > Traceback (most recent call last): > File "<console>", line 3, in <module> > File "/opt/mailmanve/lib/python3.9/site-packages/mailman/app/moderator.py", line 112, in handle_message > key, msgdata = requestdb.get_request(id) > TypeError: cannot unpack non-iterable NoneType object ``` There is a corrupt request with a request id that doesn't exist. Try something like: ``` >>> from mailman.interfaces. >>> requestdb = IListRequests(m) >>> for req in requestdb.held_requests: ... if req.request_type == RequestType.held_message: ... if not requestdb.get_request(req.id): ... print(f'Bad request id: {req.id}, deleting') ... requestdb.delete_request(req.id) ... ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years

[MM3-users] Re: Held messages: Long time waiating for response of the Mailman API

by Mark Sapiro

On 1/24/22 15:06, Mark Sapiro wrote: > On 1/18/22 06:24, Stephan Krinetzki wrote: >> Hello, >> >> We are using Mailman 3.3.5 with Hyperkitty 1.3.5. Mailman 3 is >> installed in a venv and deployed using Apache and uwsgi. This works >> quite well so far, only withheld messages cause us a problem: If we >> try to approve them via Postorius, the message is delivered to the >> list immediately, but the success message in Postorius takes a long >> time - on average the process hangs for three minutes until the >> message is no longer displayed. We have already adjusted the timeout >> in gunicorn.cfg, but this does not improve the situation. Are there >> any tips on how we can speed up the REST API? Or is it even a >> configuration error? > > > There are two steps in handling the POST for a held message. The first > step is accepting, rejecting or discarding the message. This is > happening immediately. > > The second step is handling the poster's moderation action based on the > choice from the Set member moderation dropdown in the view of the held > message. This is processed by the code at > <https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/views/list…>. > If no selection has been made, the default value POSTed for > moderation_choice is `no-action` and that code is skipped. If it is one > of the choices `Hold for moderation`, `Reject (with notification)`, > `Discard (no notification)`, `Accept immediately (bypass other rules)` > or `Default processing` that is processed. So presumably a selection has > been made and processing is stuck on getting the member or setting the > member's moderation action. > > Possibly the logs of your database manager will have information. > Some additional info. By gunicorn.cfg, do you mean the file at mailman/config/gunicorn.cfg? If you are using gunicorn as a wsgi server, that is separate from the gunicorn serving the REST API and its config doesn't affect the REST API. The relevant config is mailman/config/gunicorn.cfg?. Also, I doubt the issue is with the REST API per se, but rather it is in Mailman core's processing of the particular endpoint and if that is slow, it is most likely some kind of database issue. -- 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: Archives with encoding characters

by Mark Sapiro

On 3/4/20 8:55 AM, Seth Seeger wrote: > Hello everyone, > > I have a few (but not all) members complaining that their digests are full of coded characters. Two examples below were forwarded to me: > >> What I ended up doing was creating 2 "practice lines" in the centre of=20 >> our big teaching circle (I always teach new figures in a big circle) -=20 >> which each had 3 people set up in a line with generous space between,=20 >> and first=C2=A0 I walked through one of those lines myself starting first= >> =20 > > and > >> Robins pass Right=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Larks Loop L= >> eft > > What is the cause? Is there anything I can do about it? The cause is a quoted-printable encoded message body not being decoded. This may or may not be a Mailman bug, but if as Mark Dadgar suggests, it only happens with some MUAs, the issue might be in the MUA. To understand more we'd need to see the actual raw digest message from the list, or maybe just a raw incoming message that winds up like that in the digest. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 7 months

[MM3-users] Re: Restore/export existing Mailman lists + hyperkitty archives on a new server

by Mark Sapiro

On 9/14/23 2:09 AM, Alex Schuilenburg via Mailman-users wrote: > > I am migrating from mailman 3.2.1 & mailman3-web 0+20180916-8 on Debian Buster to mailman 3.3.8 & mailman3-web 0+20200530-2.1 on Debian bookworm, have mailman3 and mailman3-web configured (and running on bookworm) from the initial install. But when I use the mailman3-web 0+20180916-8 database (after stopping mailman3 and mailman3-web) on bookworm, unfortunately migrate fails: ... > But the migrate fails at the first operation: > # mailman-web migrate > Operations to perform: > Apply all migrations: account, admin, auth, contenttypes, django_mailman3, django_q, hyperkitty, postorius, sessions, sites, socialaccount > Running migrations: > Applying contenttypes.0001_initial...Traceback (most recent call last): ... > MySQLdb._exceptions.OperationalError: (1050, "Table 'django_content_type' already exists") You are attempting to apply migrations that have already been applied. Apparently the django_migrations table is inconsistent with the state of the database. > Indeed the table django_content_type already exists on 0+20180916-8 . Apart from fields changes, there are an additional 4 tables in mailman3-web 0+20200530-2.1 > > I managed to import the mailman 3.2.1 database to the mailman 3.3.8 database, and all lists, subscriptions and settings looks fine. > > So how can I upgrade my existing mailman3-web database? This appears to be a Debian package issue. I suggest you ask Debian. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 1 month

Search results for query "sapiro"