I was thinking of current time minus t=, which should be the real flight time
from signature to verification. Thinking twice, it may also make sense to
report how much time was left (or beyond) w.r.t x=, that is x= minus current time.
Best
Ale
On Fri 17/Feb/2023 23:22:10 +0100 Wei Chuang wrote:
Which values were you thinking of reporting for the min/max/avg
statistics? Some time delta value exceeding the "x="? The DKIM delta
between "x=" values "t=" values?
Presumably this is to help report to the sender when their expiry value is
having trouble with some receiver/forwarder?
-Wei
On Fri, Feb 17, 2023 at 11:02 AM Alessandro Vesely <ves...@tana.it> wrote:
Hi,
how to set DKIM expiration (x=) is being discussed in the DKIM WG. Making
educated guesses requires some data. Aggregate reports are the right
place for
that. For example:
<record>
<row>
<source_ip>192.0.2.119</source_ip>
<count>184</count>
<min>4</min>
<max>312</max>
<avg>21</avg>
<policy_evaluated>
...
Min, max and avg are functions present in almost all packages that deal
with
collections, from DBMSes to programming languages. So adding them is just
a
few minutes more than what would be needed to upgrade to the new spec as
it is now.
I aired this idea in [ietf-dkim], and I'm looking forward to seeing the
same
reaction here. However, what about messages from the dmarc list for the
week
ending Sun Feb 19 06:00:04 2023?
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
