> On Sep 7, 2016, at 4:16 PM, Daniel Margolis <[email protected]> wrote:
>
> I don't think there's currently any language which actually requires the
> sender to temp-fail if they can't get a new policy despite the DNS indicator
> indicating they should--only that they must get a new policy upon a
> validation failure. So if the DNS refresh trigger says "refresh me!" but the
> old policy works, I think a compliant sender can safely simply deliver with
> the old policy. Is there a reason we would want to do otherwise? (Given that
> the DNS indicator has no security guarantee, we can't really rely on it
> working, after all...)
I've not made myself clear, when I said temp-fail, that was just the
HTTPS refresh, indeed the SMTP message goes on its merry way with the
cached policy, but because we (temp)failed to refresh the HTTPS policy,
we'll have to keep trying, so long as the DNS record signals a policy
change.
Therefore we can be in a state in which the DNS record signals a need
for HTTPS refresh, which tempfails repeatedly for a possibly long time.
During that time, it would be bad to make policy refresh attempts 1:1
for every message delivery. Should the spec advise a hold-down strategy.
The options are:
* Say nothing, leave implementations to do as they see fit.
* Suggest a minimum hold-down time of say 30 minutes (or whatever)
between refresh attempts.
* Let the originally retrieved policy publish a retry time
(as with DNS SOA records) that applies on failure. The SOA's model of
refresh/retry/expire may well
be quite applicable).
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
