Mailcow-dockerized: [Feature-Request] Force TLS for outgoing mails (SMTPS) + non-tls whitelist in Mailcow UI

[Braintelligence]

See title :)
Would be awesome to be able to set global enforcement of tls for outgoing mails but still allow Mailcow users to assign mails/domains to a whitelist if they absolutely need it (knowing the risks involved).

[mitchellurgero]

What would this be used for exactly? Wouldn't this cause more harm than good? Users for mailcow already need to use TLS to authenticate and send an email. Unless of course you mean server <--> server TLS in which case I would not force TLS for that from the get go since most SMTP servers on the web do not do this. That said, having a togglable option might be worth having.

[andryyy]

For now I added (not pushed yet) options for vars.local.inc.php that are read when adding a mailbox and applied by default:

// Force incoming TLS for new mailboxes by default
$MAILBOX_DEFAULT_ATTRIBUTES['tls_enforce_in'] = false;

// Force outgoing TLS for new mailboxes by default
$MAILBOX_DEFAULT_ATTRIBUTES['tls_enforce_out'] = false;

// Force password change on next login (only allows login to mailcow UI)
$MAILBOX_DEFAULT_ATTRIBUTES['force_pw_update'] = false;

This does not address the whole feature request, but it allows to make enforced TLS opt-out.

[andryyy]

We have this now =>

https://mailcow.email/2018/10/04/updates-again/

It is not per-user but the best we can do. :-)

[Braintelligence]

Unless of course you mean server <--> server TLS

Yes, this is exactly what I meant. And the use-case for this is enforcement of transport layer security for sensitive mail. Achieving this via enforced TLS is a quadrillion times more user-friendly than explaining how Enigmail, even with pep, works to computer-illiterate people (for the sole aim of having transport security - I know we don't achieve end-to-end here). The caveat of email servers that don't work with this can be dealt with by whitelisting them, after asking for the consent of the receiving end if they're ok with receiving mails in a way where they can be sniffed on transport.

By GDPR (especially) specific groups of businesses have to ensure (transport) security for their communication (and other stuff) by standard technical means. Sending your mail unencrypted or without even a transport-only encryption could be considered a breach of GDPR in those cases, because standard technical means to ensure encryption here do exist.

Statistics depicting how many mail servers support SMTPS vs. mail servers who don't would be interesting to see, though. There's no reason to not support it IMO and I think any mail server who doesn't provide such functionality should just not be considered part of the mail web, just as modern browsers start to consider http-only content as not part of the sophisticated web anymore.

@andryyy
So if I set

$MAILBOX_DEFAULT_ATTRIBUTES['tls_enforce_in'] = true;
$MAILBOX_DEFAULT_ATTRIBUTES['tls_enforce_out'] = true;

is there some way to allow non-TLS connections for incoming mails and/or outgoing mails by whitelisting? Not necessarily on a per-user basis but maybe on a global admin-basis?

Thanks for implementing these settings so far, you're awesome 👍

EDIT: Bah, I missed the picture in your link. So domain-whitelisting on an admin-controlled global scale is possible?

[andryyy]

You should remove a users ability to toggle TLS policies first (via ACL), so they cannot disable it.

Now setup a global policy like this:

[Braintelligence]

You should remove a users ability to toggle TLS policies first (via ACL), so they cannot disable it.

Not needed for new mailboxes, though, right?

Are Incoming TLS policy maps possible as well currently?

[andryyy]

Just enforce it on a mailbox. We always accept TLS, so that's not a real problem anyway. Not even problematic in relation to GDPR.

[Braintelligence]

Yeah, but what if the sending mail server only sends without TLS and we don't want data being sent to us without transport security? Imagine a tax accountant who is ready to receive mail from his customers that doesn't even have transport encryption; sure it's their own fault for doing so, but if realizing such stuff would be enough to dodge lawsuits, people wouldn't receive compensations for (too) hot coffee on their body.

[andryyy]

Just enforce it on a mailbox then. Or enforce it for your whole server.

[mitchellurgero]

Yes, this is exactly what I meant. And the use-case for this is enforcement of transport layer security for sensitive mail. Achieving this via enforced TLS is a quadrillion times more user-friendly than explaining how Enigmail, even with pep, works to computer-illiterate people (for the sole aim of having transport security - I know we don't achieve end-to-end here). The caveat of email servers that don't work with this can be dealt with by whitelisting them, after asking for the consent of the receiving end if they're ok with receiving mails in a way where they can be sniffed on transport.

As long as the TLS enforce is optional then I have no issues here. That said I believe in client security as well. Using TLS server to server is a great idea, once more servers support it. That's all I am saying on it.

@andryyy thanks for making this feature possible!