inc(1) Losing 8,192 Bytes of Body.

[Ralph Corderoy]

Hi,

I think this has been seen before.  I'm writing to point out it's still
about as of

    $ inc -version
    inc -- nmh-1.7+dev 1.7-branchpoint-573-g248c3a45-dirty built
    2019-12-09 13:02:37 +0000 on orac

fetchmail ran as normal.

    reading message ralph@...@...:8 of 8
        (2914 header octets) (11671 body octets) flushed

2,914 + 11,671 = 14,585.

Postfix, he say

    postfix/qmgr[471]: 0C38E202DA: from=<address@hidden>,
        size=14933, nrcpt=1 (queue active)

14,933 - 14,585 = 348.  I'd infer that's the number of CR stripped less
an extra header or two.

inc didn't grumble.

    80859  02-27  "TI E2E support   Wi-Fi forum: LAUNCHCC3220MODASF

But the file in +inbox is corrupt.

    $ wc `mhpath .`
     102  319 6609 /home/ralph/mail/inbox/80859
    $ mhlist -nov
    mhlist: bogus multipart content in message 80859
     msg part  type/subtype              size description
    80859       multipart/alternative     3286
    $ 

14,933 - 6,609 = 8,324.  Suspiciously a bit over 8 Ki.

Around the line ending the headers:

    Content-Type: multipart/alternative;
            boundary="-=_ANM000_=-a066ed063f0e4a2ebf993b1cfbd3c7f6"
    X-OriginalArrivalTime: 27 Feb 2020 14:16:01.0702 (UTC) 
FILETIME=[70868460:01D5ED78]

    eWxl
    PSJjb2xvcjojODAwMDgwO2ZvbnQtZmFtaWx5OmNvbWljIHNhbnMgbXMsc2Fucy1zZXJp

The stated boundary is present only at the end.

    $ tail -4 `mhpath .`
    MGJjNWNhNmEiIC8+PC9kaXY+PC90ZD4KPC90cj4KPC90Ym9keT4KPC90YWJsZT4KPC90
    ZD4KPC90cj4KPC90Ym9keT4KPC90YWJsZT4NCjwvYm9keT48L2h0bWw+
    ---=_ANM000_=-a066ed063f0e4a2ebf993b1cfbd3c7f6--

    $ 

And that base64 at the start of the body is starting part-way through
content if I decode it.

    $ base64 -d <<<'eWxlPSJjb2xvcjojODAwMDgwO2Zv'; echo
    yle="color:#800080;fo

So I think the inc I'm running still has problems around its sliding
buffer code in the header parsing.

-- 
Cheers, Ralph.