Re: [dmarc-ietf] Consensus Sought - Ticket #47 (Removal of "pct" tag) - With Interim Notes
+1 With Mr Levine's line of thinking. I also agree with keeping pct= tag. tim On Thu, Jun 3, 2021 at 7:16 PM Dotzero wrote: > > > On Thu, Jun 3, 2021 at 6:17 PM John Levine wrote: > >> It appears that Alessandro Vesely said: >> >On Thu 03/Jun/2021 05:45:33 +0200 Murray S. Kucherawy wrote: >> >> I don't understand what "demeaning a domain's policy" means. >> > >> >I meant to say that p=quarantine; pct=0 is to be considered a strict >> policy to >> >all effects. Saying so should prevent reasoning something like "Oh, >> they said >> >quarantine, but since pct=0 it is somewhat faked, so I'll skip X", where >> X >> >could be rewriting From:, displaying a BIMI image, record aggregate >> data, or >> >any other action that might depend on the policy. That is to say pct=0 >> does >> >not alter the value of p=, otherwise testing becomes a nightmare. >> >> If we agree that's what we mean, that's what we should say, e.g., add >> something >> like this: >> >> Senders may use pct=0 to signal an intention to apply a stricter >> DMARC policy in the future, and to request receivers that do special >> processing based on DMARC policy to do that processing. Examples of >> special processing might include mailing list software rewriting >> addresses in From headers. >> > > As long as we get the wording right, I agree with your line of thinking > John. Again, we don't have insight as to the extent that receivers will > honor the request. > > Michael Hammer > ___ > 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] Extensions in Aggregate Reporting - Feedback Requested
On Thu, Jun 3, 2021 at 8:48 AM Brotman, Alex wrote: > Hello folks, > > During our interim call last week the topic of extensions within the DMARC > aggregate report came up. There was a discussion about how to best > introduce these, but also how they might be best used. I noted three cases > that I could see today; ARC, PSD, and BIMI. And indeed we have tickets > relating to the first two. The original thought was that the aggregate > draft would allow a place for extensions, and then additional drafts would > define those within the IETF. When -02 was originally being worked on, > there was a thread about how we might like to see this, though not many > responses. The result is in section 4 of the -02 draft [1]. and I thought > we'd enhance that as we progressed. At the time, I didn't intend to limit > the extensions to IETF-approved extensions, though wasn't sure how else > this might be used by reporting entities (I mentioned domain reputation-ish > things during the call). I'd consider that if we don't enforce > IETF-registered extensions, the receivers could still > ignore extensions they don't want to handle. I'm also aware this could > bloat a report in terms of size, though we've already indicated we don't > seem overly concerned with the size of the XML body. A few things I'd like > to see the group reach consensus on are: > > 1) Extensions in their own section (as it is now) or within each > element > 2) Must extensions be IETF-approved > 3) If (2) is true, do we want to define any during the DMARCbis process > (essentially a demonstration of how it is to be done) > > Thank you for your continued feedback > > 1: > https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02#section-4 > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > 1) Extensions should be in their own extension and seperate from the core reporting. There is a reason we call them "extensions". 2) Extensions used in reporting under the standard should be IETF-approved. This is a standards body. Anyone can leverage standards for private use but our focus as an IETF working group is interoperability. By requiring IETF approval/registration it puts the extensions under IETF "Note Well" and makes the extension public. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested
I agree with Alessandro's suggestions, and really like the flexibility of self-labeled elements so they can be located where appropriate rather than forcing all extensions into a single bucket. My $0.02, Trent On 6/4/21, 3:27 AM, "dmarc on behalf of Alessandro Vesely" wrote: On Thu 03/Jun/2021 14:47:21 +0200 Brotman, Alex wrote: > > During our interim call last week the topic of extensions within the DMARC aggregate report came up. There was a discussion about how to best introduce these, but also how they might be best used. I noted three cases that I could see today; ARC, PSD, and BIMI. And indeed we have tickets relating to the first two. The original thought was that the aggregate draft would allow a place for extensions, and then additional drafts would define those within the IETF. When -02 was originally being worked on, there was a thread about how we might like to see this, though not many responses. The result is in section 4 of the -02 draft [1]. I have some comments about that attempt. First, it shows extensions right below , while it seems more useful to have them as child of . Second, I'm not sure we need an container. I'd go for an example like, say, so: https://urldefense.com/v3/__http://ietf.org/xml-namesapaces/dmarc-xml/1.0__;!!ORgEfCBsr282Fw!6SA4ihYzl7xfKdVfYDefKIsr4PotRb5Nkjs2hXHPyIU5KTpmffBFLkJEKqvwSJvF$ "> ... ... https://urldefense.com/v3/__http://ietf.org/xml-namesapaces/bimi-xml?*1.0__;Lw!!ORgEfCBsr282Fw!6SA4ihYzl7xfKdVfYDefKIsr4PotRb5Nkjs2hXHPyIU5KTpmffBFLkJEKvQ2pQn-$ "> ... ... ... ... ... https://urldefense.com/v3/__http://ietf.org/xml-namesapaces/bimi-xml?**A1.0__;Py8!!ORgEfCBsr282Fw!6SA4ihYzl7xfKdVfYDefKIsr4PotRb5Nkjs2hXHPyIU5KTpmffBFLkJEKtkFNC6p$ "> ... ... Third, we need to grasp how XML grammars can be composed, and insert it in Appendix A. > At the time, I didn't intend to limit the extensions to IETF-approved extensions, though wasn't sure how else this might be used by reporting entities (I mentioned domain reputation-ish things during the call). I'd consider that if we don't enforce IETF-registered extensions, the receivers could still ignore extensions they don't want to handle. I assume no one reads the XML directly, except for debugging. If report consumers don't know about an extension, its content will never reach human eyeballs. Extension existence will have to be advertised, and a IANA page could be a decent means of doing that. > I'm also aware this could bloat a report in terms of size, though we've already indicated we don't seem overly concerned with the size of the XML body. A few things I'd like to see the group reach consensus on are: > > 1) Extensions in their own section (as it is now) or within each element Both, and both optional. An extension can have some data to add in some , but not necessarily in all of them. > 2) Must extensions be IETF-approved We cannot stop non-registered extensions. Yet, developers may want to see an RFC before implementing code that extracts a given extension's content. > 3) If (2) is true, do we want to define any during the DMARCbis process (essentially a demonstration of how it is to be done) It would be a good way to show how to define them. Not our primary task, though. Best Ale -- > 1: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02*section-4__;Iw!!ORgEfCBsr282Fw!6SA4ihYzl7xfKdVfYDefKIsr4PotRb5Nkjs2hXHPyIU5KTpmffBFLkJEKtSg8JaH$ ___ dmarc mailing list dmarc@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!6SA4ihYzl7xfKdVfYDefKIsr4PotRb5Nkjs2hXHPyIU5KTpmffBFLkJEKn_Uzf5Y$ ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested
On Thu 03/Jun/2021 14:47:21 +0200 Brotman, Alex wrote: During our interim call last week the topic of extensions within the DMARC aggregate report came up. There was a discussion about how to best introduce these, but also how they might be best used. I noted three cases that I could see today; ARC, PSD, and BIMI. And indeed we have tickets relating to the first two. The original thought was that the aggregate draft would allow a place for extensions, and then additional drafts would define those within the IETF. When -02 was originally being worked on, there was a thread about how we might like to see this, though not many responses. The result is in section 4 of the -02 draft [1]. I have some comments about that attempt. First, it shows extensions right below , while it seems more useful to have them as child of . Second, I'm not sure we need an container. I'd go for an example like, say, so: http://ietf.org/xml-namesapaces/dmarc-xml/1.0;> ... ... http://ietf.org/xml-namesapaces/bimi-xml?/1.0;> ... ... ... ... ... http://ietf.org/xml-namesapaces/bimi-xml??/1.0;> ... ... Third, we need to grasp how XML grammars can be composed, and insert it in Appendix A. At the time, I didn't intend to limit the extensions to IETF-approved extensions, though wasn't sure how else this might be used by reporting entities (I mentioned domain reputation-ish things during the call). I'd consider that if we don't enforce IETF-registered extensions, the receivers could still ignore extensions they don't want to handle. I assume no one reads the XML directly, except for debugging. If report consumers don't know about an extension, its content will never reach human eyeballs. Extension existence will have to be advertised, and a IANA page could be a decent means of doing that. I'm also aware this could bloat a report in terms of size, though we've already indicated we don't seem overly concerned with the size of the XML body. A few things I'd like to see the group reach consensus on are: 1) Extensions in their own section (as it is now) or within each element Both, and both optional. An extension can have some data to add in some , but not necessarily in all of them. 2) Must extensions be IETF-approved We cannot stop non-registered extensions. Yet, developers may want to see an RFC before implementing code that extracts a given extension's content. 3) If (2) is true, do we want to define any during the DMARCbis process (essentially a demonstration of how it is to be done) It would be a good way to show how to define them. Not our primary task, though. Best Ale -- 1: https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02#section-4 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
