Summary document: What do we do about MTA-STS adoption? Should we do anything? Let’s find out!
I talked to about four folks who work on or around Internet security issues as their primary job, four folks who manage mailservers as their profession, and 2-3 folks who work on or around MTA software.
In general, it seems that people who manage mailservers are strongly against any additional complexity in their setups, and a higher portion of people who do security are very pro-middleware option due to the strong decentralization of the email ecosystem. Folks who happen to develop MTA software (Exim/Postfix/Gmail), are predictably interested in getting MTA-STS support in natively, though they admit it could take up to 2 years.
I’ve organized this document by grouping together similar notes I took during the conversations. There were a lot of repeat comments and I'll mention which ones were popular.
- MTA-STS development in Postfix and Exim might have earlier timelines that we originally expected. It’s already too late for the Postfix 2019 release, but it’s slated for the Postfix 2020 release. Exim didn’t give me a timeline but I think they can be coerced.
- Google is testing its TLSRPT implementation now.
- Both Comcast & Microsoft may be coercable-- both have a senior staff member who co-authored MTA-STS and are looking for help to push their organization into getting this onto their timelines faster. (More talk with Peter later today)
- It’s complex, and may be difficult to do for people who rely on email hosting providers.
- It coerces the email ecosystem to depend on the CA trust system, which it hasn’t had to before.
- From our experience with debugging with webserver admins, many administrators out there just know the bare minimum to keep their system running.
- Although your average mailserver admin may know more than the average webserver admin, almost all I’ve talked to (that happen to not be security professionals also) are very averse to add another moving component to their setup. The larger the service they run, the more averse they are.
- “Can’t we just use the policy list instead of adding this component to our system?”
- “Why? I’m just going to implement it in Postfix next summer then it will be obsolete.”
- Admins for smaller, self-hosted companies which has a microservice-y back-end stack would want it to be easy to compartmentalize (maybe containerize-- docker?) and run on the same machine as the mailserver. Would expect it to be integrated with services such as Mail-in-a-Box, or with sample setup/configuration files for more tuned and manual setup.
- Admins for enterprise mailservers suggested something similar to what they use for spam filtering (like a Barracuda/Symantec transparent proxy), though they had more reservations about getting this configured correctly.
- Smart hosts are difficult to configure, too.
- Generally pro, but not sure that we (EFF) have the most affect doing things like building out MTA-STS support for others.
- I’m personally averse to politics, but I think this is a good place to put that sort of pressure, and it’s something that EFF is well-suited for.
- We should focus on making the list as good and usable as possible and get it deployed into “the big guys,” and simultaneously push for and measure MTA-STS adoption. Eventually, the overhead of maintaining the list will approach zero.