It seems templates can be configured in the filesystem or via postorius. When I place a footer template in the filesystem it worked fine. Then without adjusting any configuration, without removing that, I tried to use the postorius control panel to add a footer template, which ends up in the database, both the core and web databases.
But emails stop getting sent out. Emails were posted into Hyperkitty, but not mailed out via postfix.
Whatever system logs I have access to, I have checked. There are no apparent errors anyplace. Perhaps I didn't look in the right places.
The problematic email arrives, is posted to Hyperkitty, but isn't emailed out to subscribers. As if the template broke something.
I remove the template from the postorius UI.
Those queued emails are instantly sent!
The template said "test content". No variables.
I checked on the server for "queued emails" and did not find those either, in postfix or mailman. Mysterious. The phenomenon is repeatable on this server. Add a footer template, emails stop.
On 6/19/25 12:06, Sam Darwin via Mailman-users wrote:
It seems templates can be configured in the filesystem or via postorius. When I place a footer template in the filesystem it worked fine. Then without adjusting any configuration, without removing that, I tried to use the postorius control panel to add a footer template, which ends up in the database, both the core and web databases.
But emails stop getting sent out. Emails were posted into Hyperkitty, but not mailed out via postfix.
This is a known issue when header and/or footer templates are not accessible.
I checked on the server for "queued emails" and did not find those either, in postfix or mailman. Mysterious. The phenomenon is repeatable on this server. Add a footer template, emails stop.
The mails should be in Mailman's var/queue/out queue.
Since the issue only occurs in your case when you have a Postorius template, I suspect the issue is in your setting for POSTORIUS_TEMPLATE_BASE_URL.
When you have the Postorius template set, what does the database query
SELECT uri FROM template WHERE name = 'list:member:regular:footer' and
context = 'your.list.id';
return for the uri? is it retrievable? The initial part of the uri up to
but not including /mailman3/api/... comes from the
POSTORIUS_TEMPLATE_BASE_URL setting
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks. That fixed it.
Comments:
In the docs, the instructions say "POSTORIUS_TEMPLATE_BASE_URL = 'http://localhost:8000'. As a reader, you are thinking, I'm running both hyperkitty and postorius. Hyperkitty is at /archives/ and postorius is at /mailman3/ . What about the path '/mailman3/ for postorius?
The doc could mention the path even if it's to explain why it's not needed. (The reason perhaps it's not needed is root will redirect to '/mailman3/'.)This all seems very self-referential. The setting goes into settings.py which is the website for postorius itself. It is accessing itself. Given that's the case do you really need to tell Django about it's own URL? Doesn't it know it's own URL already? Could Django just contact itself without being configured?
Logging... when it can't find the templates, does it log an error anywhere?
The server had been up for a year. After I rebooted, the problem vanished, even after removing the new setting. So either it's caching the setting in Redis, or else the problem is really gone. Very strange.
Anyway, that was it. thank you.
It takes time to figure out a new feature. I see what is happening. :-) Or, merely one step further.
After a template is stored in the DB you can remove POSTORIUS_TEMPLATE_BASE_URL because the value is cached in the DB. That explains the caching.
Next, without POSTORIUS_TEMPLATE_BASE_URL, it assumes http://localhost:8000/mailman3/ . On our server this is not correct, because it's listening on a unix socket, as well as 80 and 443, but not 8000.
On 6/19/25 15:42, Sam Darwin via Mailman-users wrote:
It takes time to figure out a new feature. I see what is happening. :-) Or, merely one step further.
After a template is stored in the DB you can remove POSTORIUS_TEMPLATE_BASE_URL because the value is cached in the DB. That explains the caching.
Next, without POSTORIUS_TEMPLATE_BASE_URL, it assumes http://localhost:8000/mailman3/ . On our server this is not correct, because it's listening on a unix socket, as well as 80 and 443, but not 8000.
Actually, it assumes whatever the default is which might be
http://localhost:8000. See
https://gitlab.com/mailman/mailman-web/-/blob/master/mailman_web/settings/ma....
It's Postorius that adds the /mailman3/... when setting the template
table entry.
If that is not correct for your server, you need to set the correct value in settings.py.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 6/19/25 14:30, Sam Darwin via Mailman-users wrote:
Thanks. That fixed it.
Comments:
- In the docs, the instructions say "POSTORIUS_TEMPLATE_BASE_URL = 'http://localhost:8000'. As a reader, you are thinking, I'm running both hyperkitty and postorius. Hyperkitty is at /archives/ and postorius is at /mailman3/ . What about the path '/mailman3/ for postorius? The doc could mention the path even if it's to explain why it's not needed. (The reason perhaps it's not needed is root will redirect to '/mailman3/'.)
I'm guessing you are looking at https://docs.mailman3.org/projects/mailman-web/en/latest/settings.html#mailm...
Although the name of the setting includes Postorius, the definition there says "Base URL where Django/Mailman-web would be listening for requests." I.e., the base URL for accessing Django, not Postorius.
- This all seems very self-referential. The setting goes into settings.py which is the website for postorius itself. It is accessing itself. Given that's the case do you really need to tell Django about it's own URL? Doesn't it know it's own URL already? Could Django just contact itself without being configured?
It and in this case Postorius know the /mailman3/... part, but they don't necessarily know the appropriate base url for accessing the Django WSGI.
- Logging... when it can't find the templates, does it log an error anywhere?
Mailman's outgoing runner logs an error to the mailman.error log, usually written to mailman.log. The not at all descriptive log message says "Cannot connect to SMTP server <configured smtp_host> on port <configured smtp_port>", but it only logs it the first time and not again until there is a successful delivery.
This issue is https://gitlab.com/mailman/mailman/-/issues/514 which I am in the process of fixing.
- The server had been up for a year. After I rebooted, the problem vanished, even after removing the new setting. So either it's caching the setting in Redis, or else the problem is really gone. Very strange.
See https://gitlab.com/mailman/mailman/-/issues/514#note_101644301
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Actually, it assumes whatever the default is which might be http://localhost:8000. See https://gitlab.com/mailman/mailman-web/-/blob/master/mailman_web/settings/ma...
This is just tossing out some ideas, and it may not be worth it, but in the code instead of hardcoding the variable:
POSTORIUS_TEMPLATE_BASE_URL = 'http://localhost:8000'
Compute the value dynamically based on the function request.build_absolute_uri() , or request.get_full_path().
Still allowing the user to override POSTORIUS_TEMPLATE_BASE_URL in their own settings.py file, but in the absence of settings.py, it uses "absolute_uri" from the request session.
participants (2)
-
Mark Sapiro -
Sam Darwin