Conversation

Replying to

and

Occasionally some marketing spam making it through and if it appears to be in an official capacity, I add their domain to a list of entirely rejected ones. Also, enforcing some basic rules on header / HELO validity, etc. Haven't needed PTR checks, graylisting, spam filtering.

2

1

Replying to

I still have to figure out how to set a lot of this up for Grapl. We're all GSuite.

1

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. :\

6:34 PM · Jun 12, 2021Twitter Web App

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...

2

1

Show replies