Enforce email mandatory TLS on incoming emails

Its for MTA (message transfer agent) (server to server) traffic on port 25.

1 Like

postfix discourages it. Quote Postfix Configuration Parameters


Mandatory TLS encryption: announce STARTTLS support to remote SMTP clients, and require that clients use TLS encryption. According to RFC 2487 this MUST NOT be applied in case of a publicly-referenced SMTP server. Instead, this option should be used only on dedicated servers.

I haven’t found any security blogs / advice setting postfix


on search engines. Whonix.org would be the first one to do this.

There are two cases:

  • A) third-party servers that send e-mails to whonix.org that harden their security
  • B) those that don’t.

In case of A), incoming e-mail TLS encryption is already enforced through MTA-STS.
In case of B), well, if the servers that send e-mail to whonix.org don’t care about MTA-STS we might be able to force them to use TLS by switching that setting.

E-mail security generally is awful anyhow. A supported stronger patch so to speak is OpenPGP - Kicksecure.


  • This is only about the whonix.org server for incoming e-mails for Whonix team.
  • This isn’t about the Whonix software.
  • Whonix is not and does not aspire to become an e-mail service that offers services to users.
  • Receiving e-mail on whonix.org is only a very auxiliary project activity that I’ve assigned a very low priority given all other development work.
  • Private Communications Policy

For receiving e-mails, compatibility is more important than transport layer security because incoming e-mails might have legal importance.

For these reasons, I won’t implement this.


1 Like

Based on RFC writing from 1999 which SSL barely was used anywhere: It was correct decision back in 1999, but not 2022.

No one gonna send an important email while using known providers or governmental/big tech company with no TLS support for their emails (we dont live in that era now). Unless the message generated from old bot spammer.

1 Like

Doesn’t really elaborate on the setting specifically and the context is unclear to me. For server to server communication within the same company the setting might make sense. It’s not explicit for communications from the general internet to a public e-mail server.

I’ve seen a number of companies that have bad security which was implemented years ago by a contractor and unmaintained since. Lawyer companies are sometimes hacked, often not computer security enthusiast.


  • Show there’s an actual movement towards that setting with more references.
  • Convince other projects and/or security/privacy-focused e-mail providers to do it. Since incoming e-mails on whonix.org are only a very auxiliary project activity, not a (free) e-mail provider, I’ve decided not to be a first mover in this case.
1 Like

Asked daniel from danwin1210 and he replied:


I have indeed mandatory TLS setup on my email script, but a user can choose to disable it. Unfortunately a lot of services do not offer encryption, most notably many those temp mail services, promising “privacy and endryption”. Roughly 90% of all google email traffic is encrypted, which you can see here: Google Transparency Report
For incoming email this is actually a very good thing to do, since it also blocks about 90% of spam mails (as most spammers don’t care about encryption). But it also blocks legitimate emails at times, like from Yahoo Japan and temp mail providers.
Even the linux kernel mailing list server doesn’t use encryption, which is one of the larger senders listed on the google transparency report.
I’ve reached out to many providers, most didn’t respond, only a few fixed encryption.



  • 90% of gmail incoming emails are using TLS (thats mean 100% encryption on whonix case compared to gmail traffic)
  • Enforcing TLS prevent spammers
  • We only loose temporarily emails and stupid email providers ← which is not a bad idea even users going to be notified that their email provider doesnt use TLS and thus making users put pressure on the stupid email provider they are using to make changes or use different one.
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]