Google has deployed MTA-STS, and past experience suggests that this means, "Here's some totally useless new thing, but if you don't implement it, we're eventually going to stop accepting your email."So can someone point me at simple instructions to make it go on my mail server? (Postfix 2.10, Centos 7, certs via Letsencrypt)
Or tell me that this is a thing that nobody will ever care about. That works for me too.
MTA-STS isn't perfect but a good addition to DANE. Read more on the subject in my blog at URIports
MTA-STS is for trying to upgrade SMTP from optional transport encryption to enforced.
They publish one for Gmail, and they'll look for yours for sending to you.
It's not really related to receiving mail at all (the sender does the certificate validation), so it seems unlikely it will be factored into their receiving path in any way.
Google has a longstanding habit of adding "signals" to their decision of what is or is not spam, including what level of internal, opaque "trust" they apply to the originating host.
If you think it's unlikely that they will eventually use the presence or absence of some random DNS record or SMTP feature as such a signal.... you probably haven't been pushing your boulder up Google Mountain for very long.
Anyway, I think I worked it out.
Can you share what you’ve found?
This one was the clearest set of instructions I found. Bottom line:
• Add a DNS TXT for "_smtp._tls" = "v=TLSRPTv1; rua=mailto:postmaster@[DOMAIN]"
• Add a CNAME for "mta-sts" (yes it has to be literally that)
• Add a VirtualHost for "mta-sts.[DOMAIN]" that can serve "/.well-known/mta-sts.txt" (yes it has to be literally that)
• Add "mta-sts.[DOMAIN]" to the list of hosts in your certs.
• mta-sts.txt:
version: STSv1
mode: enforce
mx: [your MX]
max_age: 600
• Then silently facepalm at SMTP now being coupled to and dependent upon HTTP.
That only announces your outbound policy, it does not enforce others' policies on your inbound.
Are you using the words "outbound policy" in a strange way here?
MTA STS announces that you want other people's relays to use TLS when connecting to your SMTP server. ie Now Google knows jwz.org's SMTP server wants them to use TLS. Previously they had to discover this by noticing that STARTTLS was possible after connecting to the SMTP server. IMNSHO this is very close to useless‡, but people who hate DANE really, really wanted to do it and it's exhausting trying to stop idiots from hurting themselves so we gave up.
The TLSRPT stuff (SMTP TLS Report from RFC 8460) is at least useful. What that does is tell senders "Hey, if you couldn't talk to my SMTP server using TLS, instead of just delivering anyway with plaintext and thus destroying privacy for my senders and recipients please let me know there's a problem".
If you operate a popular web site (maybe the pages for DNA Lounge? perhaps not) this is equivalent to those emails you get saying the site is down. You can judge whether those are useful in aggregate or just annoying (obviously some fraction of them will just indicate that the sender's client is borked, the more competent you are the higher the fraction...) and the same will apply to SMTP TLS Reports.
‡ Because this is a newer signal than STARTTLS it can imply new semantics, so e.g. "I have current certs from the Web PKI for my actual SMTP server names" or "I actually speak a version of TLS that isn't old enough to buy booze in California" rather than "Check out my DIY X.509 cert with inappropriate EKUs" and "Is SSLv3 the new one?". So that's something I guess.
By "outbound policy" I mean you are making an announcement, "I use TLS, freak out if I don't". Apparently it's possible to make your server listen to others making that request too, but that's more work.
Mmm. I can't tell if you're confused or have happened to explain this in the way that makes it most likely people will misunderstand.
The announcement is: "Everybody can and should use STARTTLS with my MX and I promise I have installed correct certs and modern crypto" (and with TLSRPT "... if that doesn't check out, tell me about it so I can fix it")
It explicitly is not saying "My software will demand STARTTLS when calling somebody else's MX" or anything like that. Which is why people were surprised you think it's a potential anti-spam signal, if Google wants to mark stuff that's submitted plaintext as likely spam they're doing that already. Not that I disagree they might decide that this unrelated DNS entry indicates or does not indicate spam, but that's like literal augury (omens from the flight of birds) and could go either way.
Its proponents think MTA STS is the new HSTS (hence the name) but I suspect it's more likely the new HPKP. It's a formal standard for everybody to do something that works pretty well if you've got expert admins running your servers and otherwise quickly malfunctions. I foresee dozens of mail servers whose admins don't know why they never get any email until they find oh - there's an mbox named postmaser or posmaster [sic] with a billion emails from popular mail sites saying I misconfigured MTA STS...
Ultimately this might nudge more people to put Web PKI certs on their MX and so take us a step towards something better than opportunistic encryption that way, but I expect nothing else useful from it.
Dude, as ‘outbound’ is referring to advertising a policy, ‘inbound’ here is clearly referring to ingesting the policies of other servers. How do you make postfix do the MTA-STS lookups, attempt to use the found information, and submit trouble reports?
It is possible with external TLS policy server for Postfix
I don't see how a machine-learning filter can do the math and not conclude "spammers are labor time-constrained, the admins of the six mail hosts I get 99% of my non-spam mail from are not, and those six mail hosts are wearing the latest DNS fashions; therefore, anyone who wears the latest DNS fashions is probably legit, or at worst relaying through some legit but subverted host." These machines don't understand causation, they only do correlations, and from a heavily biased data set at that.
The relation is one-way--if you're in a majority that is not wearing DNS fashions, its absence doesn't provide actionable information about your spamminess. You don't get penalized for this per se (it won't turn a neutral mail spammy), but not getting a boost above the noise floor is effectively a penalty. There are so many spam indicators that it's now impossible to construct an email without hitting half a dozen.
Spammers often are the first to adopt some of these things (unlikely MTA-STS since they don't do inbound) because they hope it will improve the chances of their spam getting through. shrug Depends on the type of spammer, of course.
And if the bit "this sender also has MTA-STS" becomes an ML feature, then it might learn that means spammer or non-spammer, hard to predict at this point with so few places having them or seeing any particular correlation stats.
My original point was that it seems like a poor signal, so I wouldn't think it was worth the extra effort of piping the information from the outbound side or doing the extra lookups on the inbound side.
Wow. I'd complain about the insanity of having to keep my web server alive in order to maintain working email, but since they're both sitting on the same box I guess it's already shared failure domain territory to some large extent. I'm also pleased at the idea that interaction with my mail server will necessitate interaction with my web server. This is truly a brave new world.
Hah,
always think for "No Evil" ,-)
Thats most probably the reason for pushing this thing.
F*ck privacy, yeah.
Every "normal" thinking person would show them how to encrypt E2E....
Ultimately, you're not wrong. Its adding an annoying large second protocol. You don't need it, you can accomplish a similar thing with DANE-TLS, and I imagine that at some point Google will support that as well.
As you point out, though, almost everyone has one anyways, and a large number of senders have actual links/images in their messages that are on their website. And maybe you'll think like some do that DNSSEC, which is required for DANE-TLS, has its own level of pain, and maybe maintaining a web server and using web pki infrastructure is easier. It all depends.
(Disclaimer: I work for Google, and used to work on this stuff)
There's a reasonable argument that DANE is never going to happen. Ultimately you have to conceive of DANE as an alternative to the Web PKI, and the Browser Vendors have put a lot of work into the Web PKI, it's not a coincidence that it isn't called the "IETF PKI" or the "TLS PKI", and after all Jamie's colleagues at the ol' Mosaic Communications Corporation built all this stuff in the first place. None of that work is reusable under DANE and many of the hard won benefits disappear, the upside is uncertain.
So when they're asked about it, obviously even if they can get past the sunk cost fallacy there's not a lot of enthusiasm for DANE at browsers. Code has been written to do DANE in Chromium and Firefox, and it's disabled or removed because it wasn't deployable in practice for the usual reasons.
This influence reaches into things like the IETF working groups where ostensibly it's not just about web browsers. TLS is mostly a product of outfits like Google, Mozilla and Cloudflare, the working group is full of low-level web people and so there's a TLS feature draft that got all the way to adoption and then was basically stalled out and had its throat slit because in reality it's a way to do DANE and the Browser Vendors don't want DANE. It's embarrassing because they should have stood up and said "We hate DANE so much we don't want it to even be possible" rather than adopting it and then slitting its throat later -- which wasted a lot of good people's time including their own, but it's not as though there was ever a good ending possible once they adopted.
If you still cling on to the hope that we can still
make fetch happendeploy DANE in anger your best hope is probably that just the right amount of DPRIVE happens. Too little and DANE can never be deployed because clients can't get reliable DNS answers, too much and nobody cares about DANE because all DNS answers are guaranteed true by the Web PKI in some sort of Escher-inspired spiral of cryptographic recursion.In the good spirit of the new internet, next up: SMTP-over-HTTPs.
And all you need to do is first sign up to the developer program of our mail server and authenticate with OAuth2 and your unique client ID to be able to send mail to it.
Currently our developer program is in beta and only open to strategic partners, but stay tuned!
That max_age looks a bit low; are you finding that google complains about it ("no policy found")? Apparently they reject policies with a max_age lower than 86000 (possibly 86400?).
max_age has a minimum value of one day (86400). Because why would you need to change settings more often than that, or something...
Is max_age only the Expires of the mta-sts.txt file or is it related to certs? I ask because I use letsencrypt whose certs are 90 days so I wonder if too long a value here will mess something up.
I believe it's just the caching of the MTA-STS parameters.
So, the mta-sts.txt file has an expiration date built into it... because it is served over HTTP... which does not have an Expires header. Yeahhhhh that makes sense.
Contact with the enemy. Frankly even "Create a text file" is a fairly optimistic decision and I expect a non-trivial fraction of attempted MTA STS deployments will fail because an MS Word document and a raw HTML file didn't work and the user gave up trying to understand what's wrong.
ACME's http-01 works in this same space, they're emitting the file from code (if you understand what you're doing you can generate a "correct" HTTP answer for http-01 in a Perl one-liner that doesn't know your ACME account keys and this is intentional but it's not what most users are doing) and despite that they found many users can't set the MIME type correctly, and struggle to understand how permissions or file naming work on their computers. Last time I looked draft ACME (and the Let's Encrypt implementation) no longer checks Content-Type because it's so often wrong and the downside of ignoring it (what if bad guys are allowed to upload arbitrary files to .well-known/ on your server, but only as image/gif?) was too small compared to the inconvenience it was causing users.
The RFC does not mention a minimal value for max_age, so a value of 1 is technically correct. I've been in contact with Google and they have a cut-off limit of 86000 (400 seconds less then a day) due to the fact that a value below this is not considered useful and just adds weight to their caching servers.
The max_age is their in case a MiTM attack prevents a sending server from retrieving the policy, or if the web server is down for instance. It is in your best interest to have this value somewhere around months.
A lot of uninformed people are making statements that are based on assumptions, creating a lot of negativity about something that is worth implementing. MTA-STS has it's flaws but for those without DNSSEC it is worth implementing. (You can add both)
I've done two blogs last week about Email Security and In depth MTA-STS.
Nick explained it quite nicely: "The announcement is: "Everybody can and should use STARTTLS with my MX and I promise I have installed correct certs and modern crypto" (and with TLSRPT "... if that doesn't check out, tell me about it so I can fix it")"
You've made the inference, but this latest thing really makes me think this is Google's EEE of email. They're trying to make it so difficult to run your own email server, that people just won't do it. I ran one for about 15 years, with a whole other service for syncing it all to my Treo(!), and finally gave up, and gave it all to Google. (Then switched, and gave it all to Apple. So now they BOTH have all the email I've ever sent. Sigh.) Given your posts about these things lately, I KNOW I don't I have the stomach to ever try again, and, like I said, I think that's Google's conscious intent. They can say this is about spam, but their spam filter was better than it is now, a long time ago. None of this seems particularly necessary.
I, too, used to operate my own mail server. Even in a post-spam era, it was simple and it let me do clever things.
Nowadays, I, too, have Google handle that for me. The trouble is: My Google-hosted myname@mydomain address is supposed to be my login and gateway to all of the lovely services that Google hosts, but they've been shit at supporting this for years now.
Google Home, for instance, works like dogshit with a custom domain on Gmail....for no discernable reason or benefit.
This isn't about spam, though jwz is implying that eventually it'll make it into the spam filter.
This is about privacy, ensuring your emails are encrypted in transit and not trivially stripped of transport encryption by MITM or DNS hacks.
Obviously, E2E encryption would be better, but its also much harder, especially on end users.
I realize why jwz is suspect about more dns shenanigans on email, he's no doubt referring to SPF/DKIM/DMARC, and those definitely have bearing on whether Google accepts your mail. MTA-STS is different, it would be a much less obvious choice for the inbound spam classifier, but maybe eventually...
(also, I guess I should have realized the direction this post would go and point out in my original post that I work for Google, and previously ran the Gmail mail infrastructure, so my comments aren't purely speculative but also aren't current, and I'm not revealing anything non-public)
I have the same worry as you. Past experience does make me worry.
I am currently sticking with "nobody worries about it", until all my emails are rejected.
Past experiences should make you worry. That's a good thing. But MTA-STS is for protecting transport of email to your mail server, and has nothing to do with you sending email to others. Implementing MTA-STS is the same as DANE but it uses trusted CAs instead of DNSSEC. It instructs sending mail servers that your mail server has STARTTLS working and configured correctly and if a secure channel cannot be set up, the message should not be delivered. This protects email to you from a MiTM attack.
Good grief. When did organizations forget that the purpose of mail is actually to deliver to the recipient? Seems to have become a certificate wank fest.
Some senders would rather that you refused to deliver their mail than that you opened it, showed everyone in the office and then delivered it as required. It depends on how they feel about privacy, and I wouldn't like to guess whether "deliver it whatever" or "preserve my privacy" are the overriding desires of each sender but I'm confident most of them will be angry that this is considered a trade-off they might have to make.
MTA-STS is not mandatory. If you do not want email addressed to you protected against MiTM attacks you should definitely not implement MTA-STS or DANE.
Google jumped the shark long ago. I vote for plan B: don't care.
Some of us don't have the luxury of saying, "I'm ok with not being able to send email to my customers who choose to use gmail, which is almost all of them."
You are of course completely right. Business needs come first. The point I was rather clumsily trying to make was that I don't think this is one of those because Google finally appear (to me) to be losing their vice-like grip on the internet's entire communication infrastructure.
I don't think Google have the power any more to force on a whim the entire rest of the internet to perform yet another magic incantation over their email infrastructure in the latest cross-your-fingers-and-hope manoeuvre.
Of course if they're already actively rejecting email from servers that don't implement this latest silver bullet then consider my words well and truly eaten and I wish you the best of luck. I don't run email servers for a reason.
Not having been familiar with this, I initially thought the title was a joke on your part, to be pronounced "metastasis", and was momentarily confused to find it is not.
Where can I find this jwz blog robot?
Apologies for the off-topic.
Hi,
Here is manual you are looking for. This manual incorporates postfix-mta-sts-resolver in order to fetch STS policies of foreign servers.
is MTA-STS pronounced 'metastasis'?
sounds about right.
Some Linux devs idly talking about what shibboleths to use reminded me of your torment:
https://lwn.net/Articles/790193/
Wow, look at all that confident anecdata. Assuredness is truly the perpetual motion machine of open source.