Trying emClient (which I think is brilliant) but I have a problem with one account, my ProtonMail account using the ProtonMail bridge. It doesn’t display the mail body of HTML emails.
I think I can maybe see why. Looking at the email source there is an X-Internal-Id: header in there, which I suspect is added by ProtonMail or the ProtonMail bridge. Following it are two CRLF effectively creating a blank line which I think is supposed to indicate the end of the headers. But there are more headers after it, including some like Content-Type: which I think are important for proper rendering.
Is that likely to be the problem? Can it be worked around? I will also contact ProtonMail to ask if they are adding the header and if so are they doing so incorrectly and if so can they fix it.
Happy to forward on the source of a mail to show the issue.
If this can be fixed one way or another I’ll definitely be switching to (and paying for) em Client and I suspect a lot of other ProtonMail users would too as having to have a separate browser open to use ProtonMail is a pain.
Yes, saw and tried that, it doesn’t fix it. I’m not sure how it did for Nick. The problem is consistent. Emails from the ProtonMail bridge all have this header with a blank line after it. Emails from other accounts don’t have that header/blank line combination and all display perfectly. I have asked ProtonMail whether they are adding that header, we’ll see what they say and I’ll report back.
It may be because the bridge is not a properly configured IMAP server. eM Client likes to retrieve the headers only from the server, then later retrieve the message body when you click on the message. It could be that this local server does not fully support that.
What happens if you configure the account with Nick’s method, but use POP3 instead of IMAP?
Unfortunately the ProtonMail Bridge doesn’t have POP3 support, only IMAP.
Reading the RFC something is definitely breaking the specification by putting the double CRLF after that X-Internal-Id: header. ProtonMail have promised a reply within one working day so we’ll see what they say.
And just noticed. If you do “view mail header” on a genuine IMAP server you just get the header. “View Mail Source” gets you both the header and the body.
With the bridge both commands get you both the header and the body.
I’ll ask ProtonMail if they support fetching just the headers or just the body.
Sounds like they alter the message structure in a way that eM Client is not able to separate the header from the rest. That could explain why the message body appears empty.
"We’re aware of this issue and working on resolving it. eMClient, along with other email clients such as Airmail and Mailbird, are on our list for future clients that we will support. Unfortunately we don’t have a specific release date for this yet.
We’ll pass your feedback to our developers and will contact you if we need any further assistance, thanks for bringing this up."
Which prompted me to try Mailbird, which appears to work so far. It certainly gets the body of both plain and HTML mail. Not to say it won’t have other issues in the fullness of time. Trouble is I think I prefer your client!
I know the ProtonMail Bridge is only available to paying ProtonMail customers, but if you want to try and work around the problem I’m happy to help, forwarding failing messages or providing the source of a failing message and testing any fix.
I’m not sure it’s reasonable for emClient to have to work around shortcomings/bugs in the bridge which appears not to follow the IMAP specs. Hopefully ProtonMail won’t take too long to get their code shipshape.
eM Client does support S/MIME and PGP encryption, so there is no real need to use third party applications to encrypt your messages.
But I know that a lot of people are more comfortable using ProtonMail encryption. In that case you need the bridge server because I believe that their encryption is proprietary.
Those are great tools, but they are not the same thing. Their encryption is not proprietary - the web-based client is available on github, open source.
I seem to remember that ProtonMail Bridge was launched as a solution because at the time there was very little support on the Windows platform for encryption of messages.
So now that there is this functionality in eM Client, and in others as well, what is the need for a separate application to do that?
I think you’re misunderstanding the point of Proton Mail - it’s not e-mail encryption (though that is part of it), it’s an end-to-end encrypted e-mail platform (like Hotmail or Google mail).
ProtonMail Bridge exists to help IMAP clients connect to the ProtonMail service. The need for it would be eliminated if clients built in native support for ProtonMail.