Hello,
This is the first time I've ever seen such an error from inc. In looking
at the message that is causing the problem, apparently it's a MIME
message that has a base64 encoded MIME body that is all on one line that
even sed has a hard time parsing:
$ time (cat bigmessage | sed -ne '62p' | wc)
1 1 11370773
1m08.62s real 0m15.01s user 0m23.09s system
This just seems ridiculous. I'm tempted to modify my SMTP server to
reject such messages, but I'm curious to know if this is simply a bug in
the sending software or if something has changed?
Unfortunately, I cannot share the entire message, but I'm not sure I
need to. It should be easily reproduced by simply base64 encoding a
large file and putting it all on one line. Here are the redacted MIME
headers:
------=_Part_8167195_1805258438.1568043535371
Content-Type: application/octet-stream;
name="attachment.eml"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="attachment.eml"
Is this something I should report to the sender as a clear violation of
RFC5322, which as far as I can tell, restricts line lengths to 998
characters, or is there something special about MIME that supersedes the
limit and which means inc needs fixing?
Thanks,
Andy
--
TAI64 timestamp: 400000005d76af72
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers