MTA-STS - secured mailtransport

[MAGICCC]

Just as info:

Since some days MTA-STS has been officially published as RFC 8461

MTA-STS (the full name SMTP Mail Transfer Agent Strict Transport Security) is a new standard that aims to improve the security of SMTP by enabling domain names to opt into strict transport layer security mode that requires authentication (valid public certificates) and encryption (TLS).

[xetorixik]

Would be great if MTA-STS will be added to Mailcow. And as @andryyy is an expert, and above all a good guy. Easily added.

[MAGICCC]

We would need to wait until the underlying programs supports that and then the user need to add DNS records which the UI should check by clicking the DNS button in the domain overview

[Braintelligence]

This is awesome. It's like a compromise between the status quo and only allowing SMTPS. At least you can be almost sure that any server who can do SMTPS will do it, even if somebody tried to tamper with the starttls.

[andryyy]

Inter MTA communications are mostly encrypted after STARTTLS.

Am 05.10.2018 um 14:32 schrieb Braintelligence notifications@github.com:

This is awesome. It's like a compromise between the status quo and only allowing SMTPS. At least you can be almost sure that any server who can do SMTPS will do it, even if somebody tried to tamper with the starttls.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ruffy91]

Providing MTA-STS for mailcow-dockerized itself as receiving MTA should be no problem. There are 2 prerequisites

• A txt file (MTA-STS policy) served from mta-sts.domain.examle/.well-known/mta-sts.txt with a valid certificate
• DNS TXT record on _mta-sts.domain.example

Validating other servers MTA-STS records is much more complicated and is not yet implemented in postfix.

Implementing only the policy part as a first step would nonetheless improve security, as Gmail, web.de, Yahoo et al already are validating MTA-STS policies.

[xetorixik]

Nice catch! "Implementing only the policy part as a first step would nonetheless improve security, as Gmail, web.de, Yahoo et al already are validating MTA-STS policies."

Should be easy peasy for expert @andryyy to implement.

[ruffy91]

Google now follows MTA-STS per RFC and also sends TLS Reports. https://security.googleblog.com/2019/04/gmail-making-email-more-secure-with-mta.html Also there is postfix-mta-sts-resolver which can provide the validating part to postfix: https://pypi.org/project/postfix-mta-sts-resolver/

[Perflyst]

Users should also get a notice of https://www.starttls-everywhere.org/ to add their server

[dragoangel]

Easier maybe for start implement (if look to mta-sts complexity) using https://starttls-everywhere.org/policy-list/ to enforce ssl for domains an mx hostnames.

[dragoangel]

About https://starttls-everywhere.org/policy-list/ take my words back. Project is dead. And mustn't to be used anywhere. I even put myself minus for it, lol

[Perflyst]

It is dead? Was there any blog post I missed?

[andryyy]

I can create a blog post if it helps to stop it.

[dragoangel]

It is dead? Was there any blog post I missed?

It's a dead from start.

1. Look - all their domains in the list are in testing. When many of them actually has enforce policy in mta-sts.
2. They're not actualize new requests - it all manual one-guy work to add new domain in the list. And they not do it until you write mail to them. Example: I was wait 1 month for add mail server to list. No check of mta-sts for this period of time was been done from them based on server logs (exception is that was been triggered by run my own check on their site), when GMail is checking MTA-STS each 2 days. This is does not coincide with their Validation statement Before adding a domain to the list, we continue to perform validation against the mailserver for at least one week. If it fails at any point, it must be resubmitted.
3. No recheck or update domains from list. Even NX-domains existing in that list which already not exist or not participating in MTA-STS at all. This is does not coincide with their Continued requirements statement We continue to validate all the domains on the list daily. If we notice any oddities, we will notify the contact email associated with the policy submission and urge you to either update or remove your policy.

This list not displaying anything. All their base statements is lie.

[heino-vdbh]

any news on implementation of postfix-mta-sts?

[dragoangel]

Based on https://pypi.org/project/postfix-mta-sts-resolver/ it now already has version 1.0 and based on description it production ready if trust description. But need to check github project also for any ongoing issues to be sure. Also it support redis for persistence which is nice actually as mailcow already has use redis as well.

One question is how it will work in pair (or even could it works in pair) with existing mailcow futures like TLS policy maps and user enforced TLS policy. Need to check this.

In my view mailcow TLS policy map must have be checked first, if no policy is set try use MTA-STS postfix resolver and if there also no policy, then use user defined policy.

As far I know user enforced TLS policy set postfix to use TLS, but not verify hostname. That why it must be applied in my view in end when no MTA-STS exist. When MTA-STS exist for domain policy must be set to verify certificate for this connection.

Also this future must be optional I think, or at least need to update documentation how to disable it totally or skip it for certain verified broken domain before merging any changes if any. My view to disable it for certain domain is to set TLS policy map for this domain or [mx]:25 :)

[dragoangel]

And @hniemann quick look and find: https://github.com/Snawoot/postfix-mta-sts-resolver/issues/67

In my view DANE is more strictly then MTA-STS, due this DANE more preferred then MTA-STS. So MTA-STS must not override existing DANE by default which isn't possible at current moment as I see from this issue.

To note: mailcow per user TLS enforcing also override DANE, so if look from this point maybe this not such big issue 😃 as I think of. But if this priority stuff will be fixed somehow it will be really better.

[heino-vdbh]

Hi @dragoangel thanks for the feedback.

I thought DANE was not very successful and MTA-STS is the new standard which is used by the big players like google and Microsoft.

Have you already connected postfix-mta-sts-resolver and mailcow dockerized?

[dragoangel]

No I haven't connected it and not think I can by myself. I can't say DANE not very successful, it requires more advanced infra setup and harder to implement TLSA sometime then host static https page, but at same time it supported by postfix from the box and many other mta as well :) while mta-sts - not. So question about who is more successful has 2 ends ;). Why such big players not add dane is another question.

At same time I have both DANE and MTA-STS on mine domains and I agree that regional TLD is too slowly adopt to DNSSEC in result many users simply can't get DANE working there even if all other stuff is ready.

[yawnbox]

Adding a 2021 request for an update. Mail-in-a-Box has this fully implemented, for comparison.

Thank you.

[dragoangel]

@yawnbox before putting comparison maybe better look how it implemented there?

You speaking about only policy placement and well, 1 Google request take me to open issue about mta-sts in comparison project you mentioned.

Please read history of issue: you can create policy by your self. It should not be a part of mailcow. This is ONE TXT file hosted over https, all other is dns stuff (from 2 to 4 records).

You can host novadays this response over anything, even with no http server, hello cloudflare workers :).

[yawnbox]

So the position of Mailcow is that security is opt-in?

[dragoangel]

@yawnbox such security policy need to be defined by people, how you see it will automatically know all your mx in all domains and list all of them to force if they could not feet? Update of policy require update of txt record in DNS, how this will be done? Of course this will be manuall update. Post txt over https is only 30% of job, all other 70% is DNS and certificate enrollment which also requires to force acme to get new certs. I not speak for all mailcow, I speak about my own view and I don't understand how it should be opt-in when all this 1 time job which take 5 minutes and it Not something complex that needs to be automated somehow.

[mkuron]

Therre was some discussion at https://github.com/mailcow/mailcow-dockerized/pull/2747 two years ago. At the time, MTA-STS didn‘t make sense for Mailcow because it was barely used anywhere, and DANE, which we do have, offers the exact same level of security.

[dragoangel]

@mkuron well #2747 implementation was not the best one because it was luck of some stuff. Now it could be done better:

• postfix-mta-sts-resolver was been changed to be more aligned with RFC
• no need to add new container, it could be part of postfix container I think without any issues
• use redis, as we have it already, no need in sqlite
• not break DANE policy and use DANE as first place to check policy (requires additional module)

About last point - I saw yesterday how Mailu done it https://github.com/Mailu/Mailu/pull/1961/files - this looks like good way to go, but it need to adopted/rewritten to feet Mailcow.

[mkuron]

Agreed, the implementation there wasn‘t perfect, but my comment was about the discussion of MTA-STS vs. DANE. At that time, nobody was able to point me to a mail server or service provider that published an MTA-STS policy (at least one not in testing mode) but didn’t publish DANE DNS records, or that validated MTA-STS but didn‘t validate DANE. Before we implement any MTA-STS support in Mailcow, we need to know whether at least a few such servers exist, otherwise it‘s relatively useless. Sure, niche cases were mentioned like using a top-level domain that doesn‘t support DNSSEC, but in that case one should probably switch to a TLD whose operators are more security-focussed. Similarly for Gmail, which apparently published a testing-mode MTA-STS policy but couldn‘t be bothered with DNSSEC.

[dragoangel]

@mkuron well I think it should be not compared directly :P As note: TLS reporting work for DANE as Well

I can just say that DNSSEC is something that not popular enough and it blocked by regional TLDs.

Of course hard to say exactly how much it rare, but from what I know from multiple sources DANE is enabled at near 2% of domains that have MX. I scanned a list of big companies, and as much company bigger then less DNSSEC enabled domains I see. It not reaching 10% for sure.

Not saw any statistics yet for MTA-STS, but I think it even now more globally deployed then DANE. I can say about my case: all .com is DNNSEC enabled and signed, all of them has MTA-STS as well, but all regional TLDs unsigned, none of them has DNSSEC and will not get this in foreseeable future. Regional TLDs are 70% of my domain, and all of them has MTA-STS. Good par that all of them has MX which points to .com, so they are technically use DANE as well :p but* if I need to use regional tld for MX...

Also need take in count that MTA-STS also states that mail server should be used with at least TLSv1.2 and not less, while DANE don't force any minimum TLS.

[mkuron]

I scanned a list of big companies, and as much company bigger then less DNSSEC enabled domains I see.

I have never heard a convincing reason why one wouldn‘t want to use DNSSEC, so I can only conclude that these companies don‘t care enough about email encryption. I know, this includes Gmail…

Not saw any statistics yet for MTA-STS, but I think it even now more globally deployed then DANE.

Please put together a list of a some servers that publish a MTA-STA policy (in enforce mode) and another one of servers that validate MTA-STS. I am still waiting to see evidence that these lists contain a nontrivial number of servers that don‘t also support DANE.

Also need take in count that MTA-STS also states that mail server should be used with at least TLSv1.2

DANE was developed after TLSv1.2, so it is relatively safe to assume that all DANE-capable servers support TLSv1.2. I am not aware of downgrade attacks, so this is not a real shortcoming of DANE. It is still nice that MTA-STS makes it explicit though.

[adroste]

I don't see a reason why MTA-STS should not be implemented. It's a security feature after all that is especially helpful when DANE is not enabled. There are still enough domain/dns hosters that don't provide (automatic) DNSSEC support (see Hetzner for instance). Looking at it rationally MTA-STS could be a sensible fallback if DANE is not available. MTA-STS also has the advantage that you don't have to deal with the key rotation madness DANE introduces which mailcow tries to circumvent by retaining the key when issuing new certificates via Lets Encrypt. This could even be a positive argument in favor of MTA-STS as it could be more secure than DANE with reused keys.

[AvverbioPronome]

Indeed, a very common reason why DANE might not be available is people changing TLS private keys pretty often. Which is a good thing. If you don't have or want to use an API to update your DNS records, you probably end up not using DANE at all, or telling your acme client to reuse the private key (which should be rotated at least once a year, but people forget).

Serving a file on a webserver is a lot easier (you still have to update the dns record if you edit the policy, but not regularly each time your private key is rotated).

[jmissig]

I use Hover for domain and DNS and have been happy with them. The downside is they do not support DNSSEC unless we use someone else for a nameserver. It’s nice that I can get MTA-STS without having to switch nameserver providers.

Edit: or figure out switching to Unbound or something like that, of course.

[dragoangel]

Edit: or figure out switching to Unbound or something like that, of course.

Unbound not fit this purpose, for NS you have to run Bind or sort of that