[GH-ISSUE #525] Use of rtrim before encryption introduces blank line in headers when header contains lines with only whitespace characters #950

New issue

Open

opened 2026-03-14 11:17:14 +03:00 by kerem · 1 comment

kerem commented

2026-03-14 11:17:14 +03:00

Owner

Originally created by @alexaka1 on GitHub (Sep 22, 2023).
Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/525

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:unsubscribe+redacted@emsgrid.com?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...

Originally created by @alexaka1 on GitHub (Sep 22, 2023). Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/525 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:unsubscribe+redacted@emsgrid.com?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...

kerem commented

2026-03-14 11:17:21 +03:00

Author

Owner

@alexaka1 commented on GitHub (Sep 24, 2023):

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.

github.com/anonaddy/anonaddy@045e82bae8/app/CustomMailDriver/Mime/Crypto/OpenPGPEncrypter.php (L143)

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.

@alexaka1 commented on GitHub (Sep 24, 2023): 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. https://github.com/anonaddy/anonaddy/blob/045e82bae8ec559e41274e3d8f286807376492b4/app/CustomMailDriver/Mime/Crypto/OpenPGPEncrypter.php#L143 And since at this point the email is provided as is to gnupg for encryption, I looked for [RFC-5322](https://www.rfc-editor.org/rfc/rfc5322#section-2.1): > 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.

No labels

bug

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/anonaddy#950

No description provided.

Rows
Columns