Emails from my account are marked as "not encrypted" by Google


Hi guys! I’m new here, so if this is not an appropriate topic for a post just point me in the right direction.

I just started a Librem One subscription, and am trying to set up my email on my phone. As a test I’ve been sending emails to my gmail account, and it keeps complaining that my messages are “not encrypted”:

A lot of other mails in my inbox are marked with the same message, but some, like insurance and banking, are marked with “Standard encryption (TLS)”. Is that not something I can / would want to enable?

I’ve gone through the steps of getting a key and preparing to use PGP to encrypt my mail, but this seems to be referring to something else. I thought I knew a fair bit at least about this sort of thing, but I’ve quickly found all this to be quite overwhelming.


I don’t know which MTA they use but encryption comes as default for Postfix, Sendmail and OpenSMTPD
for a few years already. This is a huge security step-back.
Hopefully they did the SPF, DKIM and DMARC part fine, which will ensure that your emails are not flagged
as spam on many servers.
Generally it’s better to wait for an official security review from some reputable 3d parties or at least wait for
the project to go out of beta before using it. Surely there are more surprises like this that are not yet reported.


So I guess this is not what I should expect to see? Yikes. Hopefully this will be fixed by the time the service is fully up and running.


If I interpret that correctly, that’s about the transport encryption (TLS) and Purism should fix that. @Kyle_Rankin

It then means that the message plus meta-data (mail header, e.g. from, to) are visible to everybody with the ability to listen to traffic between and google servers. (Purism, Google, NSA and some more)

The transport being unencrypted is mostly unrelated to your use of GPG, except that if you encrypt your message with GPG, then only the mail header is visible (in clear) to 3rd parties.

However, note that you can only really make use of GPG if the receiver has his own GPG (public) key, and you have his public key to encrypt a message to them.


Edited: I think I essentially just repeated what you said, so I’ll make it brief instead and say thanks!

I will make sure not to send anything serious then for the time being.


There was a misconfiguration on the Librem One email servers that has since been fixed. Please try again. Like other posters have noted, transport security doesn’t protect the email once it’s on a server, you still want to use GPG to encrypt any messages that need to be secure.


I still cannot send transport encrypted mails using Exim from Debian stretch to Librem one. Trying ‘openssl s_client -host -port 25 -starttls smtp’ leads to ‘Verify return code: 21 (unable to verify the first certificate)’. suggests there might be a missing intermediate certificate (you might have used cert.pem instead of fullchain.pem if you are using certbot).

GnuPG is a good measure to protect you message contents, but it wont protect your meta data, which are quite sensitive, too. Not using transport encryption for e-mails is usually even considered breaking GDPR rules, so you have to use it if you are communication with EU citizens or people being in the EU.


I don’t know what is more concerning, the fact that the emails are not sent/received transport encrypted or the fact that both mx1 and mx2 servers are hosted on DigitalOcean, and thus are just virtual machines that are
accessible to both DigitalOcean staff and potential attackers as we learned from recent attacks.

So much for the trust.


SMTPS doesn’t use port 25, but 465.


The emails are sent using transport encryption. There was just a configuration error on the outbound mail servers that has since been fixed as I said above your post.


Sorry for having created confusion by writing to this thread about an issue concerning sending mails to addresses from outside, I should have opened a new thread (ports 465/587 are only relevant for, who want to send mails). Meaningwhile, somewhile fixed the certificate issue and TLS-delivery now works, thank you!


However SMTP that uses STARTTLS would ordinarily use port 25.

Exactly what the user was attempting to test I have no idea.


If I was launching an email service which claims to be secure, and respect privacy, checking that server->server SMTP traffic uses opportunistic encryption would be the first thing I did. We know for a fact that security services are passively monitoring and logging plaintext SMTP traffic. We got this information from Snowden.

According to Google, 93% of incoming mail to them is currently encrypted: - Email from was less private than 93% of email at launch time.

I understand it has been fixed now, but my god, this must have been a rushed rollout.

I also note that you haven’t implemented MTA-STS ( - If you had, then email with providers that support it (such as Google) would not just be opportunistically encrypted, but mandatory encrypted. I would expect a secure, privacy respecting email system to have this as a high priority task on their roadmap at the very least. Do you?

As an aside, the domain also lacks DNSSEC and TLSA on the MX servers.

Not a particularly impressive setup.