Issue mailman3 web-interface: Link missing in mail, 404 when clicking "manage list" in plesk

[Jan]

Server operating system version

Debian 12

Plesk version and microupdate number

18.0.62 Update #2

Hi,

I'm using mailman3 on plesk and noticed two issues regarding the web-ui

1. When opening the overview of all mailing-lists for a subscription, plesk has a "Manage the list" button for each list in the table.
   Clicking that button opens a new browser-window to - for example - https://lists.crypto.koeln/mailman3/postorius/lists/testml.crypto.koeln (testml is the mailinglist, crypto.koeln the domain name). This results in a HTTP-404, generated by "Apache Server at lists.crypto.koeln Port 443"
2. When subscribing new users to a list, the system generates a welcome-mail saying: "(...) If you have forgotten your password you will need to reset it via the web UI." However, the mail does not contain any link. Users don't know the URL of web UI. This looks like an UX-bug to me.

Regards, Jan

 

[Aleksei Fedorov]

Hello, thank you for your feedback. We will confirm the described bugs and fix them in the future.

 

[Mikhail_S]

Hello @Jan

Please let me share the details of my checks for the mentioned points:

1. The behavior was not reproduced. The links work well, the configuration can be opened without any issues.
   Thus, I would assume it is somehow related to the specific configuration or is caused by some issues on this exact server.
   
   
2. Such emails are generated by Mailman itself. Plesk does not manage them anyhow.
   The default templates can be checked here: Templates — GNU Mailman 3.3.10b1 documentation
   However, the templates can be edited manually:
   

Please let me know if I missed anything.

 

[Jan]

Thanks for your feedback.

Regarding 1) I don't recall any configuratiuon changes to this server.

The server was basically a Debian 12 clean-install running a backup restore of a Debian 10 host. I didn't do anything else.
I could if all configuration files are generated correctly - esp. w.r.t the vhost / webserver-configuration. Is there a reference (doc, example) for doing so?

Thanks, Jan

 

[Jan]

Edit: To be more specific:

1. Apparently, apache2 is serving the hosts lists.luehr.tech and generating a http-404
2. /etc/apache2/plesk.conf.d/server.conf is the only apache2-configuration defining a vhost for lists.* - it looks like this:

Listen 127.0.0.1:7082 http
<VirtualHost 127.0.0.1:7080 127.0.0.1:7082>
        DocumentRoot "/var/www/vhosts/default/htdocs"
        ServerName lists
        ServerAlias lists.*
        UseCanonicalName Off

        <IfModule mod_rewrite.c>
                RewriteEngine On
                RewriteCond %{HTTPS} off
                RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L,QSA]
        </IfModule>

</VirtualHost>

<IfModule mod_ssl.c>
        <VirtualHost 127.0.0.1:7081>
                DocumentRoot "/var/www/vhosts/default/htdocs"
                ServerName lists
                ServerAlias lists.*
                UseCanonicalName Off

                Alias "/mailman3/favcion.ico" "/var/lib/mailman3/web/static/postorius/img/favicon.ico"
                Alias "/mailman3/static" "/var/lib/mailman3/web/static/"

                SSLEngine on
                SSLVerifyClient none
                SSLCertificateFile "/opt/psa/var/certificates/scfZk6ouC"

                <Directory /var/lib/mailman3/web/static/>

                        Options FollowSymLinks
                        Require all granted
                </Directory>

                <IfModule mod_proxy_uwsgi.c>
                        ProxyPass /mailman3/favicon.ico !
                        ProxyPass /mailman3/static !
                        ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/
                </IfModule>

        </VirtualHost>
</IfModule>

The IfModule-directive looks a bit strange to me. What is supposed to happen, if the module is not loaded?
Indeed, if I remove the <IfModule mod_proxy_uwsgi.c>-directive, apache2 logs:

[Wed Sep 04 19:17:16.611224 2024] [proxy:warn] [pid 1638342:tid 1638350] [client 81.0.161.32:0] AH01144: No protocol handler was valid for the URL /mailman3/postorius/lists/test.luehr.tech (scheme 'uwsgi'). If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.

Executing a2enmod proxy_uwsgi && systemctl restart apache2 fixed the issue

Thus, from my understanding:

1. The issue is related to apache2-modules not being loaded
2. I didn't not unload any apache2 modules on purpose
3. Guess: Plesk failed to enable this module, although it is needed.
4. There's a still any issue with plesk mailman-support not checking if proxy_uwsgi is enabled

Greetz, Jan

 

[Mikhail_S]

Hello @Jan
The described behavior still looks like something customized. I have tried to reproduce that once again on a fresh Debian 12 server but to no avail.
The links work perfectly well without any additional actions required.

As for the Apache configuration, the IfModule directive simply checks if the Apache extension mod_ssl is loaded. If so, the HTTPS configuration is used by Apache. There is nothing specific, it is a default part of the configuration.

 

[Jan]

Hi @Mikhail_S.,

thanks for your answer. Regarding:

As for the Apache configuration, the IfModule directive simply checks if the Apache extension mod_ssl is loaded. If so, the HTTPS configuration is used by Apache. There is nothing specific, it is a default part of the configuration.

I was referring to <IfModule mod_proxy_uwsgi.c> - Sorry for the confusion.

IMHO this directive does not make sense. Effectively, it causes the server to answer calls to lists... with http-404 instead of http-500. This was misleading for me.

Greetz Jan

 

[Mikhail_S]

I would like to say that there is also the default state. I have the same on a test server:

                <IfModule mod_proxy_uwsgi.c>
                        ProxyPass /mailman3/favicon.ico !
                        ProxyPass /mailman3/static !
                        ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/
                </IfModule>

The module is loaded:

# apachectl -M | grep proxy_uwsgi
 proxy_uwsgi_module (shared)

---

Just to be on the same page. Here are the details line by line:

<IfModule mod_proxy_uwsgi.c>

It checks if the extension mod_proxy_uwsgi is loaded. If so, the block inside is handled.

ProxyPass /mailman3/favicon.ico !

The path /mailman3/favicon.ico is excluded from being proxied, so Apache should serve it directly.

ProxyPass /mailman3/static !

The path /mailman3/static is excluded from being proxied, so Apache should serve it directly.

ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/

All requests starting with /mailman3 are redirected to a Unix socket (located at /run/mailman3-web/uwsgi.sock), using the uwsgi protocol.

</IfModule>

The closing tag of the block.

From the above, there is nothing unexpected.

 

[Jan]

Hei,

thanks for your message. To be more specific, I try to outline my view on <IfModule mod_proxy_uwsgi.c>. Trivially, there are two possibilities:

1. The module is not loaded. Then postorious cannot be served and links result in http-404
   This was the situation on my machine. I did not disable the module by-hand. The installation was basically a clean install + backup recovery, so there is potentially an error in plesk's setup / backup-restore routine that causes the module to be disabled. Additionally, there were no log-entries highlighting the problem of the missing module. As an improvement, Plesk could log the situation more clearly and assist in troubleshooting.
   Nevertheless, serving static files in this situation is not of help. There's an error in the server-configuration that needs to be resolved.
   => Apparently, the <IfModule mod_proxy_uwsgi.c> is superfluous in this scenario.
   (Side note: being pedantic, http-4xx is semantically not correct, because it is a server and not a client-request related problem. http-5xx would have been correct, but let's skip this).
2. The module is not loaded. Postorious is served, and the directive doesn't help.

=> In both situations <IfModule mod_proxy_uwsgi.c> is not of help. It could be better to remove it.

Regards, Jan