> On Mar 28, 2017, at 6:38 AM, Federico Santandrea
> <[email protected]> wrote:
>
> If we replace that with something along the lines of:
>
> o "date-time": The date-time indicates the start- and end-times for
> the report range. It is provided as a string formatted according
> to Section 5.6, "Internet Date/Time Format", of [RFC3339].
> "start-datetime" should be 0000 UTC of the relevant day or the
> first time a policy was discovered, whichever comes last.
> "end-datetime" should be 2400 UTC of the relevant day or the
> time the last cached policy did expire, whichever comes first.
>
> Then one would normally see reports for one whole day, except when one
> first publishes a policy and in abnormal situations where a policy
> has been allowed to expire with no new one available.
Not just when first publishing, but also when each new sending
system first discovers a policy, which will make for too much
noise in the reports.
Also, policy expiration will not be "abnormal". If I implement
STS, pre-expiration background policy refresh will not happen
in the absence of email to the destination domain. This avoids
unbounded fiiling of the cache with junk domains to which email
delivery has long ceased.
The simplest solution is to accept that STS covers ongoing
validation of email to frequently used domains, and is otherwise
subject to downgrade.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
