I see a potential issue with very long max_age rules. Consider that the domain name example.org is sold to someone else, but the previous max_age in the policy was set at 10 years and various hosts (e.g. gmail.com) have sent email to example.org and thus have a cached policy. So if the new owner of example.org decides to add email, they *have to* also implement STARTTLS with the given MX hosts in the previous policy (which will often be impossible due to moving to a different email provider), or publish a new MTA-STS policy. If they don't know MTA-STS was used before, sending email will not work from some domains, without a clear signal as to why this is the case.
Note that setting up MTA-STS requires some effort above simply setting up email itself (setting up STARTTLS, setting up a new mta-sts domain, obtaining a certificate, serving a new policy file). It is also not like HSTS: with HSTS the only requirement is enabling HTTPS, but with MTA-STS many more things need to be configured to override or adhere to a cached policy. My suggestion would be to add to the description of max_age that long durations may not always be desirable. Another option is to limit max_age to one year, similar to how HTTP used to limit caching to one year [1][2]. Also see [3]. This is not a perfect solution, but it will reduce the size of the problem. [1]: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3 [2]: https://tools.ietf.org/html/rfc7234#section-5.3 [3]: https://github.com/mrisher/smtp-sts/blob/master/mta-sts.md#denial-of-service _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
