Search results for "Postorius" - Mailman-users

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.

1 year, 5 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

9 years, 5 months

Re: Where should Postfix, Django, Hyperkitty, Postorius, Dart-Sass, etc. be installed if MM3 is in a python virtual environment?

by Ron / BCLUG

Keith Christian wrote on 2024-05-24 16:41: > pip install wheel mailman psycopg2-binary > Should, or must, any of Django, Hyperkitty, Postorius, Dart-Sass, or > any other supporting programs be installed into this virtual > environment ? As I understand it, mailman-hyperkitty get installed into the venv, but django and postorius are pulled in as a dependency of mailman-web (I believe?) I don't seem to see any SASS modules when I run `pip list | grep -i sass` in the venv. This handled the SASS stuff: > sudo apt install python3-dev python3-venv sassc lynx I created a file called `requirements.txt` which I use thusly in the venv: `pip install -r requirements.txt` I don't know if I can attach it to messages to the list, so I've included it below: ===%<--- requirements.txt --->%=== mailman mailman-web mailman-hyperkitty ## PyMySQL is used in the database connection def in mailman.cfg: ## PyMySQL ## ## For mailman-web migrate with MySQL, mysqlclient is required! ## mysqlclient ## PostgreSQL: psycopg2-binary uwsgi ## Wheel is advised, but (mostly) works without. wheel ## module error on missing "xapian_backend" when running ## `mailman-web update_index_one_list` ## ## ## ModuleNotFoundError: No module named 'xapian_backend' ## ## Requires separate build process (and wheel): see docs xapian-haystack Hopefully I'm not too wrong in what I've posted. rb

1 year, 4 months

Syncing Real Name between user account and membership

by Stephen J. Turnbull

Andreas Barth writes: > a user was mass-subscribed (with a wrong name) and now registered > and changed his name via the web interface but the list entry is > not changed. I don't recall the design discussion, but I'm pretty sure that this distinction was intentional. The idea was that people might want to have different display names associated with different addresses (eg, you probably don't want your User display name associated with an address you use on anonymized lists). I'm not sure that option has any merit in practice. @ Abhilash: Since Postorius doesn't provide a way to manage address-specific display names, we should probably have Postorius propagate display name changes. I believe that is normally what the user wants. What does everybody think?

4 years, 10 months

Re: Unwanted E-mail to Maillists Submitted via Postorius Interface

by Brett Delmage

On Thu, 26 Aug 2021, Stephen J. Turnbull wrote: > However, it turns out that bots are almost as good at solving captchas > as humans, and they can retry a lot faster. Captchas are also really > horrible from an accessibility perspective. I have to disagree. I previously put a captcha on a Joomla website which stopped 100% of all bogus account signup attempts. What was it ? "How many letters are in the word 'jazz'"? This captcha is fully accessible, too. If there's a captcha problem out there, it's because too many people just use the same old, same old - which is worth the bots cracking because it is used everywhere. Or they use google catcha crap, tracking vistors without permission and invading their privacy. Brett

4 years, 1 month

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

10 months, 3 weeks

Re: Changing default message limit (max_message_size)

by Abhilash Raj

On Mon, May 27, 2019, at 8:23 AM, Mark Sapiro wrote: > On 5/27/19 12:05 AM, roger(a)reasonal.com wrote: > > I found the field in settings that would appear to do this, but it just throws an error for whatever I give it ("An error occured**: Unknown attribute: max_message_size"). > > This should be fixed at > <https://gitlab.com/mailman/mailman/merge_requests/329>. > > Perhaps you need to update your Docker images > <https://asynchronous.in/docker-mailman/> That's right. You are probably using a new version of Postorius but not of Mailman Core. Please make sure the container images you have are updated. > > Also, see > <https://gitlab.com/mailman/postorius/issues/246#note_69323948> for a > not about changing this via `mailman shell` (withlist), but see the > subsequent comment about `quit()` > > > > PS As a suggestion, may be a good idea to indicate what units it's expecting... bytes? kB? Nybbles? > > Reported at <https://gitlab.com/mailman/postorius/issues/362>, thanks. > > > PPS ** Psst: occurred with two r's... > > Reported at <https://gitlab.com/mailman/postorius/issues/361>, thanks. > > -- > 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)

6 years, 4 months

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)

4 years, 8 months

Re: SMTPSenderRefused - howto enable STARTTLS for local mail drop

by Stefan Bauer

Hi Steve, thank you for your time. Thats it :) Works now. I had to set it in /etc/mailman3/mailman-web.py After first logon, django tries to send a mail to confirm email address. Nov 10 08:44:56 mal02 postfix/qmgr[2893767]: 9255C5E0BE2: from=<postorius(a)lists.mydomain.tld>, size=920, nrcpt=1 (queue active) Nov 10 08:44:56 mal02 postfix/smtpd[879486]: disconnect from localhost[::1] ehlo=2 *starttls=1* mail=1 rcpt=1 data=1 quit=1 commands=7 This now works with STARTTLS. Hoooray :) Am Di., 9. Nov. 2021 um 16:50 Uhr schrieb Stephen J. Turnbull < stephenjturnbull(a)gmail.com>: > Stefan Bauer writes: > > > No matter what i try, mailman still only connects without STARTTLS: > > Earlier you wrote: > > > SMTPSenderRefused at /accounts/login/(530, b'5.7.0 Must issue a > STARTTLS command first', 'postorius(a)lists.mydomain.tld') > > Request Method: POST > > Request URL: https://mm3.mydomain.tld/mailman3/accounts/login/ > > Django Version: 2.2.12 > > This looks like Django errors, not Postorius (Mailman). So this is > something Django is doing, not Mailman (including Postorius). I'm not > sure why Django is sending email (somebody made a password reset > request seems likely, but I'm not that familiar with Django authn > stuff). Anyway, if it's internal to Django, it would not consult > Mailman's configs. This recent StackOverflow seems relevant: > > > https://stackoverflow.com/questions/60025730/530-5-7-0-must-issue-a-starttl… > > HTH > > Steve > >

3 years, 11 months

Re: User management page [was: Changing subscription address]

by Stephen J. Turnbull

Abhilash Raj writes: > Typo :( Page in Postorius is what I meant to say. :D No problemo, mon, I just did it too -> > Is that necessarily required? Every user in Django has a corresponding > user in Core, but the converse isn’t true and I am not sure if that is even > required. I meant "accessed from Postorius or HyperKitty." :-) > You will be able to see: > - Does the user have a Django account? > - All Subscriptions for the User > - All addresses of the User > > You will be able to perform following actions: > - Add or remove a user’s address > - Verify or un-verify an address > - Set any address as primary for the user > - Update display name of the user > - Update address on any of the subscriptions I don't think we *need* a Django account for what I'm thinking of. I do think that creating the account on User access from Postorius might make the implementation logic simpler. > What I am on fence about: > - Provide a full blown preferences menu to the admin for that user. This > will also make the UI extremely complex to see and implement. Wait to decide on that until I have a mockup or maybe a full MR. > But, when you have an account in Django with a different email > (email2) and a different Mailman user (user2) and you add a second > email (email1) to your account and are able to prove ownership by > verifying the address, Django will ask Core to add that second address > (email1) to your Mailman user (user2) and absorb “user1”. This > process is already implemented. Good. > However, if two Django accounts are created for “user1” and “user2” > then situation becomes more tricky and currently we don’t have a > way to resolve that short of delete one of the accounts and add the > addresses to other account. Delete "that" and add its attributes to "this" is what I had in mind. Again, thanks for explaining the existing logic. Steve

4 years, 6 months

Mailman-users search results for query "Postorius"