Proton Mail (Bridge) sends quoted strings with not allowed bytes #38
Comments
|
I precise that the error occurs only from Proton Bridge (v3.6.1 tested). The malformed message displays correctly in their web interface. |
|
CF https://datatracker.ietf.org/doc/html/rfc5738 They take it for granted and activated by default? How they handle UTF 8 in mailbox names ? |
|
In fact, Proton Bridge sends invalid bytes even when the message is correctly encoded. With
Looks like. I precise that I do not send any
I created a folder named |
|
Looks like they also return invalid bytes in |
|
Looks like Proton Bridge does not support the |
|
May be related: ProtonMail/proton-bridge#451 ProtonMail/proton-bridge#478 |
The message is malformed I would say. But: IMAP is weird. ... can be interpreted as ... Status {
tag: ...
code: Some(Other("Error offset=5")),
// The next ":" is broken
text: "unknown command `enable`"
}... or (with a lot goodwill) as ... Status {
tag: ...
code: None,
text: "[Error offset=5]: unknown command `enable`",
}See #31. I think the |
duesee
added
PROTO=IMAP
|
Another case of envelope containing invalid chars. Shall we initiate a new quirk? |
|
Can you give me a short reminder what was our last state here? I remember there was a bug where we activated UTF-8 (without being prepared for it.) Can we confirm that Proton uses UTF-8 unilaterally without us asking for it via |
|
I'd like to give more context on pimalaya/himalaya#525 which I submitted, and is possibly related: For context, I'm using ProtonBridge v3.15.1 (br-206), on Windows, and himalaya v1.0.0. I initially thought that UTF8 was not the cause, as out of 2828 invalid fetches, 4 of them did not, at a glance, include raw UTF8 bytes (all 2824 other invalid fetches contained either I used python's subprocess module to collect the raw output, and here are the raw bytestrings of the 4 interesting log lines: The first two contain encoded UTF8, and raw non-breaking spaces ( I minimally redacted the log lines, here's what I replaced the original bits with (the cut city name is mildly interesting in itself, there was no reason to cut it as it only contained ascii letters). None of the original bits included non-ascii bytes: I'm going to try to compile himalaya from source and poke around the code to find potential clues (I'll try to understand how quirks work and what new quirk may solve the issue). |
|
Trying to be useful, I wanted to answer #38 (comment) specifically. Here's the observed behavior of ProtonBridge v3.15.1 (br-206) (latest version that I'm aware of): I think we can confidently say that:
|
|
Thank you for your amazing help! I'm a bit short on time but what this means to me is that I should prioritize the implementation of the UTF-8 extension in imap-codec/types and enable a quirk to accept UTF-8 -- maybe even by default. The libraries stick to the RFC very tightly but I feel this issues will keep coming... |
Given the following malformed message:
When fetching the envelope associated to this message from Proton Bridge, it returns a
FETCHcontaining envelope address with not allowed bytes inside quoted strings, which leads toimap_nexterrorReceived malformed message.I did the same test with Gmail, Outlook, Posteo and even 163, they all encode correctly the sender. Proton Bridge seems to send back envelope addresses as they are in the original message.
CC @duesee
The text was updated successfully, but these errors were encountered: