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. tim * no doubt I missed something and looked to be schooled On Sat, Aug 5, 2023 at 12:06 PM Barry Leiba <barryle...@computer.org> wrote: > Two things: > > > If unspecified with a policy tag "auth=", this indicates that both DKIM > and SPF are supported. > > I don’t like this approach. I think that the absence of auth= means what > it has always meant: the sending domain is not specifying what > authentication methods it is using and the receiving domain should check > both SPF and DKIM. > > This is significantly different to the sending domain explicitly > specifying that it uses DKIM in that in the latter case the receiving > domain can treat the absence of a DKIM signature with suspicion. > > And the ABNF is needlessly complex and does not allow for extension. It’s > easy to rework it in the manner of many other specifications that do > similar things. > > Barry > > > On Fri, Aug 4, 2023 at 12:17 PM Wei Chuang <weihaw= > 40google....@dmarc.ietf.org> wrote: > >> At IETF-117, I restarted the proposal for a policy "auth=" tag based on >> the proposal here >> <https://mailarchive.ietf.org/arch/msg/dmarc/KeGbMfX91WJk_aziKsrRfI6AYkI/>. >> The "auth=" policy allows for restriction of SPF in scenarios where it >> might be problematic but still retains its availability in DMARC by >> default. I didn't hear objections at 117, so below is some proposed >> language for "auth=" for dmarc-ietf-dmarc-dmarcbis. >> >> -Wei >> >> ===== >> >> 1. Introduction, 3rd paragraph insert after first sentence: >> >> In addition, the choice of permitted authentication methods, SPF or DKIM, >> method MAY be explicitly specified, potentially to restrict the supported >> authentication methods. >> >> 4.3 Authentication Mechanisms append: >> >> Domain Owners and PSOs MAY explicitly specify the supported >> authentication methods via the "auth=" tag. The value is a colon ':' >> separated list of supported authentication methods without whitespace. The >> order of the list isn't any significant, and unknown methods are ignored. >> An aligned passing result for any listed method indicates a DMARC pass. An >> empty list indicates no authentication method is specified and DMARC is >> disabled. If unspecified with a policy tag "auth=", this indicates that >> both DKIM and SPF are supported. >> >> 5.3 General Record Format insert: >> >> auth: Indicates the supported authentication methods. If more than one >> method is specified, they are colon ':' separated without whitespace. The >> order of the list is not significant and unknown methods are ignored. An >> empty list indicates no authentication method is specified and DMARC is >> disabled. >> dkim: Authenticate with DKIM >> spf: Authenticate with SPF >> >> 5.4. Formal Definition insert: >> >> dmarc-auth = <empty> / "dkim" / "spf" / "dkim:spf" / "spf:dkim" >> >> Table: >> Tag Name Value Rule >> auth dmarc-auth >> >> >> _______________________________________________ >> 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
