Search results for "Postorius" - Mailman-users

Re: mailman3 on new Debian 12 installation, got ssl apache working on all URLs except /mailman3

by Philip Bondi

Thank you, Mark, and the whole community for your help, so far. Gosh, it feels so close. It works from browser on Debian virtual machine: But still fails through Apache: root@shackleton12:~# *cat /etc/mailman3/urls.py* # **************************************************************************** # # $Id: urls.py 165750 2025-03-31 18:19:32Z svn_beechwood $ # $URL: https://systemdatabase.com/svn/svn-sdi/sdi-sysadmin/trunk/SHACKLETON12-root… $ # $Date: 2025-03-31 14:19:32 -0400 (Mon, 31 Mar 2025) $ # # Description: https://gitlab.com/mailman/mailman-web/-/blob/master/mailman_web/urls.py # # **************************************************************************** # -*- coding: utf-8 -*- # Copyright (C) 2023 by the Free Software Foundation, Inc. # # This file is part of mailman-web. # # Postorius is free software: you can redistribute it and/or modify it under # the terms of the GNU General Public License as published by the Free # Software Foundation, either version 3 of the License, or (at your option) # any later version. # # Postorius is distributed in the hope that it will be useful, but WITHOUT # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for # more details. # # You should have received a copy of the GNU General Public License along with # Postorius. If not, see <http://www.gnu.org/licenses/>. from django.conf.urls import include from django.contrib import admin from django.urls import path, reverse_lazy from django.views.generic import RedirectView urlpatterns = [ path( '', RedirectView.as_view(url=reverse_lazy('list_index'), permanent=True), ), # Include alternate Postorius and HyperKitty URLs. path('postorius/', include('postorius.urls')), path('hyperkitty/', include('hyperkitty.urls')), # Order counts for various links. Put the above first and the following # after so the suggested Apache config still works. *path('mailman3/', include('postorius.urls')),* path('archives/', include('hyperkitty.urls')), path('', include('django_mailman3.urls')), path('accounts/', include('allauth.urls')), path('admin/', admin.site.urls), ] When I hit https://systemdatabase.ca/mailman3, I see the following in /var/log/apache2/systemdatabase.ca_error.log [Mon Mar 31 13:48:21.074890 2025] [proxy:error] [pid 3075263:tid 3075272] (2)No such file or directory: AH02454: uwsgi: attempt to connect to Unix domain socket */run/mailman3-web/uwsgi.sock* (localhost:0) failed [Mon Mar 31 13:48:21.075258 2025] [:error] [pid 3075263:tid 3075272] [client 192.168.1.1:48063] AH10101: failed to make connection to backend: localhost:0 This is my /etc/apache2/sites-available/systemdatabase.ca-le-ssl.conf # **************************************************************************** # # $Id: systemdatabase.ca-le-ssl.conf 165634 2025-03-27 20:07:40Z svn_beechwood $ # $URL: https://systemdatabase.com/svn/svn-sdi/sdi-sysadmin/trunk/SHACKLETON12-root… $ # $Date: 2025-03-27 16:07:40 -0400 (Thu, 27 Mar 2025) $ # # Description: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… # # **************************************************************************** <IfModule mod_ssl.c> <VirtualHost *:80> ServerName systemdatabase.ca Redirect permanent / https://systemdatabase.ca/ DocumentRoot /var/www/html/systemdatabase.ca/ </VirtualHost> <VirtualHost *:443> SSLEngine on ServerAdmin pjbondi(a)systemdatabase.com ServerName systemdatabase.ca ServerAlias www.systemdatabase.ca DocumentRoot /var/www/html/systemdatabase.ca/ ErrorLog ${APACHE_LOG_DIR}/systemdatabase.ca_error.log CustomLog ${APACHE_LOG_DIR}/systemdatabase.ca_access.log combined Include /etc/letsencrypt/options-ssl-apache.conf SSLCertificateFile /etc/letsencrypt/live/systemdatabase.ca-0001/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/systemdatabase.ca-0001/privkey.pem Alias /static/ /opt/mailman/web/static/ <Directory "/opt/mailman/web/static/"> Require all granted </Directory> <IfModule mod_headers.c> RequestHeader unset X-Forwarded-Proto <If "%{HTTPS} =~ /on/"> RequestHeader set X-Forwarded-Proto "https" </If> </IfModule> <IfModule mod_proxy.c> ProxyPreserveHost On ProxyPass "/postorius" "http://127.0.0.1:8000/postorius" ProxyPass "/hyperkitty" "http://127.0.0.1:8000/hyperkitty" 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" ProxyPass "/mailman3" "http://127.0.0.1:8000/mailman3" ProxyPass "/archives" "http://127.0.0.1:8000/archives" # https://github.com/maxking/docker-mailman/issues/525 #ProxyPass / unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ #ProxyPassReverse / unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ ProxyPassMatch "^/$" "http://127.0.0.1:8000/mailman3" </IfModule> </VirtualHost> </IfModule> -- Philip Bondi,pjbondi(a)SystemDatabase.com cell: +1 -416 540-2869 ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: image/png Name: 07YHHkaJc8flnc8d.png Content-Type: image/png Name: tBLp6tc9U7kLbxko.png Replaced multipart/alternative part with first alternative.

1 year, 1 month

Re: hyperkitty web site

by Mark Sapiro

On 4/28/20 9:40 AM, Gelpi Andrea wrote: > > If in django administration I rename that site it works. > > But having more than one domain this is not a solution. > > what i need is to separate different domains > > https:/website1/mailman3/hyperkitty shows some lists > https:/website2/mailman3/hyperkitty shows other lists There are issues with FILTER_VHOST. See <https://gitlab.com/mailman/postorius/-/issues/394> for the Postorius issue. This will be fixed for Postorius in the next release. For HyperKitty, the issue is <https://gitlab.com/mailman/hyperkitty/-/issues/254>. This is not yet fixed. Currently, if FILTER_VHOST is True, HyperKitty only shows lists in the index for which the list's domain matches the domain in the accessing url with a leading 'www.' stripped. E.g. list(a)example.com will only show on the index if the accessing URL's host is example.com or www.example.com, but not if it is say lists.example.com. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years

Re: One-click unsubscribe?

by Stephen J. Turnbull

Jered Floyd writes: > Ugh, I had not considered that RFC 8058 breaks the separation of > concerns here. Not your job, but it is ours. :-) > we can at least make this work for Postorius users. Definitely, that's a reasonable first step. We just need to make sure to do that while allowing others to opt out until they've implemented it themselves. I think I have a suggestion how it could just work for everybody, though. > Are there many who use just Mailman-Core and not the full suite? I don't know about absolute numbers, but yeah, it's a FAQ. There's the EMWD Affinity application which replaces Postorius for many of the sites they host, and enterprises often ask how to use bespoke scripts to control lists (although they may be using Postorius as well). > The URI path/query is defined as opaque. It probably should be > something like list-name/subscribed-address plus a signed hash to > avoid unsub-attacks. That means this likely will be a new web > application endpoint (although it may be possible to overload the > existing "unsubscribe" endpoint -- I haven't looked at the code > yet). RFC 8058 says The URI SHOULD include an opaque identifier or another hard-to-forge component in addition to, or instead of, the plaintext names of the list and the subscriber. The server handling the unsubscription SHOULD verify that the opaque or hard-to-forge component is valid. We don't need to have an explicit reference to the subscription in the URI. As I discovered (to my chagrin) Mailman's current simple RFC 2369 List-Unsubscribe field doesn't, even for personalized lists where there might be a personalized link in the footer. So I think we should go with "instead of". Maybe while experimenting it would be useful to have the plain text subscription information in the URI, though. So ... the existing REST endpoint in core won't change, because the whole REST API assumes that it's talking to the superuser. The "obvious" way to do this is through Postorius, which provides a proxy object backed by a map in Mailman core from tokens in the URL to subscriptions, and use the existing REST endpoint. This is "obvious" because Django already provides an authorization framework for subscription management -- we wouldn't be exposing anything else protected by that framework to mischief. The token would be the encrypted (list, address) pair, possibly dated in clear (to allow expiration of tokens and rotation of encryption keys). Unfortunately RFC 8058 doesn't discuss that, I guess John assumed that people would usually be unsubscribing from the most recent post. On the assumption that unsubscribes would be "rare", you wouldn't have to store the token in the database. (Have to think about that, you might be able to DOS attack by sending lots of fake unsubscribes and attack the encryption with known plaintext attacks. Safety would suggest adding a random nonce and that would need to be saved in the database.) Alternatively, you could reverse proxy this directly through the front-end webserver to Mailman core with a new REST endpoint. That gives me bad vibes because I can just see naive admins messing up the configuration of the single endpoint, and "fixing" the problem by reverse proxying port 8001 to the Internet. We'd have to be careful that the urlconf not slop over to anything else, maybe something like "listen" on the Internet at (nginx notation): location /mailman3/rfc8058/ { proxy_pass http://localhost:8001/3.2/PROXIED/rfc8058; } The "PROXIED" part is just to provide a REST namespace that is obviously separate from the domains, addresses, users, lists, etc. Maybe "SELF_AUTHORIZING" would be more accurate. I think that reverse proxy sepcification would be safe enough. And you could combine the two strategies which would allow sites that don't use Postorius to configure the reverse proxy, while sites that do would get it for "free" since we'd configure Postorius to do it. Aside: RFC 8058 says But anti-spam software often fetches all resources in mail header fields automatically, without any action by the user, and there is no mechanical way for a sender to tell whether a request was made automatically by anti-spam software or manually requested by a user. Weirdly, the RFC doesn't address this problem at all. :-( -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

5 months, 1 week

Re: Mailman3 throws 500 error (unicode encode) when loading held messages in Postorius

by Mark Sapiro

On 9/6/20 3:39 PM, Simon Handfield via Mailman-users wrote: > Thanks for your advice, Stephen. > > As I've removed the file from the shunt queue I don't believe that file is causing the 500 error any more. > > I've confirmed the error is not cached in the browser. > > If the issue does not reside in the shunt queue (no other files indicate parse errors when checking via command line) are there any other places I should look for data that is addressed by that page? As Steve said, messages in the shunt queue have nothing to do with the held messages view in postorius. Held messages are in Mailman's var/messages/ directory and referenced by entries in the message table in the database which in turn are referenced by entries in the pendedkeyvalue table. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 8 months

Re: List nonmembers

by Abhilash Raj

On Tue, Jul 9, 2019, at 10:01 AM, Stephen J. Turnbull wrote: > Abhilash Raj writes: > > > > I'm pretty sure there are ways in Postorius to create a *user* that > > > has no *addresses*, although I've not tried, and I don't know if such > > > Postorius users would be reflected in the core database. > > > > That's not True anymore, signing in to Postorius/Hyperkitty requires > > you to have an email address > > Creating a User does, or logging in does? Specifically, wouldn't it > be possible to create a User, then remove all the addresses? I don't know if there is a way to create a user without signup/signin, both of which needs an email address. Even Core's API requires that you provide a required argument "email" when creating a User. I haven't looked closely enough to figure out if we can delete the primary (and only, the last one) address of a user at all. > > -- thanks, Abhilash Raj (maxking)

6 years, 10 months

Re: Filter who can send on mailman3 list?

by Mark Sapiro

On 4/7/21 1:32 AM, Marcus Granath wrote: > > Sorry, but actually I can not find any "Users dropdown" to select "Non-Members" at any Postorius in my web interface. :-( It's one of the various tabs across the top of the page. What Postorius version is this? Seversal versions back, I think it was called `members` rather than `users`. In current Postorius, the tabs are Info Subscription requests Held messages Users Templates Settings Mass operations Ban List Header filters Delete As I said, `Users` used to be `Members` and `Templates` was added at some point, but that's the general idea. > Maybe, could it be that I am actually not the admin of the mailman3 server, I'm "just" the admin of my mailman-list - so just admin for my mailman-list and not for the mailman server? As Steve said, the list admin should see all those. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 1 month

Re: Postorius permissions granularity

by Stephen J. Turnbull

Liam Reilly writes: > It looks like we're going to take the simple route of the helpdesk > using existing screen sharing tools to assist list owners, rather > than providing elevated access in Postorius. Many of our list > owners are not technical and so the transition from Mailman 2 to 3 > has been challenging for some. Understood. Some of the design of Mailman 2 had become unsupportable over the years, and there were some features we needed to add. But accomodating those also causes discontinuities for many users. I may have a customer for a change related to your request for "view-only" superusers . If it's possible to implement in such a way as to support your requirement as well, I'll let you know. Even if you find that the screen-sharing approach makes it unnecessary for you, having multiple possible use cases makes integrating the feature much more attractive for us. Steve -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

4 months, 4 weeks

Re: Disabling Mass operations

by iMark

> On 1/23/26 17:39, iMark wrote: >> Hi All, >> >> Can anyone give me a pointer on disabling "Mass operations" >> (subscribe/removal) in Postorius. >> >> Just removing the menu link from the list-owners administration pages >> would be a good start. On 2026-01-24 02:01, Mark Sapiro wrote: > > This patch will do that > ``` > --- a/src/postorius/templates/postorius/menu/list_nav.html > +++ b/src/postorius/templates/postorius/menu/list_nav.html > @@ -84,6 +84,7 @@ > {% if user.is_superuser or user.is_list_owner %} > <li class="nav-item"><a href="{% url 'list_template_list' > list.list_id %}" class="nav-link {% nav_active_class current > 'templates' %}">{% trans 'Templates' %}</a></li> > <li class="nav-item"><a href="{% url 'list_settings' > list.list_id %}" class="nav-link {% nav_active_class current > 'list_settings' %} ">{% trans 'Settings' %}</a></li> > + {% if user.is_superuser %} > <li class="dropdown nav-item"> > <a href="#" class="{% nav_active_class current > 'list_mass_ops' %} dropdown-toggle nav-link" data-bs-toggle="dropdown" > role="button" aria-haspopup="true" > aria-expanded="false"> > @@ -98,6 +99,7 @@ > <li><a href="{% url 'mass_removal' list.list_id %}" > class="dropdown-item">{% trans 'Mass removal' %}</a></li> > </noscript> > </li> > + {% endif %} > <li class="nav-item"><a href="{% url 'list_bans' > list.list_id %}" class="{% nav_active_class current 'list_bans' %} > nav-link">{% trans 'Ban List' %}</a></li> > <li class="nav-item"><a href="{% url 'list_header_matches' > list.list_id %}" class="nav-link {% nav_active_class current > 'list_header_matches' %}">{% trans 'Header filters' %}</a></li> > <li class="nav-item"><a href="{% url 'list_delete' > list.list_id %}" class="{% nav_active_class current 'list_delete' %} > nav-link">{% trans 'Delete' %}</a></li> > ``` > Some lines in the above may be wrapped but basically it just adds > > {% if user.is_superuser %} > > and > > {% endif %} > > around the Mass operations code. > Thank you very much Mark. That is perfect. /opt/mailman/venv/lib/python3.11/site-packages/postorius/templates/postorius/menu/list_nav.html Cheers.

3 months, 2 weeks

Re: "Unsubscribe all" failed with large lists

by Abhilash Raj

thanks, Abhilash Raj On Wed, Jan 20, 2021 at 10:34, Alan So <ktso(a)cuhk.edu.hk> wrote: > We are currently testing latest mailman suite (w/Postorius 1.3.3) and > notice that that the the API call > /3.1/lists/listname.domain/roster/member failed when using > "Unsubscribe all" on Postorius for a large list (~15000 members). > Not sure whether the issue has been already reported or not. It has been reported before for sure, but I couldn't find an issue tracking it in Postorius' tracker so I created one[1]. The Core and Mailmanclient already have a mass-unsubscribe API that doesn't require looping over all address and unsubscribing them one by one, it just needs to be plumbed through in P, in case someone wants to take a stab at it. [1]:https://gitlab.com/mailman/postorius/-/issues/464 > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > <mailto:mailman-users@mailman3.org> > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > <mailto:mailman-users-leave@mailman3.org> > <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/>

5 years, 3 months

Re: postorius configuration of the from-part

by Wolfgang Bock

Hello, thanks for your information. After creating the dmarc-entries in the DNS-databases everthing works as wanted! Regards Wolfgang Am 13.11.2019 um 06:02 schrieb Mark Sapiro: > On 11/12/19 2:27 PM, Wolfgang Bock via Mailman-users wrote: >> Hello, >> >> can someone give me an advice how I can configure in the >> postorius-menues the view of the from-part of my list-member like in >> this mailinglist: >> >> Wolfgang Bock_via Mailman-users_ <mailman-users(a)mailman3.org> > > The above is the result of Settings -> DMARC Mitigatations -> DMARC > mitigation action = "Replace From: with list address" > > You can apply that to only messages From: a domain the publishes a DMARC > policy of reject or quarantine or to all messages depending on DMARC > Mitigate unconditionally. > > >> case 1 reply goes to the list or to the member >> case 2 reply goes only to the list > > The DMARC Mitigatations settings are independent of the various reply > settings on the Alter Messages tab. >

6 years, 6 months

Mailman-users search results for query "Postorius"