Use of rtrim before encryption introduces blank line in headers when header contains lines with only whitespace characters

[alexaka1]

I have setup an alias to a GOG account, and I forward it to an email. Encryption is turned on, although I don't think it matters (I have disabled encryption for now, but GOG is yet to send the next newsletter).

When I receive the email it contains a partial header in the body, and then the email html is included as multipart/mixed content-type.
The email header contains a List-Unsubscribe key and the value contains a new line with 2 spaces.

List-Unsubscribe: <mailto:[email protected]?subject=redacted>,
  
 <https://gog.salesmanago.com/optOut.htm?uid=redacted&sec=redacted&conversation=redacted&optOutLanguage=en&auto=true>

The email body that I see in the client starts exactly after the new line, and contains the <url> and the the remaining part of the header.

I have enabled a different mail client as the forward address to see if this is a provider issue, as well as disabled encryption, to see if decryption goes wrong (also unlikely). I will update the post if a new email is sent out.
2FA emails from GOG don't contain a List-Unsubscribe, and are rendered correctly (even with encryption).

I have sent you two sample emails for investigation.

Edit: When encryption is off, the email is correctly handled by both providers, despite having the same header with the line-break. Interesting...

[alexaka1]

Since then I have concluded that only the encrypted messages are messed up.
I have looked at the code and I think this code introduces a completely empty line in the email headers, because of the original header containing a line with 2 spaces.

anonaddy/app/CustomMailDriver/Mime/Crypto/OpenPGPEncrypter.php

Line 143 in 045e82b

$lines[$i] = rtrim($lines[$i])."\r\n";

And since at this point the email is provided as is to gnupg for encryption, I looked for RFC-5322:

The body is simply a sequence of
characters that follows the header section and is separated from the
header section by an empty line (i.e., a line with nothing preceding
the CRLF).

So because GOG sends this strange header, AnonAddy cleans this up, but ends up introducing a bug, by inserting a blank line into the headers, which then gets interpreted as start of body by gnupg email parser.

So that was a rabbithole 🙂

I don't have an immediate solution to this, other than GOG smgrid.pl should not compose their headers in such a way. While their header is valid, according to the spec (there are characters before crlf), it makes no sense why it is composed in such a way.