Search results for "Postorius" - Mailman-users

Re: content filtering in version 3.1

by Mark Sapiro

On 12/12/19 6:36 AM, Dieter Leupold via Mailman-users wrote: > Hi, > > I'm new to MM3. I installed version 3.1.1 on Ubuntu 18.04. All looks > fine. But i miss the setting "pass_mime_types" at content filtering. The settings are there in Mailman core but not exposed in Postorius. You can set them via `mailman shell`. MM 2.1 settings map to MM 3 as: filter_mime_types -> filter_types pass_mime_types -> pass_types filter_filename_extensions -> filter_extensions pass_filename_extensions -> pass_extensions collapse_alternatives -> collapse_alternatives * convert_html_to_plaintext -> convert_html_to_plaintext * filter_action -> filter_action * in Postorius Settings -> Alter Messages The mailman import21 command will properly import these settings when importing a Mailman 2.1 list. > Also i don't find the settings for bounce processing. Are these features > no longer supported at version 3.1.1? Bounce processing is not yet implemented in MM 2.1. See <https://gitlab.com/mailman/mailman/issues/343>. There was a recent GSOC project to address this. See <https://gitlab.com/mailman/mailman/merge_requests/538>. I don't know how close this is to being ready. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 11 months

Re: templates

by Mark Sapiro

On 5/4/23 11:15, Christian via Mailman-users wrote: > In March when I started troubleshooting my lists, you stated: > > "Also, one other thing you might check. Do these non-working lists have > templates defined in postorius, in particular, one for > list:member:regular:footer, and if not, are there any in Mailman's > var/templates/lists/redlatinleg(a)lists.ccalternatives.org/ derectory that > Mailman doesn't have permission to find and read?" > > There are no other templates listed in either Postorius nor in Mailman's > var/templates (as I stated, I do not even lave a 'lists' subdirectory under > Mailman's var/templates). My subscribers are not receiving message > distributions from my lists, even while some of them are listed in the > archives. See the original thread at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… (which you hijacked about 4 messages in) and particularly the message at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… Without further information, I can't say more than that. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 6 months

Re: Member Issue Discovered

by Abhilash Raj

I am a bit late to this thread, but I am going to try to respond to some of the points raised in the thread. On 10/19/20 7:42 PM, Brian Carpenter wrote: > On 10/19/20 10:23 PM, Mark Sapiro wrote: >> And the import21 created the user and address records for this user. > Does the same thing for a new subscriber as well. So there is no pathway > to change a real name that is associated with an email address. None. > Zilch. Yes, this is a limitation of the REST API, the display_name attribute can't be updated. Hence, Postorius can't provide a way for anyone to update the name. I have opened an issue for this[1] and I think it should be allowed. [1]: https://gitlab.com/mailman/mailman/-/issues/786 > I am admin for a list. Users got subscribed with bulk import during > transition from MM2 to MM3. > So in a sense I am responsible for adding these to a db. BUT there is > no way for me to remove them. Only mailman admin with access to the db > can do it manually. The fact that a user's memberships & User as an entity that owns email address is a design choice that Mailman developers made after some experience of using and administering Mailing lists running on Mailman 2. It was annoying to have to manage several different passwords and accounts to manage membership on same mailing list server. The policy decision that Mailman would allow a user/address to exist even if there are no subscriptions on it isn't un-resonable in certain environments and maybe it is in some. I don't think anyone here denies that either of those behavior could be an expectation from someone using Mailman. But Mailman is an open source project with decent amount of extensibility via HTTP API & Python plugin system. If the default policy doesn't match the expectations of some users, I don't think it is difficult to cleanup users/address with 0 subscriptions in a nightly cron script. It is trivial with some basic scripting and we are happy to help out with such a mechanism. I wouldn't be opposed to directly adding a command in Core that lets you clean up all sorts of stuff. On Wed, Oct 21, 2020, at 10:20 AM, Apollinaris Schöll wrote: > There might be a handful of these. > > But the bigger problem is a user can’t be removed entirely. > > User can delete account and unsubscribe from all lists. But the email > and user name is still kept in the db. Just tested with Affinity > List admin can’t do it either. Front-ends like Affinity should be able to implement such a policy by checking subscriptions of an address on every un-subscription call and delete the user & address if it comes out to be 0. The API is documented here[2], but if there are gaps in there like I mentioned above in my email, please open issues so we know about them. [2]: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… > I think the correct action is to remove all records if a email is > unsubscribed from all lists and that user has not registered for an > account. > If a user has registered for an account all information including > display name must be removed from that particular list subscription. > It should not matter if a user unsubscribes or a list admin > unsubscribes. There shouldn’t be any data kept. Also, like mentioned above, as a list admin, you can request the Site Admin to get the address fully scrubbed or if this is an expectation from all list admins, the Site Admin has the ability to automate such a task. The fact the Mailman doesn't do it by default is because the definition of "correct" action is different. User should have the ability to delete themselves from the system and if it doesn't wipe everything yet from database, it should be considered a bug in Postorius and be fixed. Postorius track users separately than Core, so the it should make sure to delete in both places and there are appropriate APIs in core to delete Users and Addresses. Now, the ability in Postorius to edit the display_name. The side effect of the model where User is a Site level thing, makes it impossible to customize user's display_name on a per-list basis, for both list admin and the user themselves. That is a trade-off and it is possible that there were use-cases where that was desirable in Mailman 2, but with the superior subscription management functionality in Postorius, I feel the decision is justified. I respect that some of y'all think that it probably isn't if it doesn't suit you particular use cases. From the thread, I gather than folks mostly agree that a list admin shouldn't be allowed to edit a user's display name. Site Admins however should be able to edit that, which brings me to next point. Like Mark brought up, there is definitely a big missing feature of User management in Postorius. This future management page would be for Site Admins (Superusers) to manage Users and have the ability to change pretty much everything about users including their addresses, memberships and preferences and also be able to wipe off the users from all the databases if they want to. If there are more features than that which folks think should be a part of this, please feel free to add to it. As it is hopefully implied from the description, it is a big task and needs substantial chunk of time, part of which this hasn't been picked up yet. > > > > > > > > On Oct 21, 2020, at 1:43 AM, Jörg Schulz <info(a)joergschulz.de> wrote: > > > > So, the issue seems to be, like in the following scenario > > > > We imagine a list server for the domains fruiteaters and meateaters. > > We have two listadmins, anna (fruit) and carl (meat). They don't share anything. > > We have a user who subscribes to fruiteaters and meateaters using his address hunger(a)eatall.com > > > > He wants to show up in the fruiteaters list as fullname wormy wonder, but in the meateaters list as fritz the cat. > > While he can do so using two different email addresses, he cannot do so using > > > > wormy wonder <hunger(a)eatall.com> > > fritz the cat <hunger(a)eatall.com> > > > > as from: addresses because all requests will be matched to the one email address. > > > > Worse, if Carl would be able to change the name to from wormy wonder to fritz the cat, Anna would see that name change and like to change it back because the user she had known, user has been identified as wormy wonder. > > > > So, if these user properties are stored somewhere not related to the lists, we don't seem to have a chance of display name changes by list admins as long as the data model isn't changed. This doesn't seem to be easy. > > > > So, only some kind of super-Admin should currently be able to change these display names, and these changes would be visible for all lists, and one email address can only have one display name for all lists. > > > > Not optimal for some rare conditions - that's the way it seems to be??? > > _______________________________________________ > > 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/ > _______________________________________________ > 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, 1 month

Re: New Mailman Releases

by Odhiambo Washington

On Wed, Oct 26, 2022 at 10:16 AM Abhilash Raj <maxking(a)asynchronous.in> wrote: > On 10/26/22 12:32, Odhiambo Washington wrote: > > > > > > On Wed, Oct 26, 2022 at 8:44 AM Abhilash Raj <maxking(a)asynchronous.in > > <mailto:maxking@asynchronous.in>> wrote: > > > > Hi, > > > > I am pleased to announce several new releases for GNU Mailman > project. > > > > 1. Mailman Core 3.3.6 [1] > > 2. Postorius 1.3.7 [2] > > 3. Hyperkitty 1.3.6 [3] > > 4. Mailmanclient 3.3.4 [4] > > 5. Django-mailman3 1.3.8 [5] [snip] > > > Finally, the minimum Python version required is 3.7 although, 3.9 is > > recommended if you are doing a new install for longest support. 3.10 > is > > supported for Django apps, but Mailman Core is missing that due to > one > > of the core dependencies not support 3.10 yet (aiosmtpd). > > > > > > > > Hello @Abhilash Raj <mailto:maxking@asynchronous.in> > > > > Thank you and the whole MM3 team for all the free work you do to make us > > have mailing lists :) > > > > I have a question regarding the Python version. > > I have a very recent installation of MM3, via the Virtual Environment > > method, running smoothly - so far. > > The Python version that got installed is 3.10.6 > > > > wash@lists:~$ sudo su - mailman > > (venv) mailman@lists:~$ which python > > /opt/mailman/mm/venv/bin/python > > (venv) mailman@lists:~$ /opt/mailman/mm/venv/bin/python -V > > Python 3.10.6 > > (venv) mailman@lists:~$ mailma > > mailmail3 mailman > > (venv) mailman@lists:~$ mailman --version > > GNU Mailman 3.3.5 (Tom Sawyer) > > (venv) mailman@lists:~$ > > > > 1. What does the incompatibility with Python-3.10 portend for my setup > > and anyone else with Python-3.10? > > The bug in aiosmtpd is a bit weird and has to do with how the test cases > in aiosmtpd and Python 3.10 changes interact with SSL. For the intents > and purposes of Mailman, we don't use SSL for the communication between > MTA and aiosmtpd, so there _shouldn't_ be any issuer with your setup. > Relief! > Ideally, `pip` shouldn't have allowed you to install aiosmtpd in a > Python venv with 3.10, but that depends on which version of pip you are > using since the newer versions have better support for such management. > I followed the HOWTO by the late BC <https://wiki.list.org/DOC/Howto_Install_Mailman3_On_Debian10> for my installation. I did not have to choose any specific version of pip. I just used what was in the system at that time, which was based on the Python version on the system. > > 2. Is it possible to downgrade the Python in a Venv down to 3.9 without > > breaking the installation? > > You can keep the current installation running and create a 2nd > installation by simply creating a 2nd venv with 3.9. Something like, > `/opt/mailman/mm/venv-3.9/`. You can install things into that venv and > when you are done and ready to switch, you can update all the paths in > various places to use update 'venv-3.9' instead of 'venv'. > That procedure seems way too much work for someone not so well versed with the PATHs used in MM3. Since I don't remember ever having to install aiosmtpd (not even sure what it is!) I believe I should not worry. 'pip3 list | grep smtpd' yielded nothing in my install. Is that expected? Or aiosmtpd is part of the core? In case you encounter any issues, you can always revert back to older > 'venv' in the paths wherever the are needed and bring back the old > install. Venvs are good for multiple installs so you can switch back and > forth pretty easily. > Talking of moving between VENVs, you did not mention about migrating the lists/list data between then :-) > > > > And finally, is there documentation/procedure to upgrade a VENV install > > in this case? > > You don't want to upgrade venv is what i've heard, you should always > create a new one if you are bumping python versions. > Noted. And only Python versions, right? Like 3.10 to 3.11? > If you are just upgrading packages in the existing venv, then you can > follow: > > https://docs.mailman3.org/en/latest/upgrade-3.2.html Thank you for this. I have a request: Is it possible for someone to update the HOWTO that was done by Brian to include the process of updating MM3? I can see that he created a heading that was supposed to have the procedure. I am assuming it should be a few simple additions - but I am not quite sure (see below): (1) Pre-upgrade First, you need to stop the running Mailman services before the upgrade to make sure that you don’t end up in a bad state. You can stop the three systemd services: $sudo systemctl stop mailman3 $sudo systemctl stop qcluster $sudo systemctl stop gunicorn (2) Then you need to switch to mailman user, activate the virtualenv: $ sudo su mailman $ source /opt/mailman/mm/venv/bin/activate (3) Upgrade package Finally, upgrade your packages: Here, I am a little confused. The official MM3 documentation says the below: *(venv) $ pip install -U mailman postorius django-mailman3 hyperkitty mailman-web* However, thee howto by BC, there was no installation for django-mailman3 and mailman-web. So I am unable to map 1:1 what needs to be done to upgrade to these 5 components of 1. Mailman Core 3.3.6 [1] 2. Postorius 1.3.7 [2] 3. Hyperkitty 1.3.6 [3] 4. Mailmanclient 3.3.4 [4] 5. Django-mailman3 1.3.8 [5] What should I add to the command line below so that everything is updated? (venv) mailman@lists:~$ pip install -U mailman postorius hyperkitty mailman-hyperkitty Sorry to bother you so much. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

2 years, 1 month

Re: Maximum number of recipients Setting

by Brian Carpenter

On 4/3/21 5:04 PM, Mark Sapiro wrote: > On 4/3/21 1:45 PM, Brian Carpenter wrote: >> I have run several tests. It looks like on the 'Maximum number of >> recipients' setting, a 2 means 1. If I set it to 2, I can have the >> listname(a)listdomain.com only. If I have a CC, it comes to me for >> moderation. If I set it to a 3, I can send out to >> listname(a)listdomain.com plus a CC. If I set it to 3 and add 2 CC's plus >> the listname(a)listdomain.com address, it comes to me for moderation. > > I understand it's confusing, but it's been that way since the beginning > of Mailman 2.1. The docs at > <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rules/docs…> > say "For backward compatibility, the message must have fewer than the > maximum number of explicit recipients." > > I agree the description in Postorius could be clarified see > <https://gitlab.com/mailman/postorius/-/issues/515>. > That explains it. Thanks for solving this mystery. -- Brian Carpenter Harmonylists.com Emwd.com

3 years, 7 months

Re: Mailman 3 localization

by Simon Hanna

> Thanks for the reply, Simon! We were thinking of using plain .po-files > too, however, we couldn't find the matching "src" folder in our > installation, do you have any more details where it or the .po-files > may also be located? What component are you talking about? For Postorius and Hyperkitty you should be able to create the files needed according to this https://docs.djangoproject.com/en/2.0/topics/i18n/translation/#message-files First run "django-admin makemessages -l de" to create the .po files and after editing "django-admin compilemessages -l de" to compile them. You should be fine doing that in your production django-project. Otherwise you can clone the frontend projects and run the commands inside the project folders. (src/postorius or hyperkitty/). I know the second option works, since that's what I'm doing (I'm deploying from the git heads) but doing that in the production projects (where manage.py is located) should generate the same files. It might generate files for dependencies as well... As for core, I only know how to translate the templates. I have no idea how the messages included in the source code should be translated.

6 years, 4 months

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

by Simon Handfield

Hi Mark, thanks for correcting my assumption. Based on your information I have been able to identify the suspect message file in /var/lib/mailman3/messages, replace the suspect file with another file, update the file permissions and successfully load the held messages page. This allowed me to discard the suspect message and other held messages are then available for review again. In case the steps below help someone else who is having this issue here are the steps I followed with my initial search string redacted: Searched all files in messages folder for matching string: cd /var/lib/mailman3/messages grep -ir [REDACTED] * Finds string in one file: Binary file HE/D7/HED7SJLGJXTJ35AESY32AZXYPXDEVUVV matches Check whether file can be parsed using mailman command: mailman qfile ./HE/D7/HED7SJLGJXTJ35AESY32AZXYPXDEVUVV Throws a matching error: [----- start pickle -----] <----- start object 1 -----> Traceback (most recent call last): File "/usr/bin/mailman", line 11, in <module> load_entry_point('mailman==3.1.1', 'console_scripts', 'mailman')() File "/usr/lib/python3/dist-packages/mailman/bin/mailman.py", line 97, in main args.func(args) File "/usr/lib/python3/dist-packages/mailman/commands/cli_qfile.py", line 81, in process printer.pprint(obj) File "/usr/lib/python3.6/pprint.py", line 139, in pprint self._format(object, self._stream, 0, 0, {}, 0) File "/usr/lib/python3.6/pprint.py", line 161, in _format rep = self._repr(object, context, level) File "/usr/lib/python3.6/pprint.py", line 393, in _repr self._depth, level) File "/usr/lib/python3.6/pprint.py", line 405, in format return _safe_repr(object, context, maxlevels, level) File "/usr/lib/python3.6/pprint.py", line 555, in _safe_repr rep = repr(object) File "/usr/lib/python3/dist-packages/mailman/email/message.py", line 45, in __repr__ return self.__str__() File "/usr/lib/python3.6/email/message.py", line 135, in __str__ return self.as_string() File "/usr/lib/python3.6/email/message.py", line 158, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/python3.6/email/generator.py", line 116, in flatten self._write(msg) File "/usr/lib/python3.6/email/generator.py", line 181, in _write self._dispatch(msg) File "/usr/lib/python3.6/email/generator.py", line 214, in _dispatch meth(msg) File "/usr/lib/python3.6/email/generator.py", line 272, in _handle_multipart g.flatten(part, unixfrom=False, linesep=self._NL) File "/usr/lib/python3.6/email/generator.py", line 116, in flatten self._write(msg) File "/usr/lib/python3.6/email/generator.py", line 181, in _write self._dispatch(msg) File "/usr/lib/python3.6/email/generator.py", line 214, in _dispatch meth(msg) File "/usr/lib/python3.6/email/generator.py", line 243, in _handle_text msg.set_payload(payload, charset) File "/usr/lib/python3.6/email/message.py", line 315, in set_payload payload = payload.encode(charset.output_charset) UnicodeEncodeError: 'ascii' codec can't encode characters in position 8-9: ordinal not in range(128) Move suspicious file out of messages: mv ./HE/D7/HED7SJLGJXTJ35AESY32AZXYPXDEVUVV /root/20200914/ held_messages page still throws 500 error. Checking debug log, it is now because the database references a file that is no longer there. Can I just copy a parseable file to the path of the bad file so I can delete it or do I need to remove the reference from the database? Copy some other file: cp ZZ/B2/ZZB24ADTZ2BOKBWTQWI7KG4XACGR6DTJ HE/D7/HED7SJLGJXTJ35AESY32AZXYPXDEVUVV Still throws an error but this time it's a permissions error. mailman can't access the copied file: ls -l HE/D7/ -rw-r----- 1 root root 78472 Sep 14 12:48 HED7SJLGJXTJ35AESY32AZXYPXDEVUVV chown list:list HE/D7/HED7SJLGJXTJ35AESY32AZXYPXDEVUVV chmod g+w HE/D7/HED7SJLGJXTJ35AESY32AZXYPXDEVUVV ls -l HE/D7/ -rw-rw---- 1 list list 78472 Sep 14 12:48 HED7SJLGJXTJ35AESY32AZXYPXDEVUVV held_messages now loads OK. Cheers, Simon. ________________________________ From: Mark Sapiro <mark(a)msapiro.net> Sent: Saturday, 12 September 2020 06:17 To: mailman-users(a)mailman3.org <mailman-users(a)mailman3.org> Subject: [MM3-users] Re: Mailman3 throws 500 error (unicode encode) when loading held messages in Postorius 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 _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mai… _ [State Library of NSW]<https://www.sl.nsw.gov.au/> Simon Handfield Desktop and Infrastructure Leader simon.handfield(a)sl.nsw.gov.au<mailto:simon.handfield@sl.nsw.gov.au> +61 2 9273 1535 Macquarie Street, Sydney NSW 2000, Australia www.sl.nsw.gov.au<https://www.sl.nsw.gov.au/> This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of their organisation.

4 years, 2 months

Re: Various patches for mm3 stable 3.3.1

by Mark Sapiro

On 9/30/20 6:57 AM, Ruth Ivimey-Cook wrote: > > 1. If I do not set up 'individual' or 'full' personalisation, all is > well and the default footer templates are expanded as expected. However > setting up personalisation causes template expansion to fail > completely, and messages get sent with a blank expansion. Your mailman-debug.patch makes changes to mailman/handlers/decorate.py including wrapping all the relevant code in a try:/except: that logs any exception. If you set the level for logging.error to debug, what do you get in the log? This issue doesn't occur in the unpatched code on my servers - personalized footers work fine - so I think the problem must be something in your patch. > 2. I would find the postorius UI much easier to cope with if the > default template was 'populated' into the UI wherever it was non-blank, > rather than the UI starting off as if no templates were defined at all. This is <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

4 years, 1 month

Re: Moderate mails from owner

by Henrik Rasmussen

Mark Sapiro wrote: > This can happen in a few ways., If this list was originally imported > from Mailman 2.1 by the 'mailman import21' command, there may be a > legacy accept_these_nonmembers attribute for the list. If so, and if a This makes sense. The list was in fact imported from Mailman 2.1. > You need to check the list's accept_these_nonmembers attribute and the > non-member address's moderation action. > > If you have recent Postorius, you can see nonmembers and their options > from the 'users' -> Non-members view. I currently have Postorius 1.2.2 so I don't have it yet. > mailman shell -l list.example.com The sender is in the list of accept_these_nonmembers, however the command memb.moderation_action = m.default_nonmember_action doesn't seem to remove it from accept_these_nonmembers. bash-4.3# mailman shell -l [LISTNAME].lists.example.com Welcome to the GNU Mailman shell The variable 'm' is the [LISTNAME].lists.example.com mailing list >>> m.accept_these_nonmembers ['listadmin(a)senderdep.example.com'] >>> memb = m.nonmembers.get_member('listadmin(a)senderdep.example.com') >>> memb.moderation_action <Action.accept: 3> >>> memb.moderation_action = m.default_nonmember_action >>> m.accept_these_nonmembers ['listadmin(a)senderdep.example.com'] -- Henrik

5 years, 6 months

Re: Struggle on upgrading mailman3-web to new version - Not Found: /mailman//

by Mark Sapiro

On 10/25/21 1:45 AM, Stefan Bauer wrote: > Dear Users, > > I recently upraded mailman3 from Ubuntu 18 to 20. After accessing the > web-interface via > > https://my.mailinglistserver.local/mailman3/postorius/lists/ > > I receive > > Not Found: /mailman//postorius/lists/ > [pid: 1346851|app: 0|req: 4/4] 10.254.253.12 () {70 vars in 1369 bytes} > [Mon Oct 25 10:39:59 2021] GET /mailman3/postorius/lists/ => generated 2821 > bytes in 12 msecs (HTTP/1.1 404) 5 headers in 155 bytes (1 switches on core > 1) > > Where does the wrong path come from (mailman vs. mailman3) See the thread at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… ... > <IfModule mod_proxy_uwsgi.c> > ProxyPass /mailman3/favicon.ico ! > ProxyPass /mailman3/static ! > ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ > </IfModule> Others have found that removing the trailing slash from ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ to make it ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost fixes the issue. -- 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

Mailman-users search results for query "Postorius"