|
|
|
|
|
by ivanr
2913 days ago
|
|
Additionally, MTA-STS has recently been approved as Proposed Standard, so we may see increased support for it in the near future. [1] The key advantage of MTA-STS is that it can be deployed quickly, without almost any disruption of the already-deployed infrastructure. Of course DNSSEC and DANE already solve the same problem, but MTA-STS is the designed by and for people who don't want to use DNSSEC. The EFF's efforts are complementary to MTA-STS. As schoen mentioned elsewhere on this thread, in the early days it's probably useful to have a preload list. (That said, I am not sure why they feel it necessary to cast MTA-STS in negative light: "[...] so the sender will never know the recipient supports STARTTLS." [2] They should explain that there MTA-STS is trust on first use and has a memory effect, exactly like the well-accepted HTTP Strict Transport Security.) We added support for MTA-STS testing to Hardenize just today, along with a blog post that explains the background and explains how to deploy it. [3] (Disclaimer: Hardenize founder.) [1] https://www.ietf.org/mail-archive/web/ietf-announce/current/... [2] https://www.eff.org/deeplinks/2018/06/technical-deep-dive-st... [3] https://www.hardenize.com/blog/mta-sts |
|