Re: [Mutt] #714: Lines starting From aren't escaped saving from Maildir to mbox
#714: Lines starting From aren't escaped saving from Maildir to mbox
Comment (by vinc17):
Replying to [comment:19 rtc]:
> In fact, I only know exactly one mbox based format, the mboxcl format,
where this is the case. It has several severe flaws: Any reader that does
not know this sick convention will wreak havoc in such mailboxes;
This is not a flaw. Mutt supports the Content-Length header, so, no
problem for me. At least this doesn't corrupt the message ("From " quoting
is particularly evil when it occurs in an attachment).
> the delivery program needs to take care of incoming mails that already
have Content-Length headers; if your delivery program doesn't (which is
common, you mentioned procmail, postfix and exim which don't take care of
that, I suppose), you get serious problems if you get a remote message
with tampered Content-Length headers etc.
I've never seen any problem in practice (but I switched to maildir for
incoming mail a few years ago). Also, nowadays most users use filters
(mainly because of spam), and it's really easy to remove the Content-
Length header. Ditto for the Status header.
Also, without Content-Length, the mailer would be very inefficient on
large mailboxes.
> There is no such thing as "the expected format" of a "line starting with
'From'".
See the is_from function in from.c.
> If your mbox variety requires From_ quoting, you should quote any line
starting with "From ", and you should assume that any line starting with
"From " is a message separator. You complicate matters endlessly and
create many unnecessary new problems if you try to use such a seemingly
more "sophisticated" approach.
Instead of dealing with theory that doesn't match the practice, Mutt tries
to solve practical problems. And it does it well.
> > Mutt does this check when reading a mailbox (if the Content-Length is
either incorrect or missing).
>
> It shouldn't. If you ever have a message inside a mboxcl format mailbox
that lacks appropriate Content-Length, and it contains an unquoted From_,
something went horribly wrong.
In any case, I think this is fine that Mutt has some recovering
mechanisms.
> This is correct. However, your initial statement was "No, this is not
the format supported by most software" What is problematic about mboxrd
not being this format? Whether you choose to assume mboxo or mboxrd on a
mailbox written in the format supported by most software (that writes
mailboxes), and this format is mboxo, you will never in all cases be able
to unambiguously reconstruct the original message.
But assuming mboxo leads to the correct result most of the time.
> And one major MTA, qmail, has switched to mboxrd, so if you assume
mboxrd, you will at least have a clean solution for this case.
qmail uses maildir by default (IIRC, this was the format introduced by
qmail).
> You are talking about the mboxcl format above. This is by far not the
format supported by most software, either.
It is supported by Mutt, and this is sufficient for most Mutt users.
> A From_ always needs to be quoted except if you assume mboxcl format,
Not all of them.
> in which case you need to assume mboxcl, not mboxo, on reading the
mailbox,
In practice, one can have mixed-form of mailboxes.
> Assuming mboxo format will never lead to fewer message corruptions
compared to assuming the mboxrd format. Of course you can always construct
specific examples where assuming the mboxrd format will corrupt the
message worse than assuming mboxo would. But these cases are very rare in
real world amd are never fatal.
No, they are common and annoying.
> Information is lost in mboxcl format, too, because if you want to write
a mail in that format, you need to overwrite already existing Content-
Length headers, apart from the other problems I mentioned.
No information is lost. Content-Length is just meta-data.
> If I am talking about corruption, I am talking about what happens to the
infinity of possible messages, not any specific subset of them.
I really don't mind about your infinity of possible messages. Not all
possible messages occur in practice. You model is wrong, as well as your
deductions.
--
Ticket URL: <http://dev.mutt.org/trac/ticket/714#comment:20>