> On May 11, 2018, at 7:30 AM, Daniel Margolis <[email protected]> wrote:
>
> Because this attack is also possible upon refresh of a cached policy, we
> suggest
> implementers do not wait until a cached policy has expired before checking for
> an update; if senders attempt to refresh the cache regularly (for example, by
> fetching currently live policy in a background task that runs daily or weekly,
> regardless of the state of the `_mta_sts` TXT record, and updating their
> cache's
> "max age" accordingly), an attacker would have to foil policy discovery
> consistently over the lifetime of a cached policy to prevent a successful
> refresh.
Perhaps sufficient. I would in practice only refresh policies as a side-effect
of ongoing traffic, so that the policy database doe snot become an
ever-expanding
museum of every domain ever contacted, to many of which no further mail will be
sent. That's an implementation choice I guess that depends on the sender's
resources to cache an unbounded number of policies and likelihood to stop
sending
to some extant domains. MTA implementors will therefore need to figure out the
details for themselves...
Or this could mention that the refresh can be contingent on ongoing email
traffic to the domain so as to allow idle cached policies to expire.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
