Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

[Wei Chuang]

I've also tried rolling up the comments in this thread as well.  Below is
the result:
-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 OPTIONAL auth tag.  The value is a colon ':' separated list
of supported authentication methods.  The order of the list is not
significant,  and unknown methods are ignored. An aligned passing result
for any listed method indicates a DMARC pass.  An empty list of methods is
a syntax error.  If auth is unspecified, the default is "spf:dkim" and both
DKIM and SPF authentication methods are supported.

5.3 General Record Format insert:

auth:  (colon-separated plain-text list of dmarc-methods; OPTIONAL; default
is "spf:dkim")
Indicates the supported authentication methods.  The order of the list
is not significant and
unknown methods are ignored.  Possible values are as follows:
dkim: Authenticate with DKIM
spf: Authenticate with SPF

An empty list of methods is a syntax error.

If any listed method passes and is aligned, then DMARC passes.


5.4. Formal Definition insert:

dmarc-method = "dkim" / "spf"

dmarc-auth = dmarc-method *(*WSP ":" *WSP dmarc-method)



Tag Name
Value Rule
auth.  dmarc-auth


On Mon, Aug 7, 2023 at 2:30 PM Murray S. Kucherawy 
wrote:

> 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
>
___
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

[Murray S. Kucherawy]

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

[Barry Leiba]

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

[Scott Kitterman]

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

[Murray S. Kucherawy]

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

[Alessandro Vesely]

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

[Barry Leiba]

> 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

Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

[Wei Chuang]

On Sun, Aug 6, 2023 at 8:50 AM Alessandro Vesely  wrote:

> On Sun 06/Aug/2023 11:38:18 + Tim Wicinski wrote:
>
> > On Sun, Aug 6, 2023 at 7:14 AM Alessandro Vesely  wrote:
> >> On Sat 05/Aug/2023 22:24:28 + Tim Wicinski wrote:
> >>>
> >>> [...]
> >>>
> >>> 5.3.  General Record Format
> >>>
> >>> auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> >> default is "spf,dkim")
> >>>
> >>>   Indicates the supported authentication methods.  The order of the
> >> list is not significant and
> >>>   unknown methods are ignored.  Possible values are as follows:
> >>>
> >>>   dkim: Authenticate with DKIM
> >>>   spf: Authenticate with SPF
> >>>
> >>>   An empty list indicates the tag is ignored.
> >>
> >> According to the grammar below, an empty list is a syntax error.  I'd
> keep
> >> the syntax as is and remove the line mentioning an empty list.
> >
> > Good catch - but why not say "an empty list is a syntax error".  That is
> > useful (to me, others may see it otherwise).
>
>
> Yes, noting that may better readability.  Since syntax errors MUST be
> ignored, it conveys the same meaning as before, but the reason is clearer.
>

Agreed that it's fine to treat it as syntax error, and it should be
ignored.  I put in the earlier language just to have that condition
specified.
-Wei


>
>
> One last thing, how about directly assessing extensibility?
>
> dmarc-method = %s"dkim" / %s"spf" / dmarc-value
>
> Ignoring unknown methods is already in the text, so it wouldn't hurt.  I
> have no useful extension in mind, but, for DMARC-fiction examples, one
> could think of "arc", "dnswl", "dkim-atps", ...
>
> BTW, all literals in Section 5.4 miss those %s'.
>
>
> Best
> Ale
> --
>
>
>
>
>
> ___
> 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

[Alessandro Vesely]

On Sun 06/Aug/2023 11:38:18 + Tim Wicinski wrote:


On Sun, Aug 6, 2023 at 7:14 AM Alessandro Vesely  wrote:

On Sat 05/Aug/2023 22:24:28 + Tim Wicinski wrote:


[...]

5.3.  General Record Format

auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;

default is "spf,dkim")


  Indicates the supported authentication methods.  The order of the

list is not significant and

  unknown methods are ignored.  Possible values are as follows:

  dkim: Authenticate with DKIM
  spf: Authenticate with SPF

  An empty list indicates the tag is ignored.


According to the grammar below, an empty list is a syntax error.  I'd keep
the syntax as is and remove the line mentioning an empty list.


Good catch - but why not say "an empty list is a syntax error".  That is
useful (to me, others may see it otherwise).



Yes, noting that may better readability.  Since syntax errors MUST be 
ignored, it conveys the same meaning as before, but the reason is clearer.



One last thing, how about directly assessing extensibility?

dmarc-method = %s"dkim" / %s"spf" / dmarc-value

Ignoring unknown methods is already in the text, so it wouldn't hurt.  I 
have no useful extension in mind, but, for DMARC-fiction examples, one 
could think of "arc", "dnswl", "dkim-atps", ...


BTW, all literals in Section 5.4 miss those %s'.


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

[Tim Wicinski]

On Sun, Aug 6, 2023 at 7:14 AM Alessandro Vesely  wrote:

> On Sat 05/Aug/2023 22:24:28 + Tim Wicinski wrote:
> >
> > [...]
> >
> > 5.3.  General Record Format
> >
> >
> > auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> default is "spf,dkim")
> >
> >  Indicates the supported authentication methods.  The order of the
> list is not significant and
> >  unknown methods are ignored.  Possible values are as follows:
> >
> >  dkim: Authenticate with DKIM
> >
> >  spf: Authenticate with SPF
> >
> >
> >  An empty list indicates the tag is ignored.
>
>
> According to the grammar below, an empty list is a syntax error.  I'd keep
> the syntax as is and remove the line mentioning an empty list.
>
>
Ale

Good catch - but why not say "an empty list is a syntax error".  That is
useful (to me, others may see it otherwise)

tim
___
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

[Alessandro Vesely]

On Sat 05/Aug/2023 22:24:28 + Tim Wicinski wrote:


[...]

5.3.  General Record Format


auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL; default is 
"spf,dkim")

 Indicates the supported authentication methods.  The order of the list is 
not significant and
 unknown methods are ignored.  Possible values are as follows:

 dkim: Authenticate with DKIM

 spf: Authenticate with SPF


 An empty list indicates the tag is ignored.



According to the grammar below, an empty list is a syntax error.  I'd keep 
the syntax as is and remove the line mentioning an empty list.




 If any listed method passes and is aligned, then DMARC passes.



5.4.  Formal Definition



 dmarc-method = "dkim" / "spf"


 dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method)





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

[Tim Wicinski]

That is more accurate Scott.

Also I removed an extra sentence on comma-separated.

Updated https://gist.github.com/moonshiner/70377e69d482e7bf3a927d5ac468babb


5.3.  General Record Format


auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL; default
is "spf,dkim")

Indicates the supported authentication methods.  The order of the list
is not significant and

unknown methods are ignored.  Possible values are as follows:

dkim: Authenticate with DKIM

spf: Authenticate with SPF


An empty list indicates the tag is ignored.


If any listed method passes and is aligned, then DMARC passes.



5.4.  Formal Definition



dmarc-method = "dkim" / "spf"


dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method)



I did not word smith Wei's 4.3 text.

On Sat, Aug 5, 2023 at 6:17 PM Scott Kitterman  wrote:

> On Saturday, August 5, 2023 6:11:03 PM EDT Tim Wicinski wrote:
> > On Sat, Aug 5, 2023 at 6:00 PM Scott Kitterman 
> wrote:
> > > On August 5, 2023 9:51:54 PM UTC, Tim Wicinski 
> wrote:
> > > >On Sat, Aug 5, 2023 at 5:35 PM John Levine  wrote:
> > > >> According to Tim Wicinski  :
> > > >> >-=-=-=-=-=-
> > > >> >
> > > >> >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)
> > > >
> > > >1) I realize we may need someway to update the dmarc-method if a new
> one
> > >
> > > is
> > >
> > > >added (okay okay)
> > > >
> > > >> That looks OK, with large clear text saying that if any of the
> listed
> > > >> methods pass, it's aligned.
> > > >
> > > >2) I missed Scott's comment the default should be "spf,dkim"
> > > >
> > > >I wordsmithed Wei's definition  above for Section 5.3
> > > >
> > > >  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> > > >
> > > >default is "spf,dkim")
> > > >
> > > >Indicates the supported authentication methods. If more than one
> > >
> > > method
> > >
> > > >is specified,
> > > >
> > > >they are comma ',' separated without whitespace.  The order of the
> > >
> > > list
> > >
> > > >is not significant and
> > > >
> > > >unknown methods are ignored.  Possible values are as follows:
> > > >dkim: Authenticate with DKIM
> > > >spf: Authenticate with SPF
> > > >
> > > >An empty list indicates no authentication method is specified and
> > >
> > > DMARC
> > >
> > > >is disabled.
> > > >
> > > >If any listed method passes, then DMARC is aligned.
> > > >
> > > >Should I do a pull request etc, etc?
> >
> > Scott
> >
> > I'd prefer an empty list means the tag is ignored.  I don't see a use
> case
> >
> > > for publishing a record that means DMARC is disabled.  Also, I think
> it's
> > > confusing.  I would find it more natural to mean no auth methods are
> used
> > > (i.e. everything fails), not DMARC is disabled.  The canonical method
> for
> > > disabiling DMARC is to not publish a record.  I don't think we need
> > > another
> > > way to express the same thing in a less clear way.
> >
> > Agreed.
> >
> >   auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> > default is "spf,dkim")
> > Indicates the supported authentication methods. If more than one
> method
> > is specified,
> > they are comma ',' separated without whitespace.  The order of the
> list
> > is not significant and
> > unknown methods are ignored.  Possible values are as follows:
> > dkim: Authenticate with DKIM
> > spf: Authenticate with SPF
> >
> > An empty list indicates the tag is ignored.
> >
> > If any listed method passes, then DMARC is aligned.
> >
> > https://gist.github.com/moonshiner/70377e69d482e7bf3a927d5ac468babb
> >
> >
> > also " I don't think we need another way to express the same thing in a
> > less clear way."
> >
> > +eleventy billion
>
> I missed this before ...
>
> Shouldn't "If any listed method passes, then DMARC is aligned." be "If any
> listed method passes and is aligned, then DMARC passes."?
>
> 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

[Scott Kitterman]

On Saturday, August 5, 2023 6:11:03 PM EDT Tim Wicinski wrote:
> On Sat, Aug 5, 2023 at 6:00 PM Scott Kitterman  wrote:
> > On August 5, 2023 9:51:54 PM UTC, Tim Wicinski  wrote:
> > >On Sat, Aug 5, 2023 at 5:35 PM John Levine  wrote:
> > >> According to Tim Wicinski  :
> > >> >-=-=-=-=-=-
> > >> >
> > >> >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)
> > >
> > >1) I realize we may need someway to update the dmarc-method if a new one
> > 
> > is
> > 
> > >added (okay okay)
> > >
> > >> That looks OK, with large clear text saying that if any of the listed
> > >> methods pass, it's aligned.
> > >
> > >2) I missed Scott's comment the default should be "spf,dkim"
> > >
> > >I wordsmithed Wei's definition  above for Section 5.3
> > >
> > >  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> > >
> > >default is "spf,dkim")
> > >
> > >Indicates the supported authentication methods. If more than one
> > 
> > method
> > 
> > >is specified,
> > >
> > >they are comma ',' separated without whitespace.  The order of the
> > 
> > list
> > 
> > >is not significant and
> > >
> > >unknown methods are ignored.  Possible values are as follows:
> > >dkim: Authenticate with DKIM
> > >spf: Authenticate with SPF
> > >
> > >An empty list indicates no authentication method is specified and
> > 
> > DMARC
> > 
> > >is disabled.
> > >
> > >If any listed method passes, then DMARC is aligned.
> > >
> > >Should I do a pull request etc, etc?
> 
> Scott
> 
> I'd prefer an empty list means the tag is ignored.  I don't see a use case
> 
> > for publishing a record that means DMARC is disabled.  Also, I think it's
> > confusing.  I would find it more natural to mean no auth methods are used
> > (i.e. everything fails), not DMARC is disabled.  The canonical method for
> > disabiling DMARC is to not publish a record.  I don't think we need
> > another
> > way to express the same thing in a less clear way.
> 
> Agreed.
> 
>   auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> default is "spf,dkim")
> Indicates the supported authentication methods. If more than one method
> is specified,
> they are comma ',' separated without whitespace.  The order of the list
> is not significant and
> unknown methods are ignored.  Possible values are as follows:
> dkim: Authenticate with DKIM
> spf: Authenticate with SPF
> 
> An empty list indicates the tag is ignored.
> 
> If any listed method passes, then DMARC is aligned.
> 
> https://gist.github.com/moonshiner/70377e69d482e7bf3a927d5ac468babb
> 
> 
> also " I don't think we need another way to express the same thing in a
> less clear way."
> 
> +eleventy billion

I missed this before ...

Shouldn't "If any listed method passes, then DMARC is aligned." be "If any 
listed method passes and is aligned, then DMARC passes."?

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

[Tim Wicinski]

On Sat, Aug 5, 2023 at 6:00 PM Scott Kitterman  wrote:

>
>
> On August 5, 2023 9:51:54 PM UTC, Tim Wicinski  wrote:
> >On Sat, Aug 5, 2023 at 5:35 PM John Levine  wrote:
> >
> >> According to Tim Wicinski  :
> >> >-=-=-=-=-=-
> >> >
> >> >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)
> >>
> >>
> >1) I realize we may need someway to update the dmarc-method if a new one
> is
> >added (okay okay)
> >
> >
> >
> >
> >> That looks OK, with large clear text saying that if any of the listed
> >> methods pass, it's aligned.
> >>
> >
> >2) I missed Scott's comment the default should be "spf,dkim"
> >
> >I wordsmithed Wei's definition  above for Section 5.3
> >
> >  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> >default is "spf,dkim")
> >Indicates the supported authentication methods. If more than one
> method
> >is specified,
> >they are comma ',' separated without whitespace.  The order of the
> list
> >is not significant and
> >unknown methods are ignored.  Possible values are as follows:
> >dkim: Authenticate with DKIM
> >spf: Authenticate with SPF
> >
> >An empty list indicates no authentication method is specified and
> DMARC
> >is disabled.
> >
> >If any listed method passes, then DMARC is aligned.
> >
> >Should I do a pull request etc, etc?
>
>
Scott

I'd prefer an empty list means the tag is ignored.  I don't see a use case
> for publishing a record that means DMARC is disabled.  Also, I think it's
> confusing.  I would find it more natural to mean no auth methods are used
> (i.e. everything fails), not DMARC is disabled.  The canonical method for
> disabiling DMARC is to not publish a record.  I don't think we need another
> way to express the same thing in a less clear way.
>
>
Agreed.

  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
default is "spf,dkim")
Indicates the supported authentication methods. If more than one method
is specified,
they are comma ',' separated without whitespace.  The order of the list
is not significant and
unknown methods are ignored.  Possible values are as follows:
dkim: Authenticate with DKIM
spf: Authenticate with SPF

An empty list indicates the tag is ignored.

If any listed method passes, then DMARC is aligned.

https://gist.github.com/moonshiner/70377e69d482e7bf3a927d5ac468babb


also " I don't think we need another way to express the same thing in a
less clear way."

+eleventy billion

tim



> 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

[Scott Kitterman]

On August 5, 2023 9:51:54 PM UTC, Tim Wicinski  wrote:
>On Sat, Aug 5, 2023 at 5:35 PM John Levine  wrote:
>
>> According to Tim Wicinski  :
>> >-=-=-=-=-=-
>> >
>> >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)
>>
>>
>1) I realize we may need someway to update the dmarc-method if a new one is
>added (okay okay)
>
>
>
>
>> That looks OK, with large clear text saying that if any of the listed
>> methods pass, it's aligned.
>>
>
>2) I missed Scott's comment the default should be "spf,dkim"
>
>I wordsmithed Wei's definition  above for Section 5.3
>
>  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
>default is "spf,dkim")
>Indicates the supported authentication methods. If more than one method
>is specified,
>they are comma ',' separated without whitespace.  The order of the list
>is not significant and
>unknown methods are ignored.  Possible values are as follows:
>dkim: Authenticate with DKIM
>spf: Authenticate with SPF
>
>An empty list indicates no authentication method is specified and DMARC
>is disabled.
>
>If any listed method passes, then DMARC is aligned.
>
>Should I do a pull request etc, etc?

I'd prefer an empty list means the tag is ignored.  I don't see a use case for 
publishing a record that means DMARC is disabled.  Also, I think it's 
confusing.  I would find it more natural to mean no auth methods are used (i.e. 
everything fails), not DMARC is disabled.  The canonical method for disabiling 
DMARC is to not publish a record.  I don't think we need another way to express 
the same thing in a less clear way.

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

[Tim Wicinski]

On Sat, Aug 5, 2023 at 5:35 PM John Levine  wrote:

> According to Tim Wicinski  :
> >-=-=-=-=-=-
> >
> >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)
>
>
1) I realize we may need someway to update the dmarc-method if a new one is
added (okay okay)




> That looks OK, with large clear text saying that if any of the listed
> methods pass, it's aligned.
>

2) I missed Scott's comment the default should be "spf,dkim"

I wordsmithed Wei's definition  above for Section 5.3

  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
default is "spf,dkim")
Indicates the supported authentication methods. If more than one method
is specified,
they are comma ',' separated without whitespace.  The order of the list
is not significant and
unknown methods are ignored.  Possible values are as follows:
dkim: Authenticate with DKIM
spf: Authenticate with SPF

An empty list indicates no authentication method is specified and DMARC
is disabled.

If any listed method passes, then DMARC is aligned.

Should I do a pull request etc, etc?

tim



> R's,
> John
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
>
> ___
> 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

[John Levine]

According to Tim Wicinski  :
>-=-=-=-=-=-
>
>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)

That looks OK, with large clear text saying that if any of the listed
methods pass, it's aligned.

R's,
John
-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
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

[Tim Wicinski]

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  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  40google@dmarc.ietf.org> wrote:
>
>> At IETF-117, I restarted the proposal for a policy "auth=" tag based on
>> the proposal here
>> .
>> 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 =  / "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

Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

[Barry Leiba]

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  wrote:

> At IETF-117, I restarted the proposal for a policy "auth=" tag based on
> the proposal here
> .
> 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 =  / "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

Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

[Alessandro Vesely]

On Fri 04/Aug/2023 21:14:18 + Scott Kitterman wrote:

On August 4, 2023 4:16:39 PM UTC, Wei Chuang 
 wrote:

At IETF-117, I restarted the proposal for a policy "auth=" tag based on the
proposal here
.
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 =  / "dkim" / "spf" / "dkim:spf" / "spf:dkim"



I'd drop the requirements of not having whitespace.  If we opt for a 
colon-separated list, why not stick with DKIM's sig-h-tag syntax?  That is:


dmarc-auth = %s"auth" equals *WSP [dmarc-method]
  *( *WSP ":" *WSP dmarc-method )

dmarc-method = %s"dkim" / %s"spf"



Table:
Tag Name   Value Rule
auth dmarc-auth


I'm still not convinced we need this, but I can live with it.



We need it after the often-cited paper showing how to reliably obtain 
spf=pass using current free-mailbox providers.  With the current spec, that 
sloppy SPF settings translates to dmarc=pass, with no possibility to amend it.




In 5.3 you need to specify the tag is optional and that the default (to be used 
in the absence of the tag) is spf:dkim.  That is necessary to preserve backward 
compatibility with existing records (which I think is essential for DMARCbis).



BTW, Section 5.4 seems to be missing a number of %s'.


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

[Scott Kitterman]

On August 4, 2023 4:16:39 PM UTC, Wei Chuang 
 wrote:
>At IETF-117, I restarted the proposal for a policy "auth=" tag based on the
>proposal here
>.
>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 =  / "dkim" / "spf" / "dkim:spf" / "spf:dkim"
>
>Table:
>Tag Name   Value Rule
>auth dmarc-auth

I'm still not convinced we need this, but I can live with it.

In 5.3 you need to specify the tag is optional and that the default (to be used 
in the absence of the tag) is spf:dkim.  That is necessary to preserve backward 
compatibility with existing records (which I think is essential for DMARCbis).

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

[Wei Chuang]

At IETF-117, I restarted the proposal for a policy "auth=" tag based on the
proposal here
.
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 =  / "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