> On Feb 23, 2017, at 3:35 PM, Daniel Margolis <[email protected]> wrote:
>
>> 2. It prevents new MX records (eg new servers for increased capacity or
>> backups) not covered by the cached policy from being used until the max_age,
>> or until a failure to send with all the covered servers.
This should be a non-problem. The DNS record exists precisely to signal
a requirement for "early" policy refresh. So when the domain's policy
changes, the DNS record policy "id" SHOULD change to alert remote caches
that the cached data is likely stale.
This applies whether or not the change is to the list of acceptable "mx"
hosts, or to some other property.
> So you've pointed out a somewhat subtle pitfall. If I deploy a policy
> with "mx: ['*.google.com']" and I later deploy additional MXs with
> higher priority on mail.google.net (and, because I'm smart, I
> remember to update my deployed policy), senders may nonetheless
> only send mail to the old .com MXs, resulting in an unexpected
> traffic imbalance.
Only if you're negligent, and fail to modify the DNS record.
Negligence can cause many other operational issues, there are
no designs immune to operator negligence.
> 2. This could be fixed if we said that senders MUST seek a
> new policy whenever some MXs are filtered out by policy
> application (5.2 step 2).
That's both unnecessary, and problematic. The issue is that
this condition is "sticky", until the policy matches the MX
RRset, the sender is in a constant "refetch" condition. It
is best to avoid this trigger. The DNS record triggers a
single update, and then its "id" is cached with the same
or any new policy.
> 3. This is optionally fixed by senders refreshing cached
> policies at an arbitrary time, which they may (but need not)
> do.
In addition to the text record trigger, senders should
attempt to opportunistically (not triggered by DNS
changes) refresh the policy at or after the midpoint
between the last retry attempt and the expiration (but
at least an ~1 hour after that attempt).
Thus when a policy is published for 90 days, and then the
policy server goes off-line, the retries would be (approx):
<= 45 days left
<= 22 days
<= 11 days
<= 6 days
<= 3 days
<= 36 hours
<= 18 hours
<= 9 hours
<= 4 hours
<= 2 hours
<= 1 hour
More retry attempts just short of expiration are likely pointless.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
