Thank you for pointing me at the history of this problem, Andy.
Doubling the size of the buffer would solve my particular
problem. But it seems that to be really robust in today's
world, we need to be able to handle an arbitrarily long
sequence of bytes without line breaks.
In the discussion of 29 Nov 2022, it looks like Andy has a
patch but no test. In my bug report, I provide a test (which
fails against HEAD, as it should). Can we put these two parts
together?
My test does not verify that the long line was passed through
without truncation. If we're going to go forward with this, I
will enhance the test to do that.
Andy asks who sends my troublesome messages. They are from
UPS (ups.com). I've gotten "Your UPS Package was delivered"
messages for years, but it is new this year that they include
a picture of the package as delivered.
I'm sure I have no hope of convincing UPS that their mail
system is broken, so I have not tried. UPS out-weighs me. A
more successful way of applying pressure would be to convince
one of the big email providers (the size of, say, Gmail) into
refusing poorly formatted messages at the SMTP level.
The MIME structure I get looks like this:
$ mhlist
msg part type/subtype size description
33 multipart/related 81K
1 text/html 33K
2 image/jpeg 36K
(Notice no text/plain alternative, which I don't like, either.)
The MIME headers look like this:
From: "UPS" <[email protected]>
Subject: Your UPS Package was delivered
MIME-Version: 1.0
Content-Type: multipart/related; boundary=----NextPart_1730848396684.0002037473
Date: Tue, 5 Nov 2024 18:13:16 -0500 (EST)
------NextPart_1730848396684.0002037473
Content-Type: text/html; charset=UTF-8
... [longest line: 1334 bytes]
------NextPart_1730848396684.0002037473
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
Content-ID: <deliveryPhoto>
MIME-Version: 1.0
Content-Disposition: inline
[48020 base64 bytes, no CRLF]
------NextPart_1730848396684.0002037473--
