-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
The repository for Proton Mail Bridge (which is open source) claims to also host the source for the Import Export app.
Here: https://github.com/ProtonMail/proton-bridge
Briefly looking at the files and code it's hard to tell whether that is still the case, but it's fair to assume Import-Export would reuse most of the machinery behind Bridge.
JMAP is a replacement for IMAP. Unlike IMAP it has immutable IDs[0] but not much support[1].
[0] https://jmap.io/#faq
[1] https://jmap.io/software.html
I've suffered from exactly the same issues with Protonmail Bridge, and just this last weekend I decided (reluctantly) to move to a more standard mail provider (I chose Mailbox.org).
Aside from the UID issue discussed I also had problems with Bridge not supporting my particular use-cases. I created my own fork (see https://github.com/polaris64/proton-bridge) to work around some limitations and to add features, but maintaining this was too much work, especially as paying for a mail provider was supposed to reduce maintenance burden. I have had a pull request open since the 23rd of June to merge these to the upstream version, but so far I haven't received any comments from the Proton team.
I like ProtonMail, I just wish Bridge was more standards-compliant.
If anyone is interested in rolling their own, I have used this since early 2012: https://github.com/jakeogh/gpgmda
This is Bart, Proton CTO here. For clarity, the issue mentioned here only impacts Proton Mail Bridge, our desktop IMAP/SMTP gateway to Proton Mail encrypted email.
The fact that Bridge and its client can become desynchronized sporadically for some users is a high priority issue we have been working on. Bridge is open source, and as a result relies upon open-source components, and the root cause is an architectural issue in a library that Bridge uses to implement IMAP. When there are network issues, this library returns errors to email clients.
Unfortunately, there are hundreds of email clients, and some email clients don’t handle errors properly, and this leads to desynchronization.
Our error tracking shows this does not happen often (1-2% of Bridge users) and the symptom is usually incorrect display of messages or read/unread status which is fixed with an inbox resynchronization. There are cases where a combination of a desynchronized mailbox and a specific series of user actions can lead to accidental email deletion, but this is far rarer than desynchronization. Our implementation tries as hard as possible to avoid this. If you find you are missing an email, our implementation works around the issue by placing it in a users’ All Mail folder.
As Bridge is open source, updates on this issue have always been publicly posted on GitHub. Addressing this issue at the source requires replacing the core IMAP library. Unfortunately, there are no FOSS IMAP libraries that are sufficiently well maintained. Therefore, the solution is to build our own IMAP library called Gluon, which we have been focusing on since this issue was reported to us. You can follow the progress of this open-source project here: https://github.com/ProtonMail/gluon
We are not refusing to fix the problem. The only possible solution is writing a new open-source IMAP library which we can maintain ourselves to ensure this class of errors cannot occur again. We have doubled the size of the team working on this this year so it is a priority for us.
We’re confident that this addresses the main sources of desynchronization and will be available in the beta version of Bridge by the end of the year.