On Mon, Feb 02, 2026 at 05:09:15AM +0100, Vincent Lefevre wrote: > 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.
Such mailbox corruption can always be detected... doesn't mean the user is educated enough to fix it. Besides, detectability doesn't make it OK. It's still a nuisance to deal with, even if you know how. Note that I'm NOT saying this is worse than the "mboxo" variants... but it's not better either. > > - 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. Again, only "no problems" in the case where the user knows it's happening, why it's happening, AND what to do about it. WE might, but the average user typically wouldn't. > > - An mbox with messages that use multiple mbox* formats that assumes > > the whole mbox is in the first format it detects > > ??? i.e. due to some migration or such, some messages have content-length, some do not, but the MUA only knows about one or the other. This is more of a historical problem since every reasonable modern mailer expects both. Even still, the devil is in the details (i.e. you still have to implement both correctly, including mixed format). > > - 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). But not to fix it. > > - 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. You're awfully quick to use insulting language, Vincent. It makes it really unpleasant to communicate with you. It's not stupid, so much as historical. If you were using an MDA that predates the content-length mutation (or just chose not to care about it), an attacker could add such a header to the outgoing message, and the MDA may well leave it there since it's not special. Then, your MUA that *does* know about it fails. Unlikely to happen now... less so in 1996, probably much less so when content-length was new. > On the opposite, without Content-Length: > * This is very sensitive to what is recognized as a "From " line > (see this discussion). Obviously I'm well aware from the previous discussion. But the more reliable "fix" is simply to use quoted-printable encoding or other such things. > * 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). Right, so do that. All the modern mailers I'm aware of support it, so... just do it. That's why it's there. Again, I'm not saying either mbox variant (or any other) is better--in fact quite the opposite: they all have flaws, and indeed the CL variant is not significantly better. It just trades one set of problems for another, with some intersection between the two. But that, as much as anything, is exactly the problem. Zawinsky's point was that changing the format to try to fix it makes things worse, not better, even if there were some theoretical marginal advantage to the new thing. The older variants were ubiquitous, so now you have TWO problems (or really three): You still have to deal with the old variant for compatibility, and you now have to deal with the quirks and drawbacks of the new variant as well, AND guess which one you need to use on top of that, potentially on a per-message basis. It's the same reason RFC 4155 is bunk. Adding yet another "standard" makes things worse, not better. If anyone took it seriously it would mean every existing mailer would need to implement even more hueristics. Thankfully, absolutely no one does. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
