Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis
Fine with me, just wanted to ask the question. -MSK, hatless On Mon, Aug 7, 2023 at 1:48 PM Barry Leiba wrote: > Indeed. We can do what we've done in other cases: create a registry > if/when we add something else later. > > Barry > > On Mon, Aug 7, 2023 at 4:11 PM Scott Kitterman > wrote: > > > > > > > > On August 7, 2023 7:47:03 PM UTC, "Murray S. Kucherawy" < > superu...@gmail.com> wrote: > > >On Sat, Aug 5, 2023 at 1:09 PM Tim Wicinski wrote: > > > > > >> Based on the ABNF in -28, how about something like this: > > >> > > >> > > >> dmarc-method = "dkim" / "spf" > > >> > > >> dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method) > > >> > > >> > > >> I think this "should"(*) allow for all permutations but also > simplifies > > >> it, and I agree with Barry it should be simpler. > > >> > > > > > >This looks good to me, except to be consistent with DKIM (from which > this > > >general syntax was borrowed) I'd suggest: > > > > > >* using colon as the separator rather than comma > > >* WSP and CFWS should follow whatever we did for other tags > > >* don't allow an empty list; I can't think of any DKIM or DMARC tag that > > >accepts a list and also allows an empty value > > > > > >If we think we might add "arc" or something else in the future, do we > need > > >a registry of supported methods? If not, we'll have to rev DMARC every > > >time a new one comes into favor. > > > > I think we don't need a registry. Rationale: > > > > 1. There is no additional method that's being contemplated (whatever > ARC is, it's not a first class alternative to SPF or DKIM). > > > > 2. Currently, we have text in the specification to describe how to use > the output of SPF and DKIM for DMARC. I don't think there's much prospect > any new method wouldn't need something similar. > > > > I think a registry would only complicate things and wouldn't actually be > helpful. > > > > Scott K > > > > ___ > > 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 for auth policy tag in draft-ietf-dmarc-dmarcbis
Indeed. We can do what we've done in other cases: create a registry if/when we add something else later. Barry On Mon, Aug 7, 2023 at 4:11 PM Scott Kitterman wrote: > > > > On August 7, 2023 7:47:03 PM UTC, "Murray S. Kucherawy" > wrote: > >On Sat, Aug 5, 2023 at 1:09 PM Tim Wicinski wrote: > > > >> Based on the ABNF in -28, how about something like this: > >> > >> > >> dmarc-method = "dkim" / "spf" > >> > >> dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method) > >> > >> > >> I think this "should"(*) allow for all permutations but also simplifies > >> it, and I agree with Barry it should be simpler. > >> > > > >This looks good to me, except to be consistent with DKIM (from which this > >general syntax was borrowed) I'd suggest: > > > >* using colon as the separator rather than comma > >* WSP and CFWS should follow whatever we did for other tags > >* don't allow an empty list; I can't think of any DKIM or DMARC tag that > >accepts a list and also allows an empty value > > > >If we think we might add "arc" or something else in the future, do we need > >a registry of supported methods? If not, we'll have to rev DMARC every > >time a new one comes into favor. > > I think we don't need a registry. Rationale: > > 1. There is no additional method that's being contemplated (whatever ARC is, > it's not a first class alternative to SPF or DKIM). > > 2. Currently, we have text in the specification to describe how to use the > output of SPF and DKIM for DMARC. I don't think there's much prospect any > new method wouldn't need something similar. > > I think a registry would only complicate things and wouldn't actually be > helpful. > > Scott K > > ___ > 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 for auth policy tag in draft-ietf-dmarc-dmarcbis
On August 7, 2023 7:47:03 PM UTC, "Murray S. Kucherawy" wrote: >On Sat, Aug 5, 2023 at 1:09 PM Tim Wicinski wrote: > >> Based on the ABNF in -28, how about something like this: >> >> >> dmarc-method = "dkim" / "spf" >> >> dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method) >> >> >> I think this "should"(*) allow for all permutations but also simplifies >> it, and I agree with Barry it should be simpler. >> > >This looks good to me, except to be consistent with DKIM (from which this >general syntax was borrowed) I'd suggest: > >* using colon as the separator rather than comma >* WSP and CFWS should follow whatever we did for other tags >* don't allow an empty list; I can't think of any DKIM or DMARC tag that >accepts a list and also allows an empty value > >If we think we might add "arc" or something else in the future, do we need >a registry of supported methods? If not, we'll have to rev DMARC every >time a new one comes into favor. I think we don't need a registry. Rationale: 1. There is no additional method that's being contemplated (whatever ARC is, it's not a first class alternative to SPF or DKIM). 2. Currently, we have text in the specification to describe how to use the output of SPF and DKIM for DMARC. I don't think there's much prospect any new method wouldn't need something similar. I think a registry would only complicate things and wouldn't actually be helpful. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis
On Sat, Aug 5, 2023 at 1:09 PM Tim Wicinski wrote: > Based on the ABNF in -28, how about something like this: > > > dmarc-method = "dkim" / "spf" > > dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method) > > > I think this "should"(*) allow for all permutations but also simplifies > it, and I agree with Barry it should be simpler. > This looks good to me, except to be consistent with DKIM (from which this general syntax was borrowed) I'd suggest: * using colon as the separator rather than comma * WSP and CFWS should follow whatever we did for other tags * don't allow an empty list; I can't think of any DKIM or DMARC tag that accepts a list and also allows an empty value If we think we might add "arc" or something else in the future, do we need a registry of supported methods? If not, we'll have to rev DMARC every time a new one comes into favor. -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis
On Mon 07/Aug/2023 14:27:53 + Barry Leiba wrote: One last thing, how about directly assessing extensibility? dmarc-method = %s"dkim" / %s"spf" / dmarc-value First, why the "%s"? I see no reason to make the method name case sensitive. My bad. I seemed to recall that RFC 7489 specified a case sensitive grammar like DKIM. In fact only dmarc-version is case sensitive. Second, there's no need for "dmarc-value". With Tim's original proposal: dmarc-method = "dkim" / "spf" ...a spec that adds a new method called "newthing" can simply use this: dmarc-method =/ "newthing" The only reason is the wording that mentions unknown values. If I write auth=DkIm,newthing on a DMARC record, it can be accepted ignoring newthing (which Tim's wording seems to suggest) or the whole tag can be discarded (according to the grammar). I don't have a preference here, except for coherence suggesting to review that wording if we keep the grammar. For example: OLD and unknown methods are ignored. NEW and only known methods are allowed. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis
> One last thing, how about directly assessing extensibility? > > dmarc-method = %s"dkim" / %s"spf" / dmarc-value First, why the "%s"? I see no reason to make the method name case sensitive. Second, there's no need for "dmarc-value". With Tim's original proposal: > dmarc-method = "dkim" / "spf" ...a spec that adds a new method called "newthing" can simply use this: dmarc-method =/ "newthing" Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
