Conversation

Replying to

postfix + dovecot + opendkim + opendmarc + python-postfix-policyd-spf It's a whole bunch of configuration. Can optionally put nginx in front as a reverse proxy with the mail modules to provide denial of service resistance and better TLS configuration (optionally BoringSSL too).

1

Replying to

and

Can use internet.nl/mail/grapheneo and havedane.net for testing that stuff, then something else for testing inbound MTA-STS. Outbound MTA-STS is too painful. The available implementation for outbound weakens DANE by not preferring DANE over MTA-STS when available.

1

Replying to

and

It's a huge pain to set up compared to other things. A lot of the defaults are pretty bad. I have some of our configurations published but not the Postfix and Dovecot ones because that's a mess. Most of the work is Postfix configuration.

GitHub - GrapheneOS/mail.grapheneos.org: Mail server

Mail server. Contribute to GrapheneOS/mail.grapheneos.org development by creating an account on GitHub.

1

Replying to

and

This is the only particularly aggressive configuration for anti-spam (reject mail with DKIM failures from key not found): github.com/GrapheneOS/mai I don't find rejecting mail without TLS to really ever cause any issues, but I guess normal people would consider that aggressive.

1

Replying to

and

Oh, also, need unbound to provide DNSSEC unless you actually want to use systemd-resolved which has unfortunately been a quite sketchy part of systemd.

1

Replying to

and

If you sent an email to me via Gmail or G Suite, they'd authenticate our server using a weaker form of WebPKI without CT due to MTA-STS. MTA-STS support is rare though. A major advantage to your own mail server aside from usual self-hosting advantages is inbound/outbound DANE.

1

1

Replying to

and

You can actually have DNSSEC by using the alternate set of G Suite addresses: mx1.smtp.goog mx2.smtp.goog mx3.smtp.goog mx4.smtp.goog They don't have TLSA records though, so still no inbound DANE and they don't do outbound DANE either.

1

2

Replying to

and

There are actually a lot of mail servers with DANE support, particularly in the EU. More likely than not there's DANE available for emails to/from *.nl addresses. Maybe Google will give in and admit it's a good thing after Microsoft has finished deploying it as they announced.

1

1

Replying to

and

MTA-STS is actually trash... the Gmail domain only has a 1 day max-age too, so if your server doesn't send email to Gmail for a day it loses the MTA-STS enforcement. I'd set it up for outbound if it didn't downgrade DANE security for domains with both. :\

1

Replying to

and

It doesn't. MTA-STS is designed not to interfere with DANE deployments when the two overlap.

MTA-STS explained

Google announced that they made email more secure by adopting the new MTA-STS internet standard. But what is MTA-STS and how does it improve security?

1

Replying to

and

I'm talking about the actual implementation that's available for Postfix, not what it's supposed to do in theory.

MTA-STS Overrides DANE · Issue #67 · Snawoot/postfix-mta-sts-resolver

I don't know of a good domain to generate a test-case for, sadly, so apologies if this isn't true, but from my understanding of the integration flow, it seems like using this in smt...

5:15 AM · Jun 13, 2021Twitter Web App

Replying to

and

I should have said "It shouldn't, when implemented correctly". Are there no other plugins that do this correctly?

1

Replying to

and

I don't think so. I have it set up for inbound mail i.e. the DNS records + web server serving a policy via an mta-sta subdomain for each domain with mail support. I don't use it for outbound mail because I'm not willing to downgrade DANE security for it due to that issue.

1

Show replies

Viktor Dukhovni

Replying to

and

There is no MTA-STS support in the official Postfix release. So "MTA-STS" does not override DANE in Postfix, rather local per-destination policy that replaces DANE with some other security mechanism as expected overrides DANE.

1

Viktor Dukhovni

Replying to

I am well aware that there are half-baked third-party "MTA-STS"-like implementations, that very crudely approximate MTA-STS via a dynamic TLS policy table. Even aside from potential implementation flaws, they are flawed by design, and I don't recommend their use.

1

Show replies