Thus said Stephen Gildea on Mon, 04 Nov 2024 20:50:12 -0800: > https://savannah.nongnu.org/bugs/?66407 describes a case I > found in the POP client that fails on long lines.
If by POP client you mean inc, this is a known issue that I reported years ago. I have a proposed patch for this situation, however, it's less than ideal and so I run the code locally and it has not yet been added to nmh proper. You're more than welcome to try at your own risk the patch that I've proposed. :-) If you're interested in catching up on the subject: https://lists.nongnu.org/archive/html/nmh-workers/2024-04/msg00003.html By the way, I'm still pursuing the contacting of the agency responsible for sending such garbage, but so far my squeeking isn't drawing any attention. I'm interested in the particulars of what is sending such large lines in your emails. Is it improperly formatted base64 data? Who is responsible for "Excessively long lines appear in some delivery-confirmation messages."? Can you share the structure (if not an actual message) of such an email? In my case, I had an email that had a single line that was 10 million characters long before hitting a LF character. Per RFC 5321 4.5.3.1.6 a line MUST not exceed 1000 octets (including CRLF). Per RFC 5322 2.1.1 Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. So whoever is sending you this should be notified. Good luck. Andy
