On Wed, Aug 16, 2017 at 02:39:43AM +0200, Ayke van Laethem wrote:
> 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 take over the domain, they presumably also take over DNS.
If they don't intent to implement STS, they will not publish the
TXT record, which is a change in the TXT record, and thus any cached
policy should trigger a refresh attempt.
For that refresh attempt to cause the policy to be flushed there
would actually need to be an HTTPS server serving a "none" 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.
Yes, the new domain owner would have to know that the domain had
STS< or just publish a "none" policy in case there was a previous
policy in place. The difficulty is of course how long such a "none"
policy should be in place. For this to be a manageable duration,
there should be a maximum "max_age" that sending systems accept,
with any higher values truncated to that maximum.
> 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.
Yes, with the limit imposed by each sender and a "SHOULD NOT" on publishing
max_age beyond that limit for receiving domains.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
