
Making email more secure with MTA-STS standard - edmorley
https://security.googleblog.com/2019/04/gmail-making-email-more-secure-with-mta.html
======
stonogo
This article is a disingenuous description of a lot of bad work. A more honest
headline would be "Google making email more complex by introducing more
protocols." Instead of just registering an SMTP-over-TLS port, now EVERY
message requires an HTTPS lookup and a reconnection. That's not the intent,
but the specification was so poorly written that it is the most common
interpretation.

All of the input during the IETF draft phase was completely disregarded unless
it came from a sponsoring corporation (all of whom are either Google or
residential ISPs). This whole process is a shameful illustration of IETF
process failure and I hope Google terminates it as readily as they do business
units.

~~~
tptacek
This comment is a lowbrow dismissal of important work. In the MTA-STS _status
quo ante_ , an attacker could break TLS and MITM SMTP transactions by forcing
a protocol downgrade. That's an untenable situation, as would be a decree from
the major mail providers that all mail must now be sent over TLS. The third
alternative, widespread deployment of DANE, would be _even more onerous_ for
site operators, in addition to its unfortunate side effect of instituting a
global PKI rooted in world governments.

There has been an SMTP-over-TLS port for ages. Obviously, that doesn't fix the
problem, because a MITM attacker can simply RST connections to that port.

MTA-STS does not in fact require EVERY message to do an "HTTPS lookup and a
reconnection".

~~~
blitmap
Google is in a position where they could have disallowed protocol downgrades,
setting a standard without defining a standard.

~~~
netheril96
Ha, imagine the outcry in that case. It certainly would be even louder than
this one.

------
tptacek
This is great news. It's worth noting: the subtext behind MTA-STS (actually
made explicit at one point in the RFC) is that it works without DNSSEC and
DANE, which major mail providers weren't adopting (for good reason).

Since breaking SMTP TLS MITM was one of the few remaining things DNSSEC could
help with that didn't have answers in other protocols, this is a major blow to
any impetus to roll DNSSEC out in the future. Between MTA-STS, DNS-over-
HTTPS/TLS, and certificate transparency, I think DNSSEC is essentially
moribund now.

~~~
belorn
MTA-STS is a Trust on First Use protocol (for those who has not read the RFC,
check section "10\. Security Considerations"). DANE with DNSSEC is not.

The benefits and drawbacks of TOFU is well known, and ssh is one where most
administrators first get a feel for it. In this case however we don't even
have any human validation, so it is blind trust on first use. Maybe future
version of popular email servers will hardcode a initial certificate or policy
for gmails and other major email provider, but that would be beyond the scope
of MTA-STS.

The same people who push DANE and DNSSEC yesterday will continue to do it
tomorrow. Adding caching and policy to starttls is good, and for major email
provider the first use will be done once and a valid version will effectively
remain in the cache forever since normal daily use will keep it up to date.
This scenario might not be as applicable to say a lawyer firm who for security
reasons run their own email server, where a larger potential number of cases
the initial email is the first time one email server connect to the other.

~~~
tptacek
The advantage of key continuity (the better term than "TOFU") over top-down
PKI is that key continuity works at scale, and PKI does not. As you note: key
continuity schemes admit to straightforward enhancements, like preload
registries, that PKIs don't.

I don't really want to go too far down this rabbit hole, but if a lawyer firm
came to us for advice and told us they run their own mail server "for security
reasons", we would tell them for security reasons to stop doing that.

Yes, people will continue advocating for and noodling around with DNSSEC, the
same way they do with PGP key servers and custom cipher cascades. But that's
not the test for whether a technology is successful --- at least not these
kinds of technologies. It is looking less and less likely --- I'd say we're
past the event horizon now --- that DNSSEC will ever be a mainstream component
of the Internet security model.

~~~
belorn
We have had a similar protocol for TOFU on the web for a very long time called
HTTP Public Key Pinning, and it did nothing to deprecate PKI. It is a bit
telling that google actually removed HTTP Public Key Pinning in 2017 from
chrome.

I can't speculate if DNSSEC can continue grow or will fall in use in some
unspecified future, but I suspect that a TOFU version of key pinning for email
server won't be the death knell. If it work it is because the wast majority of
email traffic is located in basically a handful of companies, which is why the
wast majority of domain owners won't notice a difference. I would assume
Microsoft already pins the certificate of Google servers and vice verse.

~~~
tptacek
I'm not saying that global key continuity schemes always work, only that they
have worked (SSH is the best-known example), where global PKI schemes have
never once worked.

 _Late edit:_

But note: Google didn't follow up the deprecation of HPKP by promoting DANE.
Rather: CT is working, and given that, HPKP wasn't worth the hassle. CT
doesn't depend on DNSSEC either!

~~~
kortilla
>(SSH is the best-known example), where global PKI schemes have never once
worked.

I’ve seen PKI work for SSH in $large-gov-branch. It works just fine but it
requires a cert infra most orgs don’t want.

~~~
tptacek
PKIs certainly work in enterprise settings.

------
LeonM
> SMTP is therefore vulnerable to man-in-the-middle attacks. Man-in-the-middle
> is an attack where communication between two servers is intercepted and
> possibly changed without detection.

While it's true that MTA-STS can protect email in transit from downgrade
attacks, it is not intended to prevent changes to email content. In fact, even
with perfect MTA-STS adoption it still won't prevent the MTA itself from
changing the message contents (the message passes through every MTA
unencrypted).

If you want to protect the authenticity of your email, use DKIM. If you want
to prevent MTA's from stripping the DKIM header, use DMARC.

Google also uses ARC to sign messages, but that's not end-to-end like DKIM is.

------
dane-pgp
For the record, Gmail already includes an indication for when an email wasn't
received (or won't be sent) using TLS:

[https://blog.google/products/gmail/making-email-safer-for-
yo...](https://blog.google/products/gmail/making-email-safer-for-you-posted-
by/)

and currently this applies to roughly 5% of emails:

[https://transparencyreport.google.com/safer-
email/overview](https://transparencyreport.google.com/safer-email/overview)

It would be nice to get this number down to zero, across all email providers,
perhaps by some combination of harsher warnings in the UI, penalising the
deliverability of insecure messages, and even legal action.

In terms of the latter, I note that the EU's recent NIS Directive could
potentially lead to such actions being taken:

[https://digitalguardian.com/blog/what-nis-directive-
definiti...](https://digitalguardian.com/blog/what-nis-directive-definition-
requirements-penalties-best-practices-compliance-and-more)

~~~
spc476
Lovely, running my own email server could be punishable by jail time. And
people bitch about the continuing consolidation and centralization of the
Internet ...

~~~
dane-pgp
You're welcome to run your own insecure email server, but don't expect other
mail servers to connect to it, or accept connections from it.

Also, don't allow other people to send or receive email from that server
unless they have given you their informed consent that it does not meet the
basic industry standards for security.

~~~
kortilla
Sure, and servers should refuse to connect and deliver mail to gmail.com
addresses without consent from the recipient that their email can be read by
Google employees and any government with the jurisdiction to compel them since
they don’t offer email encryption.

Your definition of “basic industry standards for security” is not the same as
others who are serious about security and it’s not the same as people slinging
birding newsletters.

The fact that legal action to fit your taste is being suggested is pretty tone
deaf.

~~~
dcbadacd
You're just strawmanning now.

------
js2
> When sending mail to a mailbox at a subdomain, compliant senders MUST NOT
> attempt to fetch a policy from the parent zone. Thus, for mail sent to
> "user@mail.example.com", the policy can be fetched only from
> "mail.example.com", not "example.com".[0]

That's not great for those of us who like to use Fastmail's
anything@user.example.com feature.

This specification also doesn't work well for those who run their own SMTP
servers and who are less likely to have cached policies. Meanwhile, the big
email providers could hard-code a list of the other big email providers and
never downgrade when talking to them (as I imagine they already do).

So who's this spec for, then?

0\.
[https://tools.ietf.org/html/rfc8461#section-3.4](https://tools.ietf.org/html/rfc8461#section-3.4)

------
technion
I'd like to be wrong, but with the nature of this standard, I don't expect
heavy adoption. If a person is deploying G Suite or Office 365 or similar,
they get asked to setup MX records, TXT for SPF, possibly DKIM and so on. If I
could create a record that says "use the policy Microsoft/Google publish", it
would be a no brainer. And it would take off because, much like SPF, these
groups can just add it to their onboarding checklist.

As soon as you say "deploy an end point on your domain", it falls in the too
hard basket for unimportant domains. Moreover, in a corporate situation the
people running mail have no involvement in web endpoints. For the mail domains
I professionally manage, that falls into the domain of another department, and
the people involved in running web endpoints are going to say something like
"if it was important, Wordpress would do it already for us".

~~~
megous
> The Policy Host DNS name is constructed by prepending "mta-sts" to the
> Policy Domain.

All the adopter has to do is set:

    
    
      mat-sts.his-domain A IP-OF-MAIL-HOST
    

or

    
    
      mat-sts.his-domain CNAME HOST-NAME-OF-MAIL-HOST
    
    

And the mail hoster can take care of the reset, including getting a
certifiacte for mat-sts.his-domain, and hosting a web server.

It's just more DNS records.

~~~
icebraining
You also have to set

    
    
        _mta-sts.his-domain TXT "v=STSv1; id=[POLICY VERSION ID];"
    

And you have to update that ID every time the policy hosted on the web server
changes.

------
amaccuish
I deployed this a few days ago using postfix-mta-sts-resolver in docker, spun
up an nginx server to handle the txt file, and added the dns txt record.
Fairly straightforward. I'll keep an eye on my logs and see if it changes
anything.

I also note that google is in the starttls-policy [1] list in testing mode
(they're also on testing, not enforced, for mta-sts on gmail.com [2])

[0] [https://github.com/Snawoot/postfix-mta-sts-
resolver](https://github.com/Snawoot/postfix-mta-sts-resolver) (this is more
up-to-date than the PyPI package)

[1] [https://starttls-everywhere.org/policy-list/](https://starttls-
everywhere.org/policy-list/)

[2] [https://mta-sts.gmail.com/.well-known/mta-sts.txt](https://mta-
sts.gmail.com/.well-known/mta-sts.txt)

~~~
Snawoot
If you are concerned, for both MTA-STS and STARTTLS-Everywhere you may use
enforcing policy even against domains in testing mode at the cost of small
possibility of delivery failure.

postfix-mta-sts-resolver has config option strict_testing: true

starttls-policy-cli has Early Adopter mode of config generator (-e, --early-
adopter).

------
shirro
I don't get this standard. Why have a https lookup of policy. I have a signed
dns. I publish information about services and trust on there. Why don't google
just accept dnssec or if they think it is broken then fix it. I have dnssec
with tlsa, caa, spf, dmarc, dkim already in my dns. Now I need to maintain a
file on a web server as well?

~~~
phicoh
From
[https://support.google.com/a/answer/9276511](https://support.google.com/a/answer/9276511)

version: STSv1 mode: testing mx: mail.solarmora.com mx: *.solarmora.net mx:
backupmx.solarmora.com max_age: 604800

It is just fascinating how people who dislike DNSSEC are recreating it over
HTTPS. Poorly, because unlike DNSSEC, this has obvious downgrade attacks.

In the end you have to trust DNS anyhow, because if you control someone's DNS,
getting a letsencrypt cert takes only a few seconds.

~~~
tptacek
This standard is nothing remotely like DNSSEC. It's a bottom-up key-continuity
mechanism. DNSSEC is a top-down global PKI.

~~~
phicoh
From RFC 8461, Section 4.2: "The certificate presented by the receiving MTA
MUST not be expired and MUST chain to a root CA that is trusted by the Sending
MTA."

(And Section 3.3: "During the TLS handshake initiated to fetch a new or
updated policy from the Policy Host, the Policy Host HTTPS server MUST present
an X.509 certificate that is valid for the "mta-sts" DNS-ID [RFC6125] (e.g.,
"mta-sts.example.com") as described below, chain to a root CA that is trusted
by the Sending MTA, and be non-expired.")

There is nothing bottom-up about this. Either you get a cert from CA trusted
by Google, or you don't get any email from gmail.com.

There is a lot that can be said about ICANN, but I prefer to trust those
processes over making sure that my certs are trusted every random company that
I need to receive e-mail from.

~~~
tptacek
No, it's bottom-up in that it's deployed at endpoints and does not require
universal deployment, or root-to-branch continuity, in order to function.
DNSSEC requires a global PKI, with cryptographically signed delegations from
the DNS roots through TLDs run by governments all the way to every involved
system; it's only been in the last 10 years that it has even been
technologically possible to accomplish this (MTA-STS could have been deployed
in 2005).

MTA-STS doesn't prevent non-TLS SMTP servers from functioning; all it does is
ensure that if you _have_ TLS, that attackers can't strip it.

If you have enough faith in ICANN to vest control of Internet trust in them,
that's, well, you do you.

~~~
phicoh
DANE doesn't require universal deployment of DNSSEC either. The sending mail
server only needs DNS resolvers that are transparent to DNSSEC. Which is just
about everything. And you can also run a modern recursive resolver on mail
server itself if you are behind an old one.

DANE does not prevent non-DNSSEC or non-TLS SMTP servers from functioning. And
of course, it actually prevents MITM attacks from stripping TLS.

Just about every 'government run' ccTLD is DNSSEC signed. There is nothing
that prevents a site from using DNSSEC.

The gTLDs are not government run. There is no government involvement in
google's TLD (.google). And because of ICANN rules, .google is actually DNSSEC
signed.

So can we use DNSSEC for email today. Everything is in place and if you don't
like governments, stick to gTLDs.

~~~
tptacek
Ostensibly, you're saying, _not all_ of the gTLDs are government run. Of
course, the most important TLDs are in fact run by governments, in particular
the FVEY SIGINT governments and China.

.GOOGLE is "actually DNSSEC signed", but, of course, GOOGLE.COM (and
GMAIL.COM) --- the domains that actually matter --- aren't.

My purpose on this subthread isn't to litigate DNSSEC, but rather to back up
the rather straightforward observation that MTA-STS is a bottom-up point
solution that doesn't depend on the deployment of a global PKI, and that DANE
is the opposite of that. The two aren't comparable. As I said, MTA-STS could
have been deployed in 2005, or, for that matter, all the way back into the
Netscape TLS days.

Since the purpose of MTA-STS is to avoid DNSSEC (that's not my observation,
it's stated directly in the RFC), and the standard's foremost and first
adopter is Google, which, like virtually every major tech company excepting
Cloudflare (which sells DNSSEC services), does not use DNSSEC, I think we can
safely predict that we will not be using DNSSEC for email today.

~~~
phicoh
Maybe you can expand a bit on how the receiving MTA can have certificates
(both for the HTTPS part and the SMTP-TLS part) that are signed by a CA
trusted by the sender?

Currently we have only one system for doing that (at scale) and that is the
current global PKI system. The situation would have been much worse 10 years
ago because many organizations were not using HTTPS at the time, partly
because obtaining certificates was expensive and a lot of work.

DNSSEC has a single root which is recognized by everybody doing DNSSEC.

In contrast, the collection of TLS CAs is only losely defined. For example,
there is a java application that I use. The java libraries do not recognize
the CA used by the Dutch government. So after each update of the libraries,
things start failing again. We can expect the same for MTA-STS unless
everybody sticks to the CAs that are trusted by common browsers.

Bottom-up security doesn't work on a global scale. It somewhat works for ssh,
because that is mostly local. It completely fails to work at scale for pgp.

~~~
tptacek
At this point I'm just happy to see we're on the same page about MTA-STS being
a bottom-up mechanism. I don't really care whether you think it will work
well. MTA-STS addresses a problem I myself don't much care about (I'm
convinced email security is an oxymoron). I'm interested in it primarily for
the signal it sends about major providers intentions with respect to DNSSEC.

------
upofadown
If you are likely to be attacked by an entity that can do a MITM between email
servers, you are already well beyond the level of threat where you need to
encrypt end to end. This isn't very interesting.

------
zeroimpl
Can somebody explain why this couldn't be as simple as adding a DNS TXT entry
which says to use TLS for a specific domain? Then add a large TTL on this DNS
entry so it can be cached for a week or more.

If it was that simple, I'd turn this on now.

~~~
hannob
DNS is usually not secure. DNSSEC is not deployed widely. End of story.

~~~
josteink
All security of everything on the internet relies on DNS.

If the problem is that DNS isn’t secure, nothing is, and DNS should be fixed
first instead of fucking up every other internet protocol instead with crappy
bandaids. That’s just obvious engineering.

The people behind this spec are obviously incompetent or have ulterior
motives.

~~~
tptacek
Virtually none of the security of the Internet depends on the security of the
DNS; not depending on DNS for security has been an explicit design goal of
Internet cryptography since the mid-1990s, which is, for instance, why IPSEC
and DNSSEC evolved separately (DNSSEC was a DoD project spearheaded by TIS).

------
lvh
Thing I don't understand about the MTA-STS spec and glossed over until someone
pointed it out to me: there's both an `id` in the DNS record (which is
supposed to refer to the specific policy uniquely, but can be anything e.g. a
hash or an incrementing identifier) _and_ the policy itself has a max_age. I
don't quite understand why the max_age itself isn't sufficient, since that
does expiry anyway? (The stated reason is preventing an HTTPS lookup, but HTTP
already has a fine cache mechanism so that sounds like a potential false
economy.)

~~~
Snawoot
"Cache" term in MTA-STS is misleading. Standard encourages to fetch new policy
even before expiration of cached copy. If you have some cached policy and "id"
is not updated since then, you may skip actual request to policy server via
HTTPS.

In MTA-STS "cache" is more like fallback minimum known to sending party.

~~~
lvh
But why have that mechanism when HTTP already has a caching mechanism? Is it
really "skip that HTTP request"?

~~~
Snawoot
RFC 8461 Section 3 states:

"These TXT records additionally contain a policy "id" field, allowing Sending
MTAs to check that a cached policy is still current without performing an
HTTPS request."

So, yes, it is "skip that HTTP request".

Despite HTTP(S) has caching rules defined, they are just different from
"caching" logic incorporated in MTA-STS. Key differences are: 1\. Sending
party ought to update MTA-STS policy for recipient domain far before it
expires. 2\. Sending party can check if policy is still actual without direct
contact with policy server by mean of retrieving id in TXT record. That
significantly reduces amount of requests policy server has to serve in order
to keep all senders up to date with its latest STS policy. Normally, HTTPS
requests occur only once from each sender per policy version. 3\. Sending
party must reuse cached policy if STS policy of recipient suddenly disappeared
without trace or failed to fetch for other reasons.

In a nut shell, "cache" and "max-age" in MTA-STS has different interpretation
than in HTTPS and require some additional (obscure) logic for processing.

------
ge0rg
So this obviously doesn't solve the initial-connection issue (where it relies
on untrusted DNS for discovery... if only we had DNSSEC).

But for later connections, it is essentially defining a caching of:

\- a boolean flag that a trusted certificate is to be used

\- a flag whether violations are to be reported to an endpoint obtained from
untrusted DNS

\- a maximum age of this "policy"

how is it superior to:

\- just querying / dumping this policy as informational headers after STARTTLS
(possibly guarded by a new EHLO feature)

\- TLS TACK ([https://tools.ietf.org/html/draft-perrin-tls-
tack-00](https://tools.ietf.org/html/draft-perrin-tls-tack-00)), which is kind
of abandoned, but is an equivalent to HSTS, just at the correct layer

and how does it solve the problem that even if you have a policy defined, a
MitM attacker can just redirect all policy reports with a very-long-lived
_smtp._tls.example.com DNS record pointing to their own property or to
nowhere?

------
lvh
There's a lot to like here, but two things I wish were different:

> MTA-STS policy suggestions in the security center are available to G Suite
> Enterprise and G Suite Enterprise for Education customers only.

MTA-STS policy suggestions do not seem like a serious differentiator for
Enterprise GSuite.

Secondly: it'd be awful nice for ease of deployment if GSuite would just like,
host that policy file for me? That way I still need to set 2 records (the TXT
record and a CNAME), but at least I'm not in the business of hosting HTTP.

(I imagine what this will look like is a Terraform module.)

------
pwinnski
MTA-STS only helps when the providers on both end use it. This post doesn't
seem to say: will there be anything in the interface to indicate whether a
message transmitted via MTA-STS or not?

~~~
LeonM
A message is not 'transmitted via MTA-STS', it is transmitted via SMTP that
uses TLS (SSL) to secure the connection between mailservers.

MTA-STS [0] is a method to publish a policy on whether email servers (known as
Mail Transfer Agents, or MTA's) are allowed to use insecure (non-TLS)
connections for email from your domain.

MTA-STS is needed because the system to deliver email over the internet (SMTP)
has a fallback method where it will switch to an unencrypted connection if the
encrypted connection fails for some reason. By blocking a encrypted connection
in the middle, an attacker can force a mailserver to fall-back to a non-
encrypted connection. This way the attacker can intercept the message in
transit. This is known as a downgrade attack. Some governments are known for
doing this.

So, MTA-STS prevents downgrade attacks (to a certain extend, because the MTA's
that your email passes through must support it).

There is also a new proposed standard called TLS-RPT [1] that allows for
reporting the usage of TLS, so you know if your MTA-STS policy caused an email
delivery to fail.

At Mailhardener [2] we are working on hosted MTA-STS and TLS-RPT integration
(both features are still in closed beta for now). It's great to see Gmail
adopting MTA-STS, as this will accelerate adoption globally.

[0] [https://tools.ietf.org/html/rfc8461](https://tools.ietf.org/html/rfc8461)
[1] [https://tools.ietf.org/html/rfc8460](https://tools.ietf.org/html/rfc8460)
[2] [https://www.mailhardener.com](https://www.mailhardener.com)

~~~
tptacek
It's great and unsurprising to see them adopting MTA-STS, since their name is
on the RFC.

------
thepangolino
It boggles my mind how a client side proper and user friendly implementation
of PGP has has always been dismissed as some silliness.

~~~
lucb1e
Depends on where you are. As a Dutchman that moved to Germany, in NL it's
somewhere between geeky and annoying for the recipient when you use PGP,
whereas when communicating with potential employers in Germany, it's not even
talked about. It's just the standard thing to use.

Since I've moved, every time I see PGP being dismissed as too hard to use, I
feel like I'm back in some echo chamber where people just keep repeating that
and start to believe it.

~~~
0xb100db1ade
> when communicating with potential employers in Germany, it's not even talked
> about. It's just the standard thing to use.

Did I read that correctly? PGP is popular in Germany?

If so, I'd love to hear more please!

~~~
lucb1e
Curse of knowledge - I forgot that it's not obvious that I'm a security
person! Should have mentioned that!

So yes it's popular... in the security community. In the Netherlands, it was
also used, but usually reluctantly when the other party asks for it and it
cannot politely be refused.

------
garaetjjte
So now to send email over SMTP it is required to host policy on.. HTTPS
server? (or else all your mail will end up in spam?) Why it isn't just extra
TXT DNS record indicating that TLS is required?

EDIT: I think DANE TLSA records are already doing that.

------
e12e
So, this is require-tls-on-first-ns-lookup? If dns isn't mitm'd, you'd get a
flag requiring tls;this can/should be cached - and fallback to plaintext smtp
(no tls) be disabled? Is that the gist?

------
vzaliva
I do not understand why for over a decade Google resists implementing end-to-
end encryption in Gmail.

For example, it would help with "man-in-the-middle" attacks they are citing as
motivation from MTA-STS.

~~~
LeonM
Because there is no practical method to do so. Email was never designed to be
end-to-end encrypted and implementing end-to-end encryption would mean that
everybody must switch to an end-to-end encryption capable protocol.

Google is not resisting, they would implement end-to-end if they could, but
they can't.

FWIW: As long as the email does not leave Google (i.e. an email between 2
gmail inboxes) it is actually already encrypted end-to-end (AFIAK).

~~~
OrgNet
They could easily do it for communications between gmail users... they just
don't want to do it.

> FWIW: As long as the email does not leave Google (i.e. an email between 2
> gmail inboxes) it is actually already encrypted end-to-end (AFIAK).

no, end-to-end means from user1-to-user2, not from user1-to-gmail and then
from gmail-to-user2 (ie: gmail should never be able to see the content of your
communications if it was truly end-to-end)

------
moocowtruck
If there is one thing I am so happy I could cry about.. it's when I stopped
managing mail systems.

------
ihonius
.

------
svnpenn
obligatory

[https://github.com/dominictarr/your-web-app-is-
bloated](https://github.com/dominictarr/your-web-app-is-bloated)

------
eitland
> Post a Comment

> You are welcome to contribute comments, but they should be relevant to the
> conversation. We reserve the right to remove off-topic remarks in the
> interest of keeping the conversation focused and engaging. Shameless self-
> promotion is well, shameless, and will get canned.

> Note: Only a member of this blog may post a comment.

Another victim of Goolge+?

~~~
ocdtrekkie
It looks like they're using Blogger's commenting system at the moment.

EDIT: It looks like this happened automatically, according to
[https://blogger.googleblog.com/2019/01/an-update-on-
google-a...](https://blogger.googleblog.com/2019/01/an-update-on-google-and-
blogger.html)

------
prolepunk
This looks a lot like SPF.

I've been looking if this has been implemented in Postfix and I found a past
HN thread on it --
[https://news.ycombinator.com/item?id=18091690](https://news.ycombinator.com/item?id=18091690)

There's this project that provides mta-sts implementation --
[https://github.com/ldelouw/postfix-mta-sts-
resolver](https://github.com/ldelouw/postfix-mta-sts-resolver)

Has anyone used it and what is your experience?

~~~
LeonM
MTA-STS is nothing like SPF.

SPF is a method to publish a policy on which senders are allowed to use your
domain so send email.

MTA-STS is a method to force MTA's to only use and accept TLS encrypted
connections when handling email send from your domain.

The MTA-STS resolver you linked to is used to implement MTA-STS capability in
Postfix MTA. It's intended for MTA administrators. You don't use the resolver
to setup MTA-STS for your own send email, for that you must setup a DNS record
and a HTTPS enabled webserver.

~~~
megous
> MTA-STS is a method to force MTA's to only use and accept TLS

It's still advisory information, like SPF. The other end has to implement it.

~~~
LeonM
That is correct. SPF, DKIM, DMARC, MTA-STS and TLS-RPT are all opt-in features
for the receivers.

One could say that email is the ultimate legacy product of the internet.

------
vkaku
Yeah, they do complicated things like this, but leave out simple fixes like
email accounts with dots in the address.

If a Googler is reading this, yes, I have a real problem with Gmail.

~~~
kiwijamo
I have a Gmail account with a dot in it. Works just fine. Yes you can leave
off the dot and/or add more dots. But there is nothing broken about that.

~~~
vkaku
It works fine, except when it doesn't. They let another guy sign up with dots
and I get his emails, letters from his girlfriend, bank statements and what
not.

And at some point, they stopped doing these erroneous signups.

But I still keep getting these emails because they strip all the dots and
relay them. This is just terrible.

I don't care about the -4 as much as I care about someone understanding how
serious this issue really is.

