Re: [PATCH 0/5] Second take at a more lax From_ parser

On 2026-01-30 15:50:08 -0500, Derek Martin wrote:
> On Fri, Jan 30, 2026 at 05:35:48AM +0100, Vincent Lefevre wrote:
> > On 2026-01-29 12:06:36 -0500, Derek Martin wrote:
> > > If the tool were in the middle of making an update to the
> > > content-length, or the actual content, and you had a power
> > > failure, hardware failure, etc.,
> > 
> > Well, such failures are rare and would have to occur at the
> > wrong time.
> 
> This was just an example.  There are a number of other ways it can
> occur that I'm aware of, and probably more that I'm not...
> 
>  - hardware or power failure during update

Can easily be detected, as I've said.

>  - Being processed by a tool that only knows about /the other/ mbox
>    format (i.e. any other)

This is controlled by the user, so no problems.

>  - An mbox with messages that use multiple mbox* formats that assumes
>    the whole mbox is in the first format it detects

???

>  - Moving mbox files between systems with different EOL

Then the Content-Length is a feature in this case as it would
allow one to detect mbox corruption (with munged EOL).

>  - A malicious user inserting an incorrect Content-Length

This is really stupid. A malicious user who can modify the mbox file
can do much worse.

On the opposite, without Content-Length:
  * This is very sensitive to what is recognized as a "From " line
    (see this discussion).
  * If an attachment contains a line starting with "From ", it will
    be corrupted when the message will be stored in a mbox file
    (unless the tool chooses to convert the attachment to QP or
    base64).

-- 
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)