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)
