Request Entity Too Large
Now mail sent to mm3 for distribution is not going out, for two different lists. The mailman.log shows this error:
Oct 17 21:50:00 2021 (491) ACCEPT: <030601d7c3a0$ee342f20$ca9c8d60$@somedomain.com> Oct 17 21:50:04 2021 (488) HyperKitty failure on https://somedomain.net/archives/api/mailman/archive: <html> <head><title>413 Request Entity Too Large</title></head> <body bgcolor="white"> <center><h1>413 Request Entity Too Large</h1></center> <hr><center>nginx/1.14.2</center> </body> </html> (413) Oct 17 21:50:04 2021 (488) Exception in the HyperKitty archiver: <html> <head><title>413 Request Entity Too Large</title></head> <body bgcolor="white"> <center><h1>413 Request Entity Too Large</h1></center> <hr><center>nginx/1.14.2</center> </body> </html> Oct 17 21:50:04 2021 (488) Traceback (most recent call last): File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman_hyperkitty/__init_ _.py", line 154, in _archive_message url = self._send_message(mlist, msg) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman_hyperkitty/__init_ _.py", line 210, in _send_message raise ValueError(result.text) ValueError: <html> <head><title>413 Request Entity Too Large</title></head> <body bgcolor="white"> <center><h1>413 Request Entity Too Large</h1></center> <hr><center>nginx/1.14.2</center> </body> </html>
Please advise. TY.
-----Original Message----- From: Mark Sapiro <mark@msapiro.net> Sent: Saturday, October 16, 2021 11:21 AM To: mailman-users@mailman3.org Subject: [MM3-users] Re: FW: [Django] ERROR (EXTERNAL IP): Internal Server Error: /user-profile/
On 10/16/21 9:52 AM, Christian Stalberg via Mailman-users wrote:
When I go to https://.../admin/ I get a Django Administration screen and in the upper right hand corner I see
WELCOME, <username>. VIEW SITE / CHANGE PASSWORD / LOG OUT
And my point was if you go to Users under Authentication and Authorization you should find that alekos.pantazis is a user.
If you go to your own https://www.grizz.org/user-profile/ page, do you see a gravatar to the right of the Username, First name, Last name boxes, and does going there produce the same error in the logs. If that's all OK, then I don't know what produced the original error, but I think you can ignore it. If that produces the same error in the logs, then something is wrong with your django-mailman3 installation, but I don't know what.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
Christian Stalberg via Mailman-users writes:
Now mail sent to mm3 for distribution is not going out, for two different lists.
Check whether stuff is stuck in your MTA queue, and your MTA logs. Also check Mailman's queues (usually in /var/lib/mailman/qfiles, I think).
As for why it's two different lists, is it possible that somebody cross-posted to those lists, or one is subscribed to the other?
The mailman.log shows this error:
Oct 17 21:50:00 2021 (491) ACCEPT: <030601d7c3a0$ee342f20$ca9c8d60$@somedomain.com> Oct 17 21:50:04 2021 (488) HyperKitty failure on https://somedomain.net/archives/api/mailman/archive: <html>
I don't think this should affect mail going out in itself, because this appears to be delivery to HyperKitty, not to any remote host. Why nginx is involved is a mystery to me, though.
<head><title>413 Request Entity Too Large</title></head> <body bgcolor="white"> <center><h1>413 Request Entity Too Large</h1></center> <hr><center>nginx/1.14.2</center> </body> </html> (413) Oct 17 21:50:04 2021 (488) Exception in the HyperKitty archiver: <html> <head><title>413 Request Entity Too Large</title></head> <body bgcolor="white"> <center><h1>413 Request Entity Too Large</h1></center> <hr><center>nginx/1.14.2</center> </body> </html>
It appears that nginx is complaining that a request from HyperKitty is too large. I don't know much about nginx, but usually a request is sent FROM a client TO an HTTPd, and it's saying it's too big. I guess if nginx is the front end for HyperKitty, it could be that some client is requesting a huge email from HyperKitty.
I guess you could have nginx between Mailman core and HyperKitty, in which case this is apparently an nginx configuration issue: it has an upper limit on the size of messages it's willing to accept from core and pass on to HyperKitty.
If your Mailman is getting messages large enough that an HTTPd balks, I wouldn't be surprised if your MTA is on strike, or is getting "you gotta be kidding, I'm too busy, try tomorrow" from remote recipients.
It could be a Mailman problem, but there's nothing in your report to suggest that it is.
I went into nginx.conf and raised the client_max_body_size from the default 1M to 0, then restarted nginx. The '413 Request Entity Too Large' error has gone away, but postings to the list are not distributed. The mail queue is empty. Now what?
-----Original Message----- From: Stephen J. Turnbull <stephenjturnbull@gmail.com> Sent: Tuesday, October 19, 2021 7:20 AM To: Christian Stalberg <csa@web-analysts.net> Cc: mailman-users@mailman3.org Subject: [MM3-users] Request Entity Too Large
Christian Stalberg via Mailman-users writes:
Now mail sent to mm3 for distribution is not going out, for two > different lists.
Check whether stuff is stuck in your MTA queue, and your MTA logs. Also check Mailman's queues (usually in /var/lib/mailman/qfiles, I think).
As for why it's two different lists, is it possible that somebody cross-posted to those lists, or one is subscribed to the other?
The mailman.log shows this error:
Oct 17 21:50:00 2021 (491) ACCEPT: <030601d7c3a0$ee342f20$ca9c8d60$@somedomain.com> Oct 17 21:50:04 2021 (488) HyperKitty failure on > https://somedomain.net/archives/api/mailman/archive: <html>
I don't think this should affect mail going out in itself, because this appears to be delivery to HyperKitty, not to any remote host. Why nginx is involved is a mystery to me, though.
<head><title>413 Request Entity Too Large</title></head> > <body bgcolor="white"> > <center><h1>413 Request Entity Too Large</h1></center> <hr><center>nginx/1.14.2</center> > </body> > </html> > (413) > Oct 17 21:50:04 2021 (488) Exception in the HyperKitty archiver: <html> > <head><title>413 Request Entity Too Large</title></head> > <body bgcolor="white"> > <center><h1>413 Request Entity Too Large</h1></center> <hr><center>nginx/1.14.2</center> > </body> > </html>
It appears that nginx is complaining that a request from HyperKitty is too large. I don't know much about nginx, but usually a request is sent FROM a client TO an HTTPd, and it's saying it's too big. I guess if nginx is the front end for HyperKitty, it could be that some client is requesting a huge email from HyperKitty.
I guess you could have nginx between Mailman core and HyperKitty, in which case this is apparently an nginx configuration issue: it has an upper limit on the size of messages it's willing to accept from core and pass on to HyperKitty.
If your Mailman is getting messages large enough that an HTTPd balks, I wouldn't be surprised if your MTA is on strike, or is getting "you gotta be kidding, I'm too busy, try tomorrow" from remote recipients.
It could be a Mailman problem, but there's nothing in your report to suggest that it is.
Christian Stalberg via Mailman-users writes:
I went into nginx.conf and raised the client_max_body_size from the default 1M to 0, then restarted nginx. The '413 Request Entity Too Large' error has gone away, but postings to the list are not distributed. The mail queue is empty. Now what?
How do you know the posts aren't distributed? If it's posters using Google mail complaining about not seeing their own posts, tell them to look in their Sent Mail folders.
If your HTTPd was configured with a 1MB size limit, how about your MTA(s) and spam/malware filters? Has the mail spool's storage filled up?
What is the mail that is not being delivered? If you configure Mailman to strip HTML, it's possible that the messages were empty after stripping an HTML part, in which case Mailman ignores them. In that case, try switching from strip HTML to convert HTML to plain text, or allow HTML.
Otherwise, what is your MTA software? What mail filters (spam, size limits) are configured into it? What do you know about the affected posters, in particular, what are their systems' DMARC policies?
Is the mail coming from inside your organization and passing through only your MTAs, or are there external MTAs involved? Is Mailman's MTA a boundary MTA (the MTA that talks to systems on the Internet outside your organization)? If not, what is in the logs for the boundary system?
What do Mailman's MTA's logs say? Did the posts get to the MTA from wherever? Does the MTA say Mailman accepted them? Mailman can be a bit spotty about logging success, but errors are not supposed to pass silently -- if there was a failure Mailman knows about it should be logged in the Mailman logs. Then, what does the MTA log say about outgoing mail?
Steve
participants (2)
-
Christian Stalberg -
Stephen J. Turnbull