Subject: bug#10080: 23.3; Rmail shows an extra blank line at the end when displaying a non-MIME message

From: Eli Zaretskii <[email-masked]>
Date: Mon, 26 Sep 2022 10:48:10 +0300

> From: Mark Lillibridge <[email-masked]>
> Date: Sun, 25 Sep 2022 09:36:27 -0700
> 
>     I'm attaching a *mbox* file (this is the format used by rmail),
> lightly edited from one of my older rmail files to hide email addresses.
> It has two messages, the first with zero blank lines at the end and last
> with 2 blank lines at the end.  If you find file it then do M-x
> rmail-mode and look at the first message, you will see that it has an
> extra blank line at the end when displayed.  The last one doesn't.  (go
> to the end of message with esc > or turn on line numbering to see where
> the displayed message ends.)
> 
>     If you look at the rmail file before doing rmail-mode, you can see
> the underlying formatting.  You will see a blank line between the first
> and second message; this is part of the mbox formatting, not a part of
> either message.
> 
> from https://en.wikipedia.org/wiki/Mbox
>     The mbox format uses a single blank line followed by the string 'From '
>     (with a space) to delimit messages; this can create ambiguities if a
>     message contains the same sequence in the message text.
> 
> (The original reproduction instructions probably no longer work because
> it's actually quite hard to send a message that's not using MIME these
> days.)
> 
>     To add insult to injury, if you attempt to forward the message, Rmail
> will include the spurious blank line in the message it forwards.  I hit
> 'f' for this in emacs28.1 -q and get a # part with the blank line before
> the closing tag.

Can you explain why this is a problem?  That is, why does it matter
that a message, as shown in the Rmail reading buffer, has extra empty
lines at the end?  I use Rmail all the time, and know about these
extra empty lines, but they never bother me, because I don't need to
read empty lines.  And forwarding a message with an extra empty line
also should not cause any trouble on the receiving end.

So I'm not sure we should do anything with this bug.