> On Feb 23, 2017, at 3:35 PM, Daniel Margolis <[email protected]> wrote:
>
>> Having pondered it a bit, my suggestion is:
>> 1. A SHOULD that max_age is set to at least 6 months, other than during
>> roll-out
>> 2. A SHOULD that well-behaved clients with a cached policy should re-check
>> DNS TXT policy weekly, and retrieve via HTTPS if the policy id has changed.
>
> I think the phrasing you give here suggests that if I send
> mail to your domain less than once a week, I should run a
> cron job to refresh the cache--and I hate cron jobs.
That's extremely unlikely to be implemented in Postfix, for example.
To avoid a "roach motel" policy cache, refresh will be driven only
by actual mail flow.
The DNS record needs to be specified as the primary trigger for "early"
refresh, wil an optional refresh when >50% of the time from last refresh
to expiration has elapsed and sufficient (say 1 hour or more) time remains
that the policy isn't about to be refreshed due to actual expiration. A
frequency cutoff avoids firing refresh triggers minutes or seconds apart
close to expiration.
> So to be slightly pedantic, would it work just as well to say senders
> SHOULD check for an updated policy if using a policy which is older
> than one week? (My phrasing may be unclear, but I mean, of course,
> that they need only check for an updated policy if they are otherwise
> sending mail to that domain anyway.)
See proposed scheme. It has no artificial scale (1 week), and is instead
based on the policy lifetime. Sending systems should probably cap the
policy lifetime on their end to something sensible (shorter for sites
that send lots of mail, and are unlikely to not contact a given peer
for a long time, longer for sites that don't send much mail). So
if a receiving system advertises a 100-year policy, something more
sensible will be stored in the sending side.
> Of course, we could still simply suggest/require senders *always*
> check for a new policy--it's one more DNS lookup to the recursive
> resolver per-send--but I bet in some implementations there are
> good reasons not to do this.
If/when Postfix implements STS, the DNS id will be checked for each
new SMTP connection. Changes in the DNS id will trigger (background)
policy refresh. Non-changes in the DNS id will continue to use the
cached policy until it is 50% closer to expiration since the last
refresh (with a sensible cutoff).
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
