bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mbox bugs?


From: Kurt Hackenberg
Subject: Re: Mbox bugs?
Date: Tue, 25 Jan 2022 00:06:46 -0500

On Mon, Jan 24, 2022 at 12:00:49PM +0100, Sergey Poznyakoff wrote:

>> ">From ". In this case, it unescaped the first two such lines, but not
>> the third.
>
>Thanks for noticing.  Fixed that in 451ca485d099bd20f2e9cfcb16deea8271df64a5.

Got it, confirmed.

>> And, in the output dotmail file, the message has a blank line added at
>> the end, before the dot line that marks the end of the message.
>
>I wasn't able to reproduce this using git HEAD.


This mbox file

----------------------
>From nobody@nowhere.invalid Thu Jan  1 00:00:00 1970
From: <Joe@Blow.nope>
To: <Alice@FlyingCloud.ship>
Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)

dog

---------------------

produces this dotmail file

----------------------
From: <Joe@Blow.nope>
To: <Alice@FlyingCloud.ship>
Date: Thu, 01 Jan 1970 00:00:00 +0000 (UTC)

dog

.
----------------------

That is incorrect. That blank line after the "dog" line and before the
dot line, should not exist.

The dotmail specification says:

     A message in a dotmail file is NOT preceded by a line like:

          From nobody@nowhere.invalid Thu Jan  1 00:00:00 1970

     and is not followed by a blank line.  Those two lines are a frame
     added by mbox; they are not part of the message.

In mailutils/libproto/mbox/mboxrd.c, a large block comment includes this:

 *  3. The From_ lines and the blank lines bracket messages, fore and aft.
 *     They do not comprise a message divider.  This means, in particular,
 *     that both bracketing lines should be included in the message octet
 *     and line counts.  However, counting the From_ line goes against
 *     the mailutils approach of logically dividing envelope and the rest
 *     of the message and would create useless differences compared to
 *     another mailbox formats.  For this reason, the From_ line is not
 *     reflected in returns from the mu_message_size and mu_message_lines
 *     functions.  The terminating blank line, on the contrary, is assumed
 *     to be part of the message body and is counted in body and message
 *     size and line count computations.

That seems wrong to me; I would think the message stored internally
should be only the RFC 822 message, without either of the two lines
that are added by mbox format.  Of course, mailutils internals are not
really my concern -- but dotmail is.  Dotmail contains only the RFC
822 message.  Specifically, dotmail does not include the blank line
added by mbox format.  The conversion mbox -> dotmail done by movemail
is incorrect.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]