> For a second issue, consider whether report generators should track policy > changes during the day and, in case, send multiple reports with different > PolicyPublished. Otherwise, PolicyPublished would be valid for only a part of > the reported rows, presumably the last. Is that acceptable? >
Shall the "policy tracking" mechanism take into consideration:- - TTL, - DNS cache issues? Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, February 6, 2020 7:44 PM, Alessandro Vesely <[email protected]> wrote: > On Tue 04/Feb/2020 22:26:30 +0100 Murray S. Kucherawy wrote: > > > On Tue, Feb 4, 2020 at 1:20 PM Scott Kitterman [email protected] wrote: > > > > > I agree on DMARCbis. I don't think advancing this draft has a significant > > > effect on that. Worst case, if DMARCbis is done before we can reach any > > > conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in > > > it. > > +1, albeit I don't think DMARCbis arrives so quickly > > > I think we've always been assuming that PSD DMARC would be input to > > DMARCbis, so we were planning to start the latter but not close it until > > the former was completed. This is the first time I've seen a different > > suggestion. > > I'd love to hear more opinions about ordering of the work here. This seems > > like an ideal time to review and update our milestones. > > There are quite some issues about DMARC. Let me mention aggregate report > format first, as this brings out a third thing which can be done in parallel, > namely to publish http://dmarc.org/dmarc-xml/0.2. > > Various tweaks have been proposed, I think they're well summarized in > http://bit.ly/dmarc-rpt-schema > > For a second issue, consider whether report generators should track policy > changes during the day and, in case, send multiple reports with different > PolicyPublished. Otherwise, PolicyPublished would be valid for only a part of > the reported rows, presumably the last. Is that acceptable? > > Another case for sending multiple reports at once is on hitting size limits. > Is better to increase sending frequency instead? How to negotiate sending > frequency between report consumer's ri= and producer's conditions deserves > some > discussion. > > I'm sure there's a bunch of other issues, and we should start to collect them. > > > > I don't see anything about PSD DMARC being inherently on the critical > > > path for DMARCbis. I suspect the current major obstacle to DMARCbis is > > > that the question of how to take the PSL out of the equation is unsolved, > > > despite one IETF WG that was supposed to be dedicated to the question.>> > > > I don't think not publishing PSD DMARC helps move DMARCbis forward, so I > > > think it's a false choice.>> > > > > I think what Dave proposed about PSL separation from DMARC is entirely > > appropriate and pragmatic, and in fact probably easy enough: DMARC is > > changed so that it says the organizational domain is determined using some > > process [currently] external to DMARC, and then a second document explains > > how that process is accomplished using the PSL (and/or PSD, depending on > > when the experiment result comes in). That's a fairly simple edit overall, > > and is actually probably minor and non-controversial compared to some of > > the other surgery that I believe is in the queue. > > +1, let DMARC core defineorganizational domain by characteristics. A second > document present a process, possibly demonstrating how the required > characteristics are met. > > Scott's I-D already outlines the characteristics of Branded and > Multi-organization PSDs, that the experimental processes are suited for. > > Best > Ale > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
