On 27/03/2017 13:41, Daniel Margolis wrote:
Anyway, I'm very open to suggestions on how to make this more
transparent within the scope of TLSRPT, but I don't love the idea of
adding policy complexity by letting recipients specify what to do in
this scenario.
To allow the receiving domain owner to spot abnormal situations without
complicating the report, we could add semantics to the date-range.
The draft says:
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]. The
report should be for a full UTC day, 0000-2400.
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.
In that case it will be clear that for some part of the day no policy
was considered, which can be expected (if the domain doesn't publish a
policy anymore) or unexpected (network problems/attacks on the sending
MTA or, if the problem is widespread across senders, possible
misconfiguration of denial of service on records or endpoints).
If in the same day a policy is discovered again after a previous one
has expired, then we would have more than one report for that day:
for instance, one from 0000 to the time the policy had expired, and
another one from the time a new policy had been discovered to 2400.
So the gap during which no policy applied would be evident.
--
Federico
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
