Search results for "Postorius" - Mailman-users

Re: Mailman, etc. upgrade woes and persistent bugs

by Abhilash Raj

On Fri, Feb 12, 2021, at 11:52 AM, Mark Sapiro wrote: > On 2/11/21 10:22 PM, hansen(a)rc.org wrote: > > I just had my Mailman suite upgraded. When it got started, I starting receiving messages that hundreds of subscribers to the lists had been disables, including several of the list moderators. This version started supporting bounce processing, but how in the world was this upgrade allowed to act on bounces that were being collected PRIOR to enabling bounce processing?? > > > I'm sorry about that. It's too late now, but the avoidance is discussed > at > <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…>. > > > > I got many angry emails, messages and phone calls asking what was going on, as they were bona fide list members. I was very surprised myself. > > > > I then looked at several of the disabled accounts, but the subscription info page in Postorius had no information about whether an account was enabled or disabled. Why is this not displayed???. The members can't see if their account is enabled. Is this another example of the disconnect between Mailman and Postorius? > > > If the user has a Django account, she can see all that info at (e.g. for > this list) <https://lists.mailman3.org/mailman3/accounts/subscriptions/> > She gets there from `Mailman settings` in the dropdown under her user > name. She can also get there via the `Manage Subscription` button on the > list's Info page. That takes her to `List-based preferences` for the > list. Any setting not selected there is inherited from the Address-based > preferences or Global Mailman preferences IIUC, I think what Allan is trying to point out is that if your account was disabled due to bounces, there is no real visual indication about that if you go to any of the Preferences pages (either, Global preferences, List based preferences of address based preferences). Even if you login as an admin and go to Member Option's view, you won't see any visual indication about the delivery being disabled. The is definitely a bug, caused due to the fact that "Delivery Status" field only has two options, "Enabled" and "Disabled". Internally, this field can have 4 values, "enabled", "by_user" (maps to "Disabled" in Postorius), "by_admin" (means disabled by admin) and "by_bounces" (means disabled due to bounces). So, when the value of the field is among the last two options, it appears as "unset" with no options selected, which unfortunately is also how it looks by default since all options are "unset" from start. The "fix" for this issue would be simply adding a new choice to the delivery_status field with a caveat that it is only a Readonly option to see that delivery is disabled due to bounces and not choosable as a valid delivery_status value by user or admin when submitting the form. https://gitlab.com/mailman/postorius/-/issues/469 We could also go a step further and show it on the List's info page when their delivery is disabled due to excessive bounce and allow the them to re-enable it themselves without admin intervention. This would ofcourse show only when you log into your account and go to the list's info page, but I guess that is the first place you'd go to debug when you get an email that your delivery was disabled? https://gitlab.com/mailman/postorius/-/issues/470 I don't know if there are any downsides to letting users re-enable their delivery on their own. > > > > Further, even after the upgrade, the moderators still cannot access the list memberships even though all the lists are set to allow that. I would have asked the moderators to do this if this access bug had been fixed, but they can't get there. > > You've already reported this at > <https://gitlab.com/mailman/postorius/-/issues/462>, and it's been > previously reported at <https://gitlab.com/mailman/postorius/-/issues/369>. > > > > As a result of these bugs, after consulting with Brian, who helped with the upgrade, I spent many hours re-enabling the several hundred accounts that had been disabled. I had to go through each email notification to find the address of a disabled account, then find the list, then the member, in Postorius, and finally enable the account (at which time Postorius DID show the enabled status). > > > I'm sorry you had to go through this. The potential issue and the > avoidances should be better documented. Unfortunately, they aren't. > > > > Please, can the next upgrade include these very basic fixes/enhancements, which I requested a long time ago: > > > > a. The ability of moderators to see the list membership (a bug). > > As I note above, this is a known issue. We are a small project with very > feew core developers, all of whom are volunteers. There is a merge > request at <https://gitlab.com/mailman/postorius/-/merge_requests/423> > which purports to fix > <https://gitlab.com/mailman/postorius/-/issues/369>, but as you can see > from the comment thread, it is not complete and the author has > apparently disappeared. > > If you would like to take it over and address the deficiencies, we would > welcome that. > > > > b. The ability of members to change their addresses for all lists they are subscribed to. > > > Users can add addresses to their account and can then change their > subscribed address at (again, e.g. for this list) > <https://lists.mailman3.org/mailman3/accounts/list-options/mailman-users.mai…> > (Get there via the `Manage Subscription` button on the list's Info > page.) > > If one is subscribed to lists via their `primary` address, one can go to > `E-mail Addresses` in their account settings and make a new address > `primary` and that will change all their subscriptions. > > > > and further, now: > > > > c. That when members go to look at their subscription info, they can actually see the settings. > > > They can if they go to `Mailman settings` in the dropdown or the `Manage > Subscription` button on the list's Info page and look at all the tabs. > > -- > 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)

5 years, 7 months

Re: FILTER_VHOST fix - was: Postorius & multi domain

by Mark Sapiro

On 4/23/20 12:11 PM, Gelpi Andrea wrote: > > > I can confirm that the fix works. > > Thank You so much. Thank you for testing and reporting. Note I have just made one minor change to the fix. Where I had in the added code > if (MailDomain.objects.get( > mail_domain=domain.mail_host).site.name == web_host): I now have > if (MailDomain.objects.get( > mail_domain=domain.mail_host).site.domain == web_host): The issue is site.name is the domain's display name whereas the domain name is site.domain. This only matters if you have given the site a display name different from the domain name in Django. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 5 months

Re: Postorius upgrade issue

by Joel Lord

So I tried to do this after upgrading, fortunately only from 1 point release back, and I get "ModuleNotFoundError: No module named 'paintstore'" from the collectstatic. Haven't tried to get past that point, and haven't really had the time to chase this down myself. It seems like that's referring to a requirement from several versions back, but this venv was built clean only 2 months ago so it strikes me as odd. On 2/8/2021 6:18 PM, Mark Sapiro wrote: > I neglected to mention `migrate`. All 4 Django management commands, `collectstatic`, > `compress`, `compilemessages` and `migrate` should be run after any upgrade. > _______________________________________________ > 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/ > -- Joel Lord

5 years, 7 months

Re: Welcome message template errors

by Mark

On 2024-04-22 14:07, Mark Sapiro wrote: > I think you must be setting the custom template via Postorius and > your Django setting for POSTORIUS_TEMPLATE_BASE_URL is wrong. It > should be set to the scheme and host you use to access Postorius. I.e, > if you normally access Postorius via something like > https://example.com/mailman3 set > > POSTORIUS_TEMPLATE_BASE_URL = 'https://example.com' > > It is probably now set as > > POSTORIUS_TEMPLATE_BASE_URL = 'http://<REDACTED-PUBLIC-IPv4-ADDRESS>' ================================================================================ There was no line POSTORIUS_TEMPLATE_BASE_URL in /etc/mailman3/settings.py So I've now added the line: POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.mydomain.com' Checked in settings.py that: - "lists.mydomain.com" is in ALLOWED_HOSTS; and - "https://lists.mydomain.com" is in CSRF_TRUSTED_ORIGINS Restarted everything... rm /opt/mailman/mm/var/locks/* systemctl restart mailman3 systemctl restart mailmanweb systemctl daemon-reload systemctl restart qcluster # pstree systemd─┬─ ├─gunicorn───gunicorn ├─mailman-web───mailman-web───4*[mailman-web] ├─nginx───2*[nginx] ├─postgres───18*[postgres] ├─python3─┬─11*[python3] │ ├─python3───{python3} │ └─python3───2*[python3] I deleted the custom Welcome template via the WebUI (Postorius), and checked it was removed from the database (PostGres mailman.template). Then, as site-owner, creating a new custom Welcome template (again via the WebUI) I can see it correctly added to the database in mailman.template.uri - https://lists.mydomain.com/mailman3/api/templates/list/lists.mydomain.com/l… Previously it was writing ... - http://localhost:8000/mailman3/api/templates/list/lists.mydomain.com/list:u… So far so good. Nothing showing in mailmanweb.log yet. Then, still as site-owner using Postorius, I mass-subscribed a new member (pre confirm, pre approve, pre verify all ticked). The error below displays on the webpage, the member is subscribed, but no custom welcome message emailed out. =================================== HTTP Error 400: HTTPSConnectionPool(host='lists.mydomain.com', port=443): Read timed out. (read timeout=5) =================================== And the syslog shows a ton of issues, starting with: =================================== 2024-04-22T23:39:27.536002+00:00 lists mailman[1317]: Apr 22 23:39:27 2024 (1317) HTTPSConnectionPool(host='<LISTS.MYDOMAIN.COM>', port=443): Read timed out. (read timeout=5) 2024-04-22T23:39:27.537648+00:00 lists mailman[1317]: Traceback (most recent call last): 2024-04-22T23:39:27.537681+00:00 lists mailman[1317]: File "/opt/mailman/venv/lib/python3.11/site-packages/urllib3/connectionpool.py", line 536, in _make_request 2024-04-22T23:39:27.537700+00:00 lists mailman[1317]: response = conn.getresponse() 2024-04-22T23:39:27.537717+00:00 lists mailman[1317]: ^^^^^^^^^^^^^^^^^^ 2024-04-22T23:39:27.537740+00:00 lists mailman[1317]: File "/opt/mailman/venv/lib/python3.11/site-packages/urllib3/connection.py", line 461, in getresponse 2024-04-22T23:39:27.537757+00:00 lists mailman[1317]: httplib_response = super().getresponse() 2024-04-22T23:39:27.537772+00:00 lists mailman[1317]: ^^^^^^^^^^^^^^^^^^^^^ 2024-04-22T23:39:27.537790+00:00 lists mailman[1317]: File "/usr/lib/python3.11/http/client.py", line 1374, in getresponse =================================== I removed the custom welcome message and the newly subscribed members. The default "You've been unsubscribed" notice got emailed out okay. Then mass subscribing a member, the default welcome message gets emailed out okay and no error displayed on the webpage. I have no idea what the report in syslog is saying, or where to look next. Any help appreciated.

2 years, 5 months

Moderated unsub requests are not provided by mailman3 service

by Joachim Schrod

Hello, I'm new to Mailman3; being in the process of moving some mailing lists from an ancient Mailman2 installation to a new host. (These lists are not big; they are used to organize a yearly holiday of roughly 50 persons.) As part of the migration; I'm testing out actions that were done on the previous Mailman2 instance. Currently, I stumble over confirmation of unsubscribe requests. Unsubscribe policy of the list is "Moderate". I subscribed an email address and used "Mass operations - Mass removal" in Postorius to unsubscribe it. (Actually, since it didn't work at first, I used that dialog twice.) Now I, as the mailing list owner, get a daily email vom Mailman3 that there are pending unsubscription requests that I shall approve. (Both unsubscription requests for the same email requests are listed in that email; doublettes are not handled properly.) The unsubscriptions requests are not shown in the web interface. I suppose they should appear in the UI section "Subscription requests", either as "Pending Approval" or "Pending Confirmation". (Frankly, I don't understand the difference between these two options at all.) Tracing the communication between Postorius and mailman3 service, I see that Postorius asks mailman3 about pending unsubscriptions with the following requests: 1) GET /3.1/lists/MBOX@DOMAIN This returns list information. 2) GET /3.1/lists/MBOX@DOMAIN/requests?token_owner=moderator This returns a JSON structure with properties "start" 0 and "total_size" 0. 3) GET /3.1/lists/MBOX@DOMAIN/requests/count?token_owner=moderator This returns a JSON structure with count 0. 4) GET /3.1/lists/MBOX@DOMAIN/held/count This also returns a JSON structure with count 0. When one wants to see the "Subscriptions pending user confirmation", there is also a GET to get the requests of token_owner=subscriber; returning the same result as the request for token_owner=moderator above. Looking at the mailman3 database, there are 2 records in table `workflowstate' that are in step `unsubscribe_from_restore' who describe the open unsubscribe requests. I could not identify any other database records that are obviously relevant to that issue. (Since this is a fresh test setup, the database is small enough that I can still look at any record in the database.) Why does Mailman3 have no info in its JSON responses about the unsubscription requests that I get informed about daily? Any hints where I could look further are dearly accepted. System information: mailman3 3.3.3; Postorius (mailman3-web) 1.3.4; both on Debian 11 (bullseye). I know that this is out of date; thus a definitive info "this is fixed by now" is quite OK for me. (Debian upgrade is planned as the next action after getting Mailman3 to work for that use case.) Hope that someone can guide me towards a solution, Joachim PS: The list configuration that I actually want is something completely different: mass unsubscription by the mailing list owner without moderation; but moderation for individual unsubscription requests. This is a mailing list where every year all subscribers are setup anew. Subscribers are email-illiterate users who may know WhatsApp at best, which brings its own problems. No person (un)subscribes herself or himself; all is done by the list owner. Unsubscription would mean cancelling the holiday participation -- the list owner must then ask if that's really wanted... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: joachim(a)schrod.org Roedermark, Germany ``How do we persuade new users that spreading fonts across the page like peanut butter across hot toast is not necessarily the route to typographic excellence?'' -- Peter Flynn

1 year, 9 months

Re: Template Ignored?

by Stephen Daniel

Thanks for clarifying. All is working now!!! On Thu, Feb 17, 2022 at 1:27 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 2/17/22 10:10, Stephen Daniel wrote: > > Fixed the POSTORIUS_TEMPLATE_BASE_URL. Doesn't fix the issue. > > I've been playing with wget, and no matter what I put, I keep getting a > 404 > > error. > > > > So: this works: > > > > wget -O wget.out --user restadmin --password restpass ' > > http://localhost:8001/3.1/lists/list.example.com' > > > > but this does not (404 error): > > > > wget -O wget.out --user restadmin --password restpass ' > > > http://localhost:8001/3.1/templates/list/list.example.com/list:user:notice:… > > > You are using Mailman core's REST API which is wrong. You need to get > the template from Postorius. Maybe something like > > > > http://localhost/postorius/api/templates/list/list.example.com/list:user:no… > > Where http://localhost/postorius/ is the URL you use to access > Postorius, maybe mailman3 instead of postorius. > > Once you figure that out, POSTORIUS_TEMPLATE_BASE_URL is just the scheme > and domain part of that. > > -- > 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, 7 months

Re: Apache shows No Lists

by Mark Sapiro

On 5/21/23 15:15, ceo(a)sartrack.nz wrote: > Running Debian 11. > > I have 6 mailing lists, but Apache2 says there are no lists. > I have not been able to set up Postorius because nowhere is any information on *where* the configuration file is supposed to be located. If Postorius is not running, what is Apache looking at? > I have found an example in > /usr/share/doc/python3-django-hyperkitty/examples/settings.py > > But I don't know if this example is the right one, and I have no idea where the final file should go... Please follow the doc at <https://docs.mailman3.org/en/latest/install/virtualenv.html>. This is our current recommendation. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 4 months

Re: Trouble importing a Mailman 3 Postgres database into a new Mailman 3 instance (Docker)

by skenny＠scss.tcd.ie

Mark Sapiro wrote: > > My point was after you remove the newly minted mailmandb database and > then create a new blank one, and import into that, you should then run > manage.py migrate to apply any new migrations to the imported database. Ah, right ... ok, I've done that now, and all's good. Actually, I've noticed something related. It looks like the mailman-web container runs manage.py as part of its startup procedure in any event. After the import completes, I start up the mailman-web container and, its logs say this: mailman-web | Operations to perform: mailman-web | Apply all migrations: account, admin, auth, contenttypes, django_mailman3, django_q, hyperkitty, postorius, sessions, sites, socialaccount mailman-web | Running migrations: mailman-web | Applying auth.0012_alter_user_first_name_max_length... OK mailman-web | Applying django_q.0014_schedule_cluster... OK mailman-web | Applying hyperkitty.0022_mailinglist_archive_rendering_mode... OK mailman-web | Applying postorius.0014_auto_20210329_2248... OK mailman-web | Applying postorius.0015_auto_20210619_0509... OK mailman-web | Applying postorius.0016_auto_20210810_2157... OK If the container is restarted again, it shows that there's nothing to do this time: mailman-web | Apply all migrations: account, admin, auth, contenttypes, django_mailman3, django_q, hyperkitty, postorius, sessions, sites, socialaccount mailman-web | Running migrations: mailman-web | No migrations to apply. These latter diagnostics are also what I see if, at this point, I enter the mailman-web container and run "manage.py migrate" explicitly. I really appreciate the help, thanks so much.

4 years, 2 months

High Server Load problem

by Brian Carpenter

For about a week now, I am seeing very high server loads and it seems to have something to do with the following process hanging: uwsgi --ini /opt/mailman-web/uwsgi.ini I am using the docker version of Mailman. When this process hangs, the server load just goes sky high and both Postorius and Hyperkitty no longer responds. I don't have very many sites on this server and I am running about 30 lists. I really need some assistance here as this needs to be fixed. I am seeing nothing in the logs that is explaining why this process is hanging and why the server load goes through the roof. Running docker-compose restart mailman-web kills the hanged process and the server load goes down. Postorius and Hyperkitty starts responding again. This seems to happen once a day. Brian

6 years, 10 months

[MM3-users]Re: mailman 2 vs. mailman 3: what happened to multipart/digest?

by Mark Sapiro

On 5/13/16 5:05 PM, Simon Hanna wrote: > On 05/12/2016 09:26 PM, Barry Warsaw wrote: >> On May 12, 2016, at 12:18 PM, Mark Sapiro wrote: >> >>> It is the intent that Postorius will eventually expose all these >>> settings. We're not there yet. At present you could possibly do this by >>> interacting with mailmanclient, although I'm not certain the settings are >>> exposed there. >> >> I'm not sure if they're exposed in mailmanclient, but they are exposed in the >> core's REST API, on the member resource. It's the `delivery_mode` attribute >> and it takes as legal values one of 'regular', 'plaintext_digests', >> 'mime_digests', and 'summary_digests' (IOW, the enum item names for the >> DeliveryMode enum). > They are exposed in mailmanclient and are used in postorius. They can be > found in the users personal subscription settings > https://lists.mailman3.org/mailman3/accounts/mailmansettings/ You are correct. When I checked this before my initial reply, I never pulled down the Delivery Mode list to see all the options. My bad. However, please correct me if I'm wrong, but there does not appear to be a way in Postorius to set a list's mime_is_default_digest attribute. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

10 years, 4 months

Mailman-users search results for query "Postorius"