-
-
Notifications
You must be signed in to change notification settings - Fork 110
Don't prefetch Chat-Version and Auto-Submitted headers, try to find out message encryption state instead #7426
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
base: main
Are you sure you want to change the base?
Conversation
|
CI is failing. Edit: Might be that our CI server is having some problems |
…yption state instead Instead, prefetch Secure-Join, Content-Type and Subject headers, try to find out if the message is encrypted, i.e.: - if its Content-Type is "multipart/encrypted" - or Subject is "..." or "[...]" as some MUAs use "multipart/mixed"; we can't only look at Subject as it's not mandatory; and depending on this decide on the target folder and whether the message should be downloaded. There's no much sense in downloading unencrypted "Chat-Version"-containing messages if `ShowEmails` is `Off` or `AcceptedContacts`, unencrypted Delta Chat messages should be considered as usual emails, there's even the "New E-Mail" feature in UIs nowadays which sends such messages. Don't prefetch Auto-Submitted as well, this becomes unnecessary. Changed behavior: before, "Chat-Version"-containing messages were moved from INBOX to DeltaChat, now such encrypted messages may remain in INBOX -- if there's no parent message or it's not `MessengerMessage`. Don't unconditionally move encrypted messages yet because the account may be shared with other software which doesn't and shouldn't look into the DeltaChat folder.
There was a comment that group messages should always be downloaded to avoid inconsistent group state, but this is solved by the group consistency algo nowadays in the sense that inconsistent group state won't spread to other members if we send to the group. Moreover, encrypted messages are now always downloaded, and unencrypted chat replies too, and as for ad-hoc groups, `Config::ShowEmails` controls everything.
Before, only replies to chat messages were moved to the mvbox because we're removing Chat-Version from outer headers, but there's no much sense in moving only replies and not moving original messages and MDNs. Instead, move all encrypted messages. Users should be informed about this in UIs, so if a user has another PGP-capable MUA, probably they should disable MvboxMove. Moreover, untying this logic from References and In-Reply-To allows to remove them from outer headers too, the "Header Protection for Cryptographically Protected Email" RFC even suggests such a behavior: https://datatracker.ietf.org/doc/html/rfc9788#name-offering-more-ambitious-hea.
19b501c to
7677439
Compare
Yes, there were random timeouts in various tests. Now everything works except The corresponding log is Maybe the chat hasn't been created by then. |
Separated from #7405 the commits which can be already merged (don't conflict with removal of partial downloads). Probably it makes to merge them earlier to avoid compatibility issues when we remove Chat-Version from the outer headers.
This tries to find out message encryption state looking at Content-Type and Subject. Basically, encrypted messages are considered as chat messages and moved to the DeltaChat folder if MvboxMove is on.