<<< Date Index >>>     <<< Thread Index >>>

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>