Re: [dmarc-ietf] [PROPOSAL]: Timing data in aggregate reports
On Sun, Feb 19, 2023 at 1:01 PM Scott Kitterman wrote: > Thanks for checking. In that case, I particularly think we should not be > spending time on proposals like this. We should focus on finishing the > work we are chartered to do. > > Scott K > +1 Focus. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [PROPOSAL]: Timing data in aggregate reports
It appears that Murray S. Kucherawy said: >-=-=-=-=-=- > >On Sat, Feb 18, 2023 at 5:07 AM Alessandro Vesely wrote: > >> 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. >> > >I'm a little worried about scope creep here. Are we turning aggregate >reporting from something DMARC-specific into an all purpose delivery >reporting mechanism? I would more characterize it as mission gallop. So I agree, DMARC reports are DMARC reports, not anything else, and they should include other stuff (SPF and DKIM) only enough to help diagnore DMARC failures. DKIM replay is *not* a DMARC failure. If we end up tweaking DKIM somehow, DMARC can use the tweaked DMARC but that is way, way down the road. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [PROPOSAL]: Timing data in aggregate reports
On Sat, Feb 18, 2023 at 5:07 AM Alessandro Vesely wrote: > 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. > I'm a little worried about scope creep here. Are we turning aggregate reporting from something DMARC-specific into an all purpose delivery reporting mechanism? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [PROPOSAL]: Timing data in aggregate reports
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 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: 192.0.2.119 184 4 312 21 ... 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
Re: [dmarc-ietf] [PROPOSAL]: Timing data in aggregate reports
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 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: > > > > 192.0.2.119 > 184 > 4 > 312 > 21 > > ... > > 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 > smime.p7s Description: S/MIME Cryptographic Signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
