Thus said Ken Hornstein on Tue, 10 Sep 2019 09:15:00 -0400:
So how big WAS this message, actually? I'm trying to understand the
scope of the problem.
The entire size of the message on disk (including additional trace
headers added by my MTA) is 11,374,046 while the size of the offending
line is 11,370,773. That means that the rest of the message headers and
text/plain part of the message occupy 3,273 bytes.
Really, I think that the best course of action would be that inc
always tries to write something out (unless it encounters something
like an I/O error) and exits cleanly.
Actually I failed to report that inc *did* write out something. It wrote
out until the MIME content started, so it got up to the headers of the
MIME part and then while trying to scan the next line issued that
error---the resulting file was truncated. I found the problem later when
I was reading messages with EXMH which showed the attachment, but when I
saved the attachment it was a 0 byte file. EXMH must be lenient when it
comes to missing MIME part markers (maybe it just assumes end-of-file is
TAI64 timestamp: 400000005d77a9cf