Mailman shutting down Hyperkitty: Request too large
Hello I need help troubleshooting a problem with MM. The service is stopping and throwing this error in the mailman log "Exception in the HyperKitty archiver: 413 Request Entity Too Large"
I'm not sure what my next steps should be to troubleshoot this issue.
System CTL has this message and i'm not sure if it's relevant to the issue.
>sudo systemctl status mailman3.service
systemd[1]: mailman3.service: Can't open PID file
/opt/mailman/mm/var/master.pid (yet?) after start: No such file or directory
The MM Service will run for a while then shuts down.
/mailman.log
Jan 30 05:22:20 2025 (1547) HyperKitty failure on
https://list.louisvillecommunitygrocery.com/archives/api/mailman/archive:
<html>
<head><title>413 Request Entity Too Large</title></head>
<body>
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx/1.24.0 (Ubuntu)</center>
</body>
</html>
(413)
Jan 30 05:22:20 2025 (1547) Could not archive the message with id <
CAPesOD3EWaFzfVZAbUzFm3Vk3Xnqcf9KodVic6agaT27Kmhy0w@mail.gmail.com>
Jan 30 05:22:20 2025 (1547) archiving failed, re-queuing (mailing-list
lcg-board-private.list.louisvillecommunitygrocery.com, message <
CAPesOD3EWaFzfVZAbUzFm3Vk3Xnqcf9KodVic6agaT27Kmhy0w@mail.gmail.com>)
Jan 30 05:22:20 2025 (1547) Exception in the HyperKitty archiver: <html>
<head><title>413 Request Entity Too Large</title></head>
<body>
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx/1.24.0 (Ubuntu)</center>
</body>
</html>
Jan 30 05:22:20 2025 (1547) Traceback (most recent call last):
File
"/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
line 158, in _archive_message
url = self._send_message(mlist, msg)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
line 228, in _send_message
raise ValueError(result.text)
ValueError: <html>
<head><title>413 Request Entity Too Large</title></head>
<body>
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx/1.24.0 (Ubuntu)</center>
</body>
</html>
Jan 30 05:22:21 2025 (1547) HyperKitty archived message
<CAPesOD25frujqYsAXU3kk8MUOY=h3ZV4cgzUXSi9L0c3K2W0NQ@mail.gmail.com> to
https://list.louisvillecommunitygrocery.com/archives/list/testing@list.louisvillecommunitygrocery.com/message/HU6MK5CB6CE77AIMY5WESY2BNTX7T6YW/
[30/Jan/2025:05:22:43 +0000] "GET /3.1/users/lcgcoop@gmail.com HTTP/1.1"
200 428 "-" "GNU Mailman REST client v3.3.5"
[30/Jan/2025:05:22:43 +0000] "GET
/3.1/users/a6af988d603c49c9ac61a3a41562d132/addresses HTTP/1.1" 200 927 "-"
"GNU Mailman REST client v3.3.5"
[30/Jan/2025:05:22:43 +0000] "POST /3.1/members/find HTTP/1.1" 200 3407 "-"
"GNU Mailman REST client v3.3.5"
[30/Jan/2025:05:22:43 +0000] "POST /3.1/members/find HTTP/1.1" 200 4705 "-"
"GNU Mailman REST client v3.3.5"
[30/Jan/2025:05:22:43 +0000] "GET /3.1/addresses/lcgcoop@gmail.com
HTTP/1.1" 200 401 "-" "GNU Mailman REST client v3.3.5"
[30/Jan/2025:05:22:43 +0000] "GET /3.1/lists/
testing@list.louisvillecommunitygrocery.com HTTP/1.1" 200 482 "-" "GNU
Mailman REST client v3.3.5"
[30/Jan/2025:05:22:43 +0000] "GET /3.1/lists/
testing.list.louisvillecommunitygrocery.com/roster/owner HTTP/1.1" 200 763
"-" "GNU Mailman REST client v3.3.5"
[30/Jan/2025:05:22:44 +0000] "GET /3.1/addresses/lcgcoop@gmail.com
HTTP/1.1" 200 401 "-" "GNU Mailman REST client v3.3.5"
[30/Jan/2025:05:23:53 +0000] "GET /3.1/lists/
testing.list.louisvillecommunitygrocery.com HTTP/1.1" 200 482 "-" "GNU
Mailman REST client v3.3.5"
[30/Jan/2025:05:23:53 +0000] "GET /3.1/lists/
testing.list.louisvillecommunitygrocery.com HTTP/1.1" 200 482 "-" "GNU
Mailman REST client v3.3.5"
[30/Jan/2025:05:23:53 +0000] "GET /3.1/lists/
testing@list.louisvillecommunitygrocery.com/requests/count?token_owner=moderator
HTTP/1.1" 200 73 "-" "GNU Mailman REST client v3.3.5"
[30/Jan/2025:05:23:53 +0000] "GET /3.1/lists/
testing@list.louisvillecommunitygrocery.com/held/count HTTP/1.1" 200 73 "-"
"GNU Mailman REST client v3.3.5"
[30/Jan/2025:05:24:15 +0000] "GET /3.1/lists/
testing@list.louisvillecommunitygrocery.com HTTP/1.1" 200 482 "-" "GNU
Mailman REST client v3.3.5"
Jan 30 05:42:54 2025 (1550) ACCEPT: <008401db72ce$cb6d50d0$6247f270$@
iglou.com>
Jan 30 05:42:55 2025 (1547) HyperKitty failure on
https://list.louisvillecommunitygrocery.com/archives/api/mailman/archive:
<html>
<head><title>413 Request Entity Too Large</title></head>
<body>
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx/1.24.0 (Ubuntu)</center>
</body>
</html>
(413)
Jan 30 05:42:55 2025 (1547) Could not archive the message with id <
CAPesOD3EWaFzfVZAbUzFm3Vk3Xnqcf9KodVic6agaT27Kmhy0w@mail.gmail.com>
Jan 30 05:42:55 2025 (1547) archiving failed, re-queuing (mailing-list
lcg-board-private.list.louisvillecommunitygrocery.com, message <
CAPesOD3EWaFzfVZAbUzFm3Vk3Xnqcf9KodVic6agaT27Kmhy0w@mail.gmail.com>)
Jan 30 05:42:55 2025 (1547) Exception in the HyperKitty archiver: <html>
<head><title>413 Request Entity Too Large</title></head>
<body>
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx/1.24.0 (Ubuntu)</center>
</body>
</html>
Jan 30 05:42:55 2025 (1547) Traceback (most recent call last):
File
"/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
line 158, in _archive_message
url = self._send_message(mlist, msg)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
line 228, in _send_message
raise ValueError(result.text)
ValueError: <html>
<head><title>413 Request Entity Too Large</title></head>
<body>
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx/1.24.0 (Ubuntu)</center>
</body>
</html>
Jan 30 05:42:57 2025 (1547) HyperKitty archived message
<008401db72ce$cb6d50d0$6247f270$@iglou.com> to
https://list.louisvillecommunitygrocery.com/archives/list/lcg-board-private@list.louisvillecommunitygrocery.com/message/M4A4NYUDVJX7WQ63LMIAHGVDU5WS5TP2/
[2025-01-30 05:46:02 +0000] [1554] [ERROR] Worker (pid:1586) was sent
SIGKILL! Perhaps out of memory?
[2025-01-30 05:46:02 +0000] [2227] [INFO] Booting worker with pid: 2227
Jan 30 05:46:09 2025 (1553) pipeline runner caught SIGTERM. Stopping.
Jan 30 05:46:09 2025 (1553) pipeline runner exiting.
Jan 30 05:46:09 2025 (1551) lmtp runner caught SIGTERM. Stopping.
Jan 30 05:46:09 2025 (1551) lmtp runner exiting.
Jan 30 05:46:09 2025 (1558) digest runner caught SIGTERM. Stopping.
Jan 30 05:46:09 2025 (1558) digest runner exiting.
Jan 30 05:46:09 2025 (1557) virgin runner caught SIGTERM. Stopping.
Jan 30 05:46:09 2025 (1557) virgin runner exiting.
Jan 30 05:46:09 2025 (1556) task runner caught SIGTERM. Stopping.
Jan 30 05:46:09 2025 (1556) task runner exiting.
Jan 30 05:46:09 2025 (1541) Master watcher caught SIGTERM. Exiting.
Jan 30 05:46:09 2025 (1555) retry runner caught SIGTERM. Stopping.
Jan 30 05:46:09 2025 (1555) retry runner exiting.
Jan 30 05:46:09 2025 (1552) out runner caught SIGTERM. Stopping.
Jan 30 05:46:09 2025 (1552) out runner exiting.
Jan 30 05:46:09 2025 (1549) command runner caught SIGTERM. Stopping.
Jan 30 05:46:09 2025 (1549) command runner exiting.
Jan 30 05:46:09 2025 (1548) bounces runner caught SIGTERM. Stopping.
Jan 30 05:46:09 2025 (1548) bounces runner exiting.
Jan 30 05:46:09 2025 (1547) archive runner caught SIGTERM. Stopping.
Jan 30 05:46:09 2025 (1547) archive runner exiting.
Jan 30 05:46:09 2025 (1550) in runner caught SIGTERM. Stopping.
Jan 30 05:46:09 2025 (1550) in runner exiting.
[2025-01-30 05:46:09 +0000] [1554] [INFO] Handling signal: term
[2025-01-30 05:46:09 +0000] [2227] [INFO] Worker exiting (pid: 2227)
[2025-01-30 05:46:09 +0000] [1585] [INFO] Worker exiting (pid: 1585)
Jan 30 05:46:10 2025 (1541) Master watcher caught SIGTERM. Exiting.
[2025-01-30 05:46:10 +0000] [1554] [ERROR] Worker (pid:1585) was sent
SIGKILL! Perhaps out of memory?
[2025-01-30 05:46:10 +0000] [1554] [ERROR] Worker (pid:2227) was sent
SIGTERM!
[2025-01-30 05:46:10 +0000] [1554] [INFO] Shutting down: Master
Jan 30 05:46:11 2025 (1541) Master stopped
Thank you, Paul 'Arte Chambers' Robey 502-408-6922
Arte Chambers via Mailman-users writes:
Hello I need help troubleshooting a problem with MM. The service is stopping
If you mean the message quoted below, the Mailman daemons are not stopping. You need to check the "Active", "Main PID", and "CGroup" fields of "systemctl status mailman3.service", or run "mailman status" directly to determine if Mailman is actually running properly or not.
and throwing this error in the mailman log "Exception in the HyperKitty archiver: 413 Request Entity Too Large"
I think a similar issue was reported last week, and Mark is more familiar with it. I seem to remember that it's possible that the message in question is a spam and has non-ASCII characters in the header or body of the message, which violates the email RFCs. Maybe if you move the oldest message in $var_dir/queue/archive (or maybe $var_dir/archiver/hyperkitty/spool) to $var_dir/queue/bad for later inspection things will start running again.
System CTL has this message and i'm not sure if it's relevant to the issue.
sudo systemctl status mailman3.service systemd[1]: mailman3.service: Can't open PID file /opt/mailman/mm/var/master.pid (yet?) after start: No such file or directory
This isn't relevant. The initial 'mailman' process spawns a 'master' process then shuts down. 'master' takes enough time to get rolling that systemd can't find its pid file when 'mailman' shuts down, and systemd is too impatient to wait. That snippet is taken from the systemd journal, and does not reflect current status.
The MM Service will run for a while then shuts down.
This is probably normal, as explained above, unless you mean that "systemctl status mailman3.service" or "mailman status" reports that Mailman is not running. That should have some explanation in $log_dir/mailman.
Steve
and throwing this error in the mailman log "Exception in the HyperKitty archiver: 413 Request Entity Too Large"
I think a similar issue was reported last week, and Mark is more familiar with it. I seem to remember that it's possible that the message in question is a spam and has non-ASCII characters in the header or body of the message, which violates the email RFCs. Maybe if you move the oldest message in $var_dir/queue/archive (or maybe $var_dir/archiver/hyperkitty/spool) to $var_dir/queue/bad for later inspection things will start running again.
There is only 1 .pck file in $var_dir/archiver/hyperkitty/spool and it is only 3.5M - Is there a way I can see what this pck file is?
Thank you, Paul 'Arte Chambers' Robey 502-408-6922
On Thu, Jan 30, 2025 at 12:09 PM Stephen J. Turnbull < turnbull@sk.tsukuba.ac.jp> wrote:
Arte Chambers via Mailman-users writes:
Hello I need help troubleshooting a problem with MM. The service is stopping
If you mean the message quoted below, the Mailman daemons are not stopping. You need to check the "Active", "Main PID", and "CGroup" fields of "systemctl status mailman3.service", or run "mailman status" directly to determine if Mailman is actually running properly or not.
and throwing this error in the mailman log "Exception in the HyperKitty archiver: 413 Request Entity Too Large"
I think a similar issue was reported last week, and Mark is more familiar with it. I seem to remember that it's possible that the message in question is a spam and has non-ASCII characters in the header or body of the message, which violates the email RFCs. Maybe if you move the oldest message in $var_dir/queue/archive (or maybe $var_dir/archiver/hyperkitty/spool) to $var_dir/queue/bad for later inspection things will start running again.
System CTL has this message and i'm not sure if it's relevant to the issue.
sudo systemctl status mailman3.service systemd[1]: mailman3.service: Can't open PID file /opt/mailman/mm/var/master.pid (yet?) after start: No such file or directoryThis isn't relevant. The initial 'mailman' process spawns a 'master' process then shuts down. 'master' takes enough time to get rolling that systemd can't find its pid file when 'mailman' shuts down, and systemd is too impatient to wait. That snippet is taken from the systemd journal, and does not reflect current status.
The MM Service will run for a while then shuts down.
This is probably normal, as explained above, unless you mean that "systemctl status mailman3.service" or "mailman status" reports that Mailman is not running. That should have some explanation in $log_dir/mailman.
Steve
The output from systemctl status after mailman has failed
~$ sudo systemctl status mailman3.service
× mailman3.service - GNU Mailing List Manager
Loaded: loaded (/etc/systemd/system/mailman3.service; enabled; preset:
enabled)
Active: failed (Result: oom-kill) since Thu 2025-01-30 17:00:27 UTC;
1h 24min ago
Duration: 33min 59.427s
Process: 1228 ExecStart=/opt/mailman/venv/bin/mailman start
(code=exited, status=0/SUCCESS)
Process: 2509 ExecStop=/opt/mailman/venv/bin/mailman stop (code=killed,
signal=TERM)
Main PID: 1253 (code=killed, signal=KILL)
CPU: 29.751s
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]: File
"/usr/lib/python3.12/logging/__init__.py", line 1700, in handle
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]:
self.callHandlers(record)
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]: File
"/usr/lib/python3.12/logging/__init__.py", line 1762, in callHandlers
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]:
hdlr.handle(record)
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]: File
"/usr/lib/python3.12/logging/__init__.py", line 1028, in handle
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]:
self.emit(record)
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]: File
"/opt/mailman/venv/lib/python3.12/site-packages/mailman/core/logging.py",
line 85, in emit
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]:
self.handleError(record)
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]: Message:
'out runner caught SIGTERM. Stopping.'
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]:
Arguments: ()
Thank you, Paul 'Arte Chambers' Robey 502-408-6922
On Thu, Jan 30, 2025 at 1:22 PM Arte Chambers <paul.m.robey@gmail.com> wrote:
and throwing this error in the mailman log "Exception in the HyperKitty archiver: 413 Request Entity Too Large"
I think a similar issue was reported last week, and Mark is more familiar with it. I seem to remember that it's possible that the message in question is a spam and has non-ASCII characters in the header or body of the message, which violates the email RFCs. Maybe if you move the oldest message in $var_dir/queue/archive (or maybe $var_dir/archiver/hyperkitty/spool) to $var_dir/queue/bad for later inspection things will start running again.
There is only 1 .pck file in $var_dir/archiver/hyperkitty/spool and it is only 3.5M - Is there a way I can see what this pck file is?
Thank you, Paul 'Arte Chambers' Robey 502-408-6922
On Thu, Jan 30, 2025 at 12:09 PM Stephen J. Turnbull < turnbull@sk.tsukuba.ac.jp> wrote:
Arte Chambers via Mailman-users writes:
Hello I need help troubleshooting a problem with MM. The service is stopping
If you mean the message quoted below, the Mailman daemons are not stopping. You need to check the "Active", "Main PID", and "CGroup" fields of "systemctl status mailman3.service", or run "mailman status" directly to determine if Mailman is actually running properly or not.
and throwing this error in the mailman log "Exception in the HyperKitty archiver: 413 Request Entity Too Large"
I think a similar issue was reported last week, and Mark is more familiar with it. I seem to remember that it's possible that the message in question is a spam and has non-ASCII characters in the header or body of the message, which violates the email RFCs. Maybe if you move the oldest message in $var_dir/queue/archive (or maybe $var_dir/archiver/hyperkitty/spool) to $var_dir/queue/bad for later inspection things will start running again.
System CTL has this message and i'm not sure if it's relevant to the issue.
sudo systemctl status mailman3.service systemd[1]: mailman3.service: Can't open PID file /opt/mailman/mm/var/master.pid (yet?) after start: No such file or directoryThis isn't relevant. The initial 'mailman' process spawns a 'master' process then shuts down. 'master' takes enough time to get rolling that systemd can't find its pid file when 'mailman' shuts down, and systemd is too impatient to wait. That snippet is taken from the systemd journal, and does not reflect current status.
The MM Service will run for a while then shuts down.
This is probably normal, as explained above, unless you mean that "systemctl status mailman3.service" or "mailman status" reports that Mailman is not running. That should have some explanation in $log_dir/mailman.
Steve
Arte Chambers via Mailman-users writes:
The output from systemctl status after mailman has failed
~$ sudo systemctl status mailman3.service × mailman3.service - GNU Mailing List Manager Loaded: loaded (/etc/systemd/system/mailman3.service; enabled; preset: enabled) Active: failed (Result: oom-kill) since Thu 2025-01-30 17:00:27 UTC;
Ah, yes, that is as dead as the Monty Python parrot. How much memory and swap does the system have? (Note, you probably don't want to be using swap at all most of the time, this is to understand the "killed because the system ran out of free memory" oom-kill message.)
For comparison, I found that OOM kills were fairly frequent (~ once in 1-3 days) on a Digital Ocean droplet with 2GB of memory, and there was a dramatic reduction but not an elimination of OOM kills when I bumped it to 4GB. The two active apps were Mailman and Mediawiki, plus whatever Digital Ocean likes to run on its standard droplets.
Steve
I updated the number of runners in hyperkitty to 9 a couple days ago to address a problem I was having with custom templates per this thread <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/M...>. I reduced this to 2 workers and so far it seems to have resolved the problem. Thanks again for everyone's help. The Mailman community gets an A+ for its treatment of noobs!
Thank you, Paul 'Arte Chambers' Robey 502-408-6922
On Fri, Jan 31, 2025 at 2:44 AM Stephen J. Turnbull < turnbull@sk.tsukuba.ac.jp> wrote:
Arte Chambers via Mailman-users writes:
The output from systemctl status after mailman has failed
~$ sudo systemctl status mailman3.service × mailman3.service - GNU Mailing List Manager Loaded: loaded (/etc/systemd/system/mailman3.service; enabled; preset: enabled) Active: failed (Result: oom-kill) since Thu 2025-01-30 17:00:27 UTC;Ah, yes, that is as dead as the Monty Python parrot. How much memory and swap does the system have? (Note, you probably don't want to be using swap at all most of the time, this is to understand the "killed because the system ran out of free memory" oom-kill message.)
For comparison, I found that OOM kills were fairly frequent (~ once in 1-3 days) on a Digital Ocean droplet with 2GB of memory, and there was a dramatic reduction but not an elimination of OOM kills when I bumped it to 4GB. The two active apps were Mailman and Mediawiki, plus whatever Digital Ocean likes to run on its standard droplets.
Steve
Arte Chambers via Mailman-users writes:
There is only 1 .pck file in $var_dir/archiver/hyperkitty/spool and it is only 3.5M - Is there a way I can see what this pck file is?
That file would be related to the response. The *request* in the HyperKitty protocol is going to be much smaller. I believe the normal upper limit is 4kB. The previous report raised the limit on the request to 16kb or maybe 64kB, but then ran into a different problem. None of these numbers should be big enough to cause consistent OOM conditions unless your memory is truly tiny.
To view the file content, su to mailman, activate the virtual environment if you are using one, and type
mailman qfile $var_dir/archiver/hyperkitty/spool/xxxx-xxxx.pck(with the correct name for the qfile, of course). mailman qfile -h will give you help, but IIRC qfile is one of the simplest subcommands: '-h' may be the only option it takes.
There are two parts to the output. The first is the Message object flattened to an RFC 822 message file. The second is a mapping of metadata that gives hints about what Mailman was doing with the file.
Steve
Thanks, this was helpful. It was a message I sent to the list that was just an image attachment with no body text. I noticed this other thread about messages with attachments, without text discarded silently <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/E...>. I am attaching the pickle file hoping that it helps anyone researching this issue.
Thank you, Paul 'Arte Chambers' Robey 502-408-6922
On Fri, Jan 31, 2025 at 2:55 AM Stephen J. Turnbull < turnbull@sk.tsukuba.ac.jp> wrote:
Arte Chambers via Mailman-users writes:
There is only 1 .pck file in $var_dir/archiver/hyperkitty/spool and it is only 3.5M - Is there a way I can see what this pck file is?
That file would be related to the response. The *request* in the HyperKitty protocol is going to be much smaller. I believe the normal upper limit is 4kB. The previous report raised the limit on the request to 16kb or maybe 64kB, but then ran into a different problem. None of these numbers should be big enough to cause consistent OOM conditions unless your memory is truly tiny.
To view the file content, su to mailman, activate the virtual environment if you are using one, and type
mailman qfile $var_dir/archiver/hyperkitty/spool/xxxx-xxxx.pck(with the correct name for the qfile, of course). mailman qfile -h will give you help, but IIRC qfile is one of the simplest subcommands: '-h' may be the only option it takes.
There are two parts to the output. The first is the Message object flattened to an RFC 822 message file. The second is a mapping of metadata that gives hints about what Mailman was doing with the file.
Steve
Mailman's content filtering has removed the following MIME parts from this message.
Replaced multipart/alternative part with first alternative.
On 1/31/25 11:01, Arte Chambers via Mailman-users wrote:
Thanks, this was helpful. It was a message I sent to the list that was just an image attachment with no body text. I noticed this other thread about messages with attachments, without text discarded silently <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/E...>. I am attaching the pickle file hoping that it helps anyone researching this issue.
I think the underlying issue is the same as in that thread. While your message has mime structure
multipart/mixed multipart/alternative text/plain <- empty text/html image/jpeg
If you have content filtering Collapse alternatives = yes, it will become
multipart/mixed text/plain <- empty image/jpeg
after collapsing alternatives and that will trigger the error. See https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/... for a patch (not yet tested) that I think will fix this.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
If you have content filtering Collapse alternatives = yes, it will become
multipart/mixed text/plain <- empty image/jpeg
after collapsing alternatives and that will trigger the error. See https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/... for a patch (not yet tested) that I think will fix this.
I don't think that's the best we can do, though. Especially if Convert HTML to plain is also yes, we want to preserve the HTML part and convert it, don't we? I think a better (or additional) strategy would be to check the selected alternative for blank, and if so, drop it and try again for an appropriate type.
Steve
On 1/31/25 21:44, Stephen J. Turnbull wrote:
I don't think that's the best we can do, though. Especially if Convert HTML to plain is also yes, we want to preserve the HTML part and convert it, don't we?
Not if we're collapsing alternatives. If we're collapsing a multipart/alternative part with text/plain and text/html alternatives to just the first alternative we don't keep the text/html part.
The only html parts we keep and possibly convert to plain text are ones that aren't a second or later alternative in a multipart/alternative part.
I think a better (or additional) strategy would be to check the selected alternative for blank, and if so, drop it and try again for an appropriate type.
The collapsing of a two part multipart message with an empty first part into a single part message with just the second part is the last thing that's done after all other content filtering.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
Not if we're collapsing alternatives. If we're collapsing a multipart/alternative part with text/plain and text/html alternatives to just the first alternative we don't keep the text/html part.
I understand that's what we currently do. But I think that when the MUA provides an empty plain text part and a non-null HTML part, that's a mark of lazy MUA developers, not author intent. I think that it's very likely that the author would prefer the reader get converted HTML rather than a blank.
Of course if the list owner wants to inhibit conversion, that's fine. But I would expect that list owners who enable conversion would also want to present a converted alternate rather than the blank plain text.
Steve
participants (3)
-
Arte Chambers -
Mark Sapiro -
Stephen J. Turnbull