Text blocks, e.g. msg_footer, might not end with linefeed

Bug #1670033 reported by Ralph Corderoy
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Mailman
Mark Sapiro

Bug Description

Mailman 2.1.18-2+deb8u1. msg_footer was edited in the web GUI so the text area limited the cursor to the last line of text; it couldn't move down to a blank line below. The emails comes from Mailman that have this text base64 encoded, and the last line doesn't end with a linefeed, e.g. LS0gCnNpZzAKc2lnMQ==. Mailman should ensure a linefeed is added if one isn't already present, but on using the text block, not editing it so the blank line appears in the GUI as then the user will wonder why they can't remove it.

Related branches

Revision history for this message
Mark Sapiro (msapiro) wrote :

If you position the cursor to the end of the last line, you should be able to press enter/return and add a new line. You should be able to ensure in the web GUI that msg_footer ends with a new-line. If this doesn't work, it would seem to be a browser issue.

The base64 encoding is a Debian modification having to to with their changing Mailman's character set for English (and all other languages) to UTF-8.

Changed in mailman:
status: New → Incomplete
Revision history for this message
Ralph Corderoy (ralph-inputplus) wrote :

Hi Mark, Yes I can add a "blank" line to the end of the text area. My point is, it isn't obvious to the user that they should do this. By doing so they may think, like me, that they're adding an unwanted blank line to the msg_footer, for example. Just as Unix text editors shouldn't produce a text file without a trailing newline, since POSIX mandates a text file is zero or more LF-terminated lines, so I think Mailman has to work around the different UI presented by web-browser text areas and ensure the text it uses from them has a terminating LF.

Thanks for the Debian pointer on the base64. I think other encodings would show the lack of final LF too though, e.g. Quoted-Printable of the above base64:


Revision history for this message
Mark Sapiro (msapiro) wrote :

I'm not sure this won't have negative consequences on people/installations that do automated processing on list messages, but I'm willing to try it.

Changed in mailman:
assignee: nobody → Mark Sapiro (msapiro)
importance: Undecided → Low
milestone: none → 2.1.24
status: Incomplete → Fix Committed
Mark Sapiro (msapiro)
Changed in mailman:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers