Autoresponder - Carriage Return Yields Double Line Break
I have tried this with multiple users/accounts. They all do the same thing. Each carriage return adds 2 new lines as seen below.
Here are the settings:
Here is the appearance in Outlook:
-
Found the same problem, and it's still definitely a bug.
In `text/plain` emails, it inserts `=0D` for the line break, but also includes an actual line break, resulting in the duplicate. The `Content-Transfer-Encoding` is `quoted-printable`. It should end each line of the 'encoded' content with `=` to suppress the literal line feed, but does not.
A workaround is to select 'This message contains HTML' and maybe insert some `<p>` tags.0 -
jakeqz - I'm not sure why this didn't get a reply the first time, but I'll test this now and let you know what I find!
0 -
I created an autoresponder with this in the body:
and I confirmed this does happen within Outlook but NOT other tools like Gmail or Yahoo. Unfortunately this is just how different software handles the line breaks and not something we can control. If we "fixed" it in one version, it would cause issues for the others.
You can see the code is the same in all locations by viewing the source message, which looks like this:
This is the first line=0D
=0D
This is the second line=0D
=0D
This is the third line=0Dand Outlook has chosen to handle them this way.
My only recommendation is to use the workaround you've already found for this.
0 -
The extra line breaks also appear with Thunderbird and the Webatic decoder.
According to RFC 2045, "A line break in a text body, represented as a CRLF sequence in the text canonical form, must be represented by a (RFC 822) line break, which is also a CRLF sequence, in the Quoted-Printable encoding."
The `=0D` is an encoded CR - i.e. a Macintosh line ending. I think what Google and Yahoo (and also Roundcube) are doing is rendering the hard line break but ignoring the encoded CR, whereas the others are treating the encoded CR as an additional line break.
Therefore I think this can and should be fixed to work on all systems, by eliminating the `=0D` which has no clearly-defined behaviour and is not necessary.
0 -
I confirmed that removing the spurious `=0D`s resolves the problem with Thunderbird and does not break Gmail. Therefore I think that is the fix. (I already posted a reply to that effect but it has disappeared. Note that the previous post with more information, citing RFC 2045 is currently pending approval.)
0 -
Not disappeared, just flagged for moderation.
I don't think we can completely remove that encoding as it has to have *something* to show the line break, but it seems to be up to each application to decide how they interpret it.
0 -
it has to have *something* to show the line break
Yes. An actual line break - CR LF - as defined by RFC 2045. If physical line breaks should not be included in the rendered text, "'soft' line breaks must be used. An equal sign as the last character on a encoded line indicates such a non-significant ('soft') line break in the encoded text."
The `=0D` looks to be anti-spec and should not be there, particularly as it lacks a LF (`=0A`). The spec clearly states that line breaks are to be included in the text unless preceded by a single equals character (`=`).0 -
Ah, I gotcha - I only saw the top half of that longer message when I approved it.
I've opened case CPANEL-51015 for our team to investigate changing this option. It's always possible there was an obscure reason that =0D was chosen years ago, but it never hurts to ask if we can improve things.
I've also linked this thread to this case so if I hear an update on my end I'll be sure to post!
1
Please sign in to leave a comment.
Comments
8 comments