Re: [dmarc-ietf] Comment on DMARCbis, was draft-ietf-dmarc-psd

[Jane Moneypenny <[e-mail]>]

> 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 <[e-mail]> 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 [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc