-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[v3] Mail headers are rearranged #321
Comments
Client-side DKIM checks are a lost cause for a number of reasons, it's probably not the header order, it's probably processing that happens when we convert to UTF8, encrypt, and sometimes do other manipulations. |
While client-side DKIM checks might be somewhat out of our hands, we do indeed rearrange the headers as a side effect of go's random map ordering. This is a known issue and something that I hoped to sneak into v3 but never found the time (the message builder hasn't received much love for a while). The API provides both raw headers (string) and pre-parsed headers (key-value map). We use the pre-parsed headers because the API tends to do a better parsing job than we do. However, the pre-parsed headers are unmarshaled into a go map, and as such, have undefined order. |
I'm reopening the issue because maintaining deterministic message header ordering is something we should aim to do, regardless of whether or not DKIM checks will still work. There's one edge case I can think of where gluon actually relies on this. I've opened a ticket internally to tackle this (GODT-2212). |
I ran into this issue w.r.t. spam reporting to Spamcop. To determine the spam source, Spamcop specifically relies on the message header order. The cumbersome workaround is to export the e-mail from the Proton web interface, copy paste the contents and submit messages manually. Would very much appreciate if this could be fixed. Thank you in advance! |
A fix for this issue was released with version 3.6.1. All new messages will have their header order preserved. If you want to retroactively apply this, please remove the account from bridge and add it again. |
I'm using version 3.6.1 and don't see any change in behavior, neither for new or for existing messages (I removed and re-added the accounts). Web interface export (expected):
Thunderbird (through bridge v3.6.1):
As you can see, even the Content-Type is somewhere in the top, where I would expect it to be at the start of the body. |
I haven't had time to do a thorough testing, but I had to setup everything again some days after the 3.7.1 (br-183) update. But my experience is quite similar to @dikkechill. It still feels somewhat re-ordered. Once I get a bit more time available, I'll run more thorough testing. |
Header order is vital for any kind of diagnostics or forensics, as a side effect this would also fix DKIM checks, not being able to get the actual message as it was received is a big loss. |
Just testing and verifying again with Proton Mail Bridge 3.13.0 .... issue is still present. I set up a SimpleLogin alias to forward mails to both a Proton Mail address and a mailbox.org address to compare headers. This is what was being received on the various locations (data has been pseudo-anonymised): Proton Mail webmail:
mailbox.org account:
Proton Mail Bridge (via Thunderbird):
As another curiosity, only the mailbox.org mail has successful DKIM validation via Thunderbird. Exporting the mail from webmail as a |
When inspecting the e-mail headers, they are completely differently arranged compared to "View headers" via the Portal Mail webportal.
This breaks DKIM checks in mail clients, typically flagging them as suspicious. E-mail header ordering should be preserved via IMAP.
This behaviour can be tested in Thunderbird with the DKIM Verifier add-on.
Proton Mail Bridge version: git - v3 branch, commit 48480bc
Thunderbird version: 102.6.0 (64-bit)
OS: Red Hat Enterprise Linux 8.7
Note: This is not a regression from prior Bridge generations, this happened there too. But I had hoped that the new gluon integration would resolve this issue.
The text was updated successfully, but these errors were encountered: