Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Neil Anuskiewicz]

> On Feb 29, 2024, at 10:55 AM, Todd Herr 
>  wrote:
> 
> 
> Colleagues,
> 
> I've been reading DMARCbic rev -30 today with a plan to collect the first set 
> of minor edits and I came across a sentence that I believe goes beyond minor, 
> so wanted to get a sanity check.
> 
> Section 7.6, Domain Owner Actions, ends with the following sentence:
> 
> In particular, this document makes explicit that domains for general-purpose 
> email MUST NOT deploy a DMARC policy of p=reject.
> 
> I don't believe this to be true, however. Rather, Section 8.6, 
> Interoperability Considerations, says SHOULD NOT on the topic (e.g., "It is 
> therefore critical that domains that host users who might post messages to 
> mailing lists SHOULD NOT publish p=reject")
> 
> Section 7.6 therefore should be updated to read "domains for general-purpose 
> email SHOULD NOT deploy a DMARC policy of p=reject", yes?
> 
Yes! Assuming general purpose is precisely, clearly defined we have a winner.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Todd Herr]

On Fri, Mar 8, 2024 at 4:52 AM Alessandro Vesely  wrote:

> On 06/03/2024 15:42, Todd Herr wrote:
> > On Tue, Mar 5, 2024 at 10:45 PM Barry Leiba 
> wrote:
> >
> >> SHOULD NOT was the consensus call, and the correction Todd
> >> proposes is just making that sentence consistent with that.
>
>
> Yet, Section 7.6 still has:
>
> In particular, this document makes explicit that domains for general-
> purpose email MUST NOT deploy a DMARC policy of p=reject.
>
>
>
Yes, due to an oversight on my part, one that I identified during my Last
Call read of DMARCbis, and subsequently opened this thread to transparently
confirm that I had indeed overlooked that phrase in 7.6 during previous
releases and that I believed that it was an oversight and should be
corrected.

The chairs have confirmed that it was an oversight on my part, and the
language will be changed to SHOULD NOT in rev -31, as per the discussion in
this thread and the previous consensus.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Alessandro Vesely]

On 06/03/2024 15:42, Todd Herr wrote:

On Tue, Mar 5, 2024 at 10:45 PM Barry Leiba  wrote:

SHOULD NOT was the consensus call, and the correction Todd 
proposes is just making that sentence consistent with that.



Yet, Section 7.6 still has:

   In particular, this document makes explicit that domains for general-
   purpose email MUST NOT deploy a DMARC policy of p=reject.


Best
Ale
--




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

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Todd Herr]

On Tue, Mar 5, 2024 at 10:45 PM Barry Leiba  wrote:

> I agree.  This is not a substantive issue, but is simply correcting an
> oversight.  SHOULD NOT was the consensus call, and the correction Todd
> proposes is just making that sentence consistent with that.
>
> Enough said on this; Todd, please just add this change to your other
> editorial changes.
>
>
Done and recorded in closed issue #122.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Barry Leiba]

I agree.  This is not a substantive issue, but is simply correcting an
oversight.  SHOULD NOT was the consensus call, and the correction Todd
proposes is just making that sentence consistent with that.

Enough said on this; Todd, please just add this change to your other
editorial changes.

Barry, as chair

On Thu, Feb 29, 2024 at 7:13 PM Murray S. Kucherawy  wrote:
>
> On Thu, Feb 29, 2024 at 2:14 PM Seth Blank 
>  wrote:
>>
>> As Chair: Consensus was already called. Todd just wants the wording 
>> consistent in the document. There's no need for another decision here.
>
>
> This is my understanding as well.  Mike Hammer summarized it neatly.
>
> -MSK
>
> ___
> 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] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Hector Santos]

No rehashing, my technical opinion, clearly the semantics but both lead to:

“You SHOULD|MUST consider the documented conflicts before using the restricted 
policy p=reject”

Question. Is p=quarantine ok to use?  Or do we presume p=reject implies 
p=quarantine?’'



All the best,
Hector Santos



> On Feb 29, 2024, at 2:53 PM, Seth Blank  
> wrote:
> 
> I thought we landed on SHOULD NOT, there was strong resistance to MUST NOT
> 
> On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman  > wrote:
>> Okay.  I think 8.6 is the one in error.  You see how this is going to go, 
>> right?
>> 
>> Scott K
>> 
>> On February 29, 2024 7:45:15 PM UTC, Todd Herr 
>> > > wrote:
>> >It is not my intent here to relitigate any issues.
>> >
>> >Rather, I believe that the text in 7.6 is wrong, likely due to an oversight
>> >on my part when the new text in 8.6 was published, and I just want to
>> >confirm that 7.6 is indeed wrong.
>> >
>> >On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman > >>
>> >wrote:
>> >
>> >> In what way is this a new issue that has not already been argued to death
>> >> in the WG?  I think for WGLC, we've already done this. We will, no doubt
>> >> get to have this conversation during the IETF last call, but for the
>> >> working group, this strikes me as exactly the type of relitigation of
>> >> issues we've been counseled to avoid.
>> >>
>> >> Scott K
>> >>
>> >> On February 29, 2024 6:54:57 PM UTC, Todd Herr > >> 40valimail@dmarc.ietf.org > 
>> >> wrote:
>> >> >Colleagues,
>> >> >
>> >> >I've been reading DMARCbic rev -30 today with a plan to collect the first
>> >> >set of minor edits and I came across a sentence that I believe goes 
>> >> >beyond
>> >> >minor, so wanted to get a sanity check.
>> >> >
>> >> >Section 7.6, Domain Owner Actions, ends with the following sentence:
>> >> >
>> >> >In particular, this document makes explicit that domains for
>> >> >general-purpose email MUST NOT deploy a DMARC policy of p=reject.
>> >> >
>> >> >
>> >> >I don't believe this to be true, however. Rather, Section 8.6,
>> >> >Interoperability Considerations, says SHOULD NOT on the topic (e.g., "It
>> >> is
>> >> >therefore critical that domains that host users who might post messages 
>> >> >to
>> >> >mailing lists SHOULD NOT publish p=reject")
>> >> >
>> >> >Section 7.6 therefore should be updated to read "domains for
>> >> >general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", yes?
>> >> >
>> >>
>> >> ___
>> >> 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
> 
> 
> --
> Seth Blank  | Chief Technology Officer
> e: s...@valimail.com 
> p:
> 
> This email and all data transmitted with it contains confidential and/or 
> proprietary information intended solely for the use of individual(s) 
> authorized to receive it. If you are not an intended and authorized recipient 
> you are hereby notified of any use, disclosure, copying or distribution of 
> the information included in this transmission is prohibited and may be 
> unlawful. Please immediately notify the sender by replying to this email and 
> then delete it from your system.
> ___
> 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] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Murray S. Kucherawy]

On Thu, Feb 29, 2024 at 2:14 PM Seth Blank  wrote:

> As Chair: Consensus was already called. Todd just wants the wording
> consistent in the document. There's no need for another decision here.
>

This is my understanding as well.  Mike Hammer summarized it neatly.

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

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Seth Blank]

As Chair: Consensus was already called. Todd just wants the wording
consistent in the document. There's no need for another decision here.

On Thu, Feb 29, 2024 at 4:36 PM Scott Kitterman 
wrote:

> Right, I understand that view, but since the chairs have already stepped
> back on this issue, who should make that call?
>
> Scott K
>
> On February 29, 2024 9:26:42 PM UTC, Seth Blank  40valimail@dmarc.ietf.org> wrote:
> >It was already resolved, Todd's point is that the text in 7.6 was never
> >updated to match, which was a mistake he wants to fix transparently.
> >
> >On Thu, Feb 29, 2024 at 4:04 PM Scott Kitterman 
> >wrote:
> >
> >> I think it ought to be resolved by the same AD that made the consensus
> >> call.
> >>
> >> Scott K
> >>
> >> On February 29, 2024 8:58:21 PM UTC, Dotzero  wrote:
> >> >I agree that the rough consensus landed on "SHOULD NOT" even though
> there
> >> >were some who felt "MUST NOT" was "purer". I was one of those who
> >> >(reluctantly) supported "SHOULD NOT". Todd is simply trying to get
> >> >consistency within the document to match the outcome that there was
> rough
> >> >agreement on. That is the new issue he is opening and not rehashing the
> >> >previously closed issue.
> >> >
> >> >Hopefully the chairs will rule on this so we don't have a previous
> issue
> >> >reopened during last call.
> >> >
> >> >Michael Hammer
> >> >
> >> >On Thu, Feb 29, 2024 at 2:53 PM Seth Blank  >> >40valimail@dmarc.ietf.org> wrote:
> >> >
> >> >> I thought we landed on SHOULD NOT, there was strong resistance to
> MUST
> >> NOT
> >> >>
> >> >> On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman <
> skl...@kitterman.com>
> >> >> wrote:
> >> >>
> >> >>> Okay.  I think 8.6 is the one in error.  You see how this is going
> to
> >> go,
> >> >>> right?
> >> >>>
> >> >>> Scott K
> >> >>>
> >> >>> On February 29, 2024 7:45:15 PM UTC, Todd Herr  >> >>> 40valimail@dmarc.ietf.org> wrote:
> >> >>> >It is not my intent here to relitigate any issues.
> >> >>> >
> >> >>> >Rather, I believe that the text in 7.6 is wrong, likely due to an
> >> >>> oversight
> >> >>> >on my part when the new text in 8.6 was published, and I just want
> to
> >> >>> >confirm that 7.6 is indeed wrong.
> >> >>> >
> >> >>> >On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman <
> skl...@kitterman.com
> >> >
> >> >>> >wrote:
> >> >>> >
> >> >>> >> In what way is this a new issue that has not already been argued
> to
> >> >>> death
> >> >>> >> in the WG?  I think for WGLC, we've already done this. We will,
> no
> >> >>> doubt
> >> >>> >> get to have this conversation during the IETF last call, but for
> the
> >> >>> >> working group, this strikes me as exactly the type of
> relitigation
> >> of
> >> >>> >> issues we've been counseled to avoid.
> >> >>> >>
> >> >>> >> Scott K
> >> >>> >>
> >> >>> >> On February 29, 2024 6:54:57 PM UTC, Todd Herr  >> >>> >> 40valimail@dmarc.ietf.org> wrote:
> >> >>> >> >Colleagues,
> >> >>> >> >
> >> >>> >> >I've been reading DMARCbic rev -30 today with a plan to collect
> the
> >> >>> first
> >> >>> >> >set of minor edits and I came across a sentence that I believe
> goes
> >> >>> beyond
> >> >>> >> >minor, so wanted to get a sanity check.
> >> >>> >> >
> >> >>> >> >Section 7.6, Domain Owner Actions, ends with the following
> >> sentence:
> >> >>> >> >
> >> >>> >> >In particular, this document makes explicit that domains for
> >> >>> >> >general-purpose email MUST NOT deploy a DMARC policy of
> p=reject.
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >I don't believe this to be true, however. Rather, Section 8.6,
> >> >>> >> >Interoperability Considerations, says SHOULD NOT on the topic
> >> (e.g.,
> >> >>> "It
> >> >>> >> is
> >> >>> >> >therefore critical that domains that host users who might post
> >> >>> messages to
> >> >>> >> >mailing lists SHOULD NOT publish p=reject")
> >> >>> >> >
> >> >>> >> >Section 7.6 therefore should be updated to read "domains for
> >> >>> >> >general-purpose email SHOULD NOT deploy a DMARC policy of
> >> p=reject",
> >> >>> yes?
> >> >>> >> >
> >> >>> >>
> >> >>> >> ___
> >> >>> >> 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
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> *Seth Blank * | Chief Technology Officer
> >> >> *e:* s...@valimail.com
> >> >> *p:*
> >> >>
> >> >> This email and all data transmitted with it contains confidential
> and/or
> >> >> proprietary information intended solely for the use of individual(s)
> >> >> authorized to receive it. If you are not an intended and authorized
> >> >> recipient you are hereby notified of any use, disclosure, copying or
> >> >> distribution of the information included in this transmission is
> >> prohibited
> >> >> 

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Scott Kitterman]

Right, I understand that view, but since the chairs have already stepped back 
on this issue, who should make that call?

Scott K

On February 29, 2024 9:26:42 PM UTC, Seth Blank 
 wrote:
>It was already resolved, Todd's point is that the text in 7.6 was never
>updated to match, which was a mistake he wants to fix transparently.
>
>On Thu, Feb 29, 2024 at 4:04 PM Scott Kitterman 
>wrote:
>
>> I think it ought to be resolved by the same AD that made the consensus
>> call.
>>
>> Scott K
>>
>> On February 29, 2024 8:58:21 PM UTC, Dotzero  wrote:
>> >I agree that the rough consensus landed on "SHOULD NOT" even though there
>> >were some who felt "MUST NOT" was "purer". I was one of those who
>> >(reluctantly) supported "SHOULD NOT". Todd is simply trying to get
>> >consistency within the document to match the outcome that there was rough
>> >agreement on. That is the new issue he is opening and not rehashing the
>> >previously closed issue.
>> >
>> >Hopefully the chairs will rule on this so we don't have a previous issue
>> >reopened during last call.
>> >
>> >Michael Hammer
>> >
>> >On Thu, Feb 29, 2024 at 2:53 PM Seth Blank > >40valimail@dmarc.ietf.org> wrote:
>> >
>> >> I thought we landed on SHOULD NOT, there was strong resistance to MUST
>> NOT
>> >>
>> >> On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman 
>> >> wrote:
>> >>
>> >>> Okay.  I think 8.6 is the one in error.  You see how this is going to
>> go,
>> >>> right?
>> >>>
>> >>> Scott K
>> >>>
>> >>> On February 29, 2024 7:45:15 PM UTC, Todd Herr > >>> 40valimail@dmarc.ietf.org> wrote:
>> >>> >It is not my intent here to relitigate any issues.
>> >>> >
>> >>> >Rather, I believe that the text in 7.6 is wrong, likely due to an
>> >>> oversight
>> >>> >on my part when the new text in 8.6 was published, and I just want to
>> >>> >confirm that 7.6 is indeed wrong.
>> >>> >
>> >>> >On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman > >
>> >>> >wrote:
>> >>> >
>> >>> >> In what way is this a new issue that has not already been argued to
>> >>> death
>> >>> >> in the WG?  I think for WGLC, we've already done this. We will, no
>> >>> doubt
>> >>> >> get to have this conversation during the IETF last call, but for the
>> >>> >> working group, this strikes me as exactly the type of relitigation
>> of
>> >>> >> issues we've been counseled to avoid.
>> >>> >>
>> >>> >> Scott K
>> >>> >>
>> >>> >> On February 29, 2024 6:54:57 PM UTC, Todd Herr > >>> >> 40valimail@dmarc.ietf.org> wrote:
>> >>> >> >Colleagues,
>> >>> >> >
>> >>> >> >I've been reading DMARCbic rev -30 today with a plan to collect the
>> >>> first
>> >>> >> >set of minor edits and I came across a sentence that I believe goes
>> >>> beyond
>> >>> >> >minor, so wanted to get a sanity check.
>> >>> >> >
>> >>> >> >Section 7.6, Domain Owner Actions, ends with the following
>> sentence:
>> >>> >> >
>> >>> >> >In particular, this document makes explicit that domains for
>> >>> >> >general-purpose email MUST NOT deploy a DMARC policy of p=reject.
>> >>> >> >
>> >>> >> >
>> >>> >> >I don't believe this to be true, however. Rather, Section 8.6,
>> >>> >> >Interoperability Considerations, says SHOULD NOT on the topic
>> (e.g.,
>> >>> "It
>> >>> >> is
>> >>> >> >therefore critical that domains that host users who might post
>> >>> messages to
>> >>> >> >mailing lists SHOULD NOT publish p=reject")
>> >>> >> >
>> >>> >> >Section 7.6 therefore should be updated to read "domains for
>> >>> >> >general-purpose email SHOULD NOT deploy a DMARC policy of
>> p=reject",
>> >>> yes?
>> >>> >> >
>> >>> >>
>> >>> >> ___
>> >>> >> 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
>> >>>
>> >>
>> >>
>> >> --
>> >>
>> >> *Seth Blank * | Chief Technology Officer
>> >> *e:* s...@valimail.com
>> >> *p:*
>> >>
>> >> This email and all data transmitted with it contains confidential and/or
>> >> proprietary information intended solely for the use of individual(s)
>> >> authorized to receive it. If you are not an intended and authorized
>> >> recipient you are hereby notified of any use, disclosure, copying or
>> >> distribution of the information included in this transmission is
>> prohibited
>> >> and may be unlawful. Please immediately notify the sender by replying to
>> >> this email and then delete it from your system.
>> >> ___
>> >> 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] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Seth Blank]

It was already resolved, Todd's point is that the text in 7.6 was never
updated to match, which was a mistake he wants to fix transparently.

On Thu, Feb 29, 2024 at 4:04 PM Scott Kitterman 
wrote:

> I think it ought to be resolved by the same AD that made the consensus
> call.
>
> Scott K
>
> On February 29, 2024 8:58:21 PM UTC, Dotzero  wrote:
> >I agree that the rough consensus landed on "SHOULD NOT" even though there
> >were some who felt "MUST NOT" was "purer". I was one of those who
> >(reluctantly) supported "SHOULD NOT". Todd is simply trying to get
> >consistency within the document to match the outcome that there was rough
> >agreement on. That is the new issue he is opening and not rehashing the
> >previously closed issue.
> >
> >Hopefully the chairs will rule on this so we don't have a previous issue
> >reopened during last call.
> >
> >Michael Hammer
> >
> >On Thu, Feb 29, 2024 at 2:53 PM Seth Blank  >40valimail@dmarc.ietf.org> wrote:
> >
> >> I thought we landed on SHOULD NOT, there was strong resistance to MUST
> NOT
> >>
> >> On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman 
> >> wrote:
> >>
> >>> Okay.  I think 8.6 is the one in error.  You see how this is going to
> go,
> >>> right?
> >>>
> >>> Scott K
> >>>
> >>> On February 29, 2024 7:45:15 PM UTC, Todd Herr  >>> 40valimail@dmarc.ietf.org> wrote:
> >>> >It is not my intent here to relitigate any issues.
> >>> >
> >>> >Rather, I believe that the text in 7.6 is wrong, likely due to an
> >>> oversight
> >>> >on my part when the new text in 8.6 was published, and I just want to
> >>> >confirm that 7.6 is indeed wrong.
> >>> >
> >>> >On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman  >
> >>> >wrote:
> >>> >
> >>> >> In what way is this a new issue that has not already been argued to
> >>> death
> >>> >> in the WG?  I think for WGLC, we've already done this. We will, no
> >>> doubt
> >>> >> get to have this conversation during the IETF last call, but for the
> >>> >> working group, this strikes me as exactly the type of relitigation
> of
> >>> >> issues we've been counseled to avoid.
> >>> >>
> >>> >> Scott K
> >>> >>
> >>> >> On February 29, 2024 6:54:57 PM UTC, Todd Herr  >>> >> 40valimail@dmarc.ietf.org> wrote:
> >>> >> >Colleagues,
> >>> >> >
> >>> >> >I've been reading DMARCbic rev -30 today with a plan to collect the
> >>> first
> >>> >> >set of minor edits and I came across a sentence that I believe goes
> >>> beyond
> >>> >> >minor, so wanted to get a sanity check.
> >>> >> >
> >>> >> >Section 7.6, Domain Owner Actions, ends with the following
> sentence:
> >>> >> >
> >>> >> >In particular, this document makes explicit that domains for
> >>> >> >general-purpose email MUST NOT deploy a DMARC policy of p=reject.
> >>> >> >
> >>> >> >
> >>> >> >I don't believe this to be true, however. Rather, Section 8.6,
> >>> >> >Interoperability Considerations, says SHOULD NOT on the topic
> (e.g.,
> >>> "It
> >>> >> is
> >>> >> >therefore critical that domains that host users who might post
> >>> messages to
> >>> >> >mailing lists SHOULD NOT publish p=reject")
> >>> >> >
> >>> >> >Section 7.6 therefore should be updated to read "domains for
> >>> >> >general-purpose email SHOULD NOT deploy a DMARC policy of
> p=reject",
> >>> yes?
> >>> >> >
> >>> >>
> >>> >> ___
> >>> >> 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
> >>>
> >>
> >>
> >> --
> >>
> >> *Seth Blank * | Chief Technology Officer
> >> *e:* s...@valimail.com
> >> *p:*
> >>
> >> This email and all data transmitted with it contains confidential and/or
> >> proprietary information intended solely for the use of individual(s)
> >> authorized to receive it. If you are not an intended and authorized
> >> recipient you are hereby notified of any use, disclosure, copying or
> >> distribution of the information included in this transmission is
> prohibited
> >> and may be unlawful. Please immediately notify the sender by replying to
> >> this email and then delete it from your system.
> >> ___
> >> 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
>


-- 

*Seth Blank * | Chief Technology Officer
*e:* s...@valimail.com
*p:*

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. 

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Scott Kitterman]

I think it ought to be resolved by the same AD that made the consensus call.

Scott K

On February 29, 2024 8:58:21 PM UTC, Dotzero  wrote:
>I agree that the rough consensus landed on "SHOULD NOT" even though there
>were some who felt "MUST NOT" was "purer". I was one of those who
>(reluctantly) supported "SHOULD NOT". Todd is simply trying to get
>consistency within the document to match the outcome that there was rough
>agreement on. That is the new issue he is opening and not rehashing the
>previously closed issue.
>
>Hopefully the chairs will rule on this so we don't have a previous issue
>reopened during last call.
>
>Michael Hammer
>
>On Thu, Feb 29, 2024 at 2:53 PM Seth Blank 40valimail@dmarc.ietf.org> wrote:
>
>> I thought we landed on SHOULD NOT, there was strong resistance to MUST NOT
>>
>> On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman 
>> wrote:
>>
>>> Okay.  I think 8.6 is the one in error.  You see how this is going to go,
>>> right?
>>>
>>> Scott K
>>>
>>> On February 29, 2024 7:45:15 PM UTC, Todd Herr >> 40valimail@dmarc.ietf.org> wrote:
>>> >It is not my intent here to relitigate any issues.
>>> >
>>> >Rather, I believe that the text in 7.6 is wrong, likely due to an
>>> oversight
>>> >on my part when the new text in 8.6 was published, and I just want to
>>> >confirm that 7.6 is indeed wrong.
>>> >
>>> >On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman 
>>> >wrote:
>>> >
>>> >> In what way is this a new issue that has not already been argued to
>>> death
>>> >> in the WG?  I think for WGLC, we've already done this. We will, no
>>> doubt
>>> >> get to have this conversation during the IETF last call, but for the
>>> >> working group, this strikes me as exactly the type of relitigation of
>>> >> issues we've been counseled to avoid.
>>> >>
>>> >> Scott K
>>> >>
>>> >> On February 29, 2024 6:54:57 PM UTC, Todd Herr >> >> 40valimail@dmarc.ietf.org> wrote:
>>> >> >Colleagues,
>>> >> >
>>> >> >I've been reading DMARCbic rev -30 today with a plan to collect the
>>> first
>>> >> >set of minor edits and I came across a sentence that I believe goes
>>> beyond
>>> >> >minor, so wanted to get a sanity check.
>>> >> >
>>> >> >Section 7.6, Domain Owner Actions, ends with the following sentence:
>>> >> >
>>> >> >In particular, this document makes explicit that domains for
>>> >> >general-purpose email MUST NOT deploy a DMARC policy of p=reject.
>>> >> >
>>> >> >
>>> >> >I don't believe this to be true, however. Rather, Section 8.6,
>>> >> >Interoperability Considerations, says SHOULD NOT on the topic (e.g.,
>>> "It
>>> >> is
>>> >> >therefore critical that domains that host users who might post
>>> messages to
>>> >> >mailing lists SHOULD NOT publish p=reject")
>>> >> >
>>> >> >Section 7.6 therefore should be updated to read "domains for
>>> >> >general-purpose email SHOULD NOT deploy a DMARC policy of p=reject",
>>> yes?
>>> >> >
>>> >>
>>> >> ___
>>> >> 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
>>>
>>
>>
>> --
>>
>> *Seth Blank * | Chief Technology Officer
>> *e:* s...@valimail.com
>> *p:*
>>
>> This email and all data transmitted with it contains confidential and/or
>> proprietary information intended solely for the use of individual(s)
>> authorized to receive it. If you are not an intended and authorized
>> recipient you are hereby notified of any use, disclosure, copying or
>> distribution of the information included in this transmission is prohibited
>> and may be unlawful. Please immediately notify the sender by replying to
>> this email and then delete it from your system.
>> ___
>> 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] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Dotzero]

I agree that the rough consensus landed on "SHOULD NOT" even though there
were some who felt "MUST NOT" was "purer". I was one of those who
(reluctantly) supported "SHOULD NOT". Todd is simply trying to get
consistency within the document to match the outcome that there was rough
agreement on. That is the new issue he is opening and not rehashing the
previously closed issue.

Hopefully the chairs will rule on this so we don't have a previous issue
reopened during last call.

Michael Hammer

On Thu, Feb 29, 2024 at 2:53 PM Seth Blank  wrote:

> I thought we landed on SHOULD NOT, there was strong resistance to MUST NOT
>
> On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman 
> wrote:
>
>> Okay.  I think 8.6 is the one in error.  You see how this is going to go,
>> right?
>>
>> Scott K
>>
>> On February 29, 2024 7:45:15 PM UTC, Todd Herr > 40valimail@dmarc.ietf.org> wrote:
>> >It is not my intent here to relitigate any issues.
>> >
>> >Rather, I believe that the text in 7.6 is wrong, likely due to an
>> oversight
>> >on my part when the new text in 8.6 was published, and I just want to
>> >confirm that 7.6 is indeed wrong.
>> >
>> >On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman 
>> >wrote:
>> >
>> >> In what way is this a new issue that has not already been argued to
>> death
>> >> in the WG?  I think for WGLC, we've already done this. We will, no
>> doubt
>> >> get to have this conversation during the IETF last call, but for the
>> >> working group, this strikes me as exactly the type of relitigation of
>> >> issues we've been counseled to avoid.
>> >>
>> >> Scott K
>> >>
>> >> On February 29, 2024 6:54:57 PM UTC, Todd Herr > >> 40valimail@dmarc.ietf.org> wrote:
>> >> >Colleagues,
>> >> >
>> >> >I've been reading DMARCbic rev -30 today with a plan to collect the
>> first
>> >> >set of minor edits and I came across a sentence that I believe goes
>> beyond
>> >> >minor, so wanted to get a sanity check.
>> >> >
>> >> >Section 7.6, Domain Owner Actions, ends with the following sentence:
>> >> >
>> >> >In particular, this document makes explicit that domains for
>> >> >general-purpose email MUST NOT deploy a DMARC policy of p=reject.
>> >> >
>> >> >
>> >> >I don't believe this to be true, however. Rather, Section 8.6,
>> >> >Interoperability Considerations, says SHOULD NOT on the topic (e.g.,
>> "It
>> >> is
>> >> >therefore critical that domains that host users who might post
>> messages to
>> >> >mailing lists SHOULD NOT publish p=reject")
>> >> >
>> >> >Section 7.6 therefore should be updated to read "domains for
>> >> >general-purpose email SHOULD NOT deploy a DMARC policy of p=reject",
>> yes?
>> >> >
>> >>
>> >> ___
>> >> 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
>>
>
>
> --
>
> *Seth Blank * | Chief Technology Officer
> *e:* s...@valimail.com
> *p:*
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
> ___
> 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] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Mark Alley]

Either way, I think Todd raises a valid point. Given the near identical 
context of the language, the asserted intent should be consistent for 
both, dependent on MUST NOT or SHOULD NOT consensus.


In my eyes as a consumer of the document output, I would probably be 
asking the same clarifying questions of the WG about these two sections 
in the future, because they're not consistent.


- Mark Alley

On 2/29/2024 1:47 PM, Scott Kitterman wrote:

Okay.  I think 8.6 is the one in error.  You see how this is going to go, right?

Scott K

On February 29, 2024 7:45:15 PM UTC, Todd 
Herr  wrote:

It is not my intent here to relitigate any issues.

Rather, I believe that the text in 7.6 is wrong, likely due to an oversight
on my part when the new text in 8.6 was published, and I just want to
confirm that 7.6 is indeed wrong.

On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman
wrote:


In what way is this a new issue that has not already been argued to death
in the WG?  I think for WGLC, we've already done this. We will, no doubt
get to have this conversation during the IETF last call, but for the
working group, this strikes me as exactly the type of relitigation of
issues we've been counseled to avoid.

Scott K

On February 29, 2024 6:54:57 PM UTC, Todd Herr  wrote:

Colleagues,

I've been reading DMARCbic rev -30 today with a plan to collect the first
set of minor edits and I came across a sentence that I believe goes beyond
minor, so wanted to get a sanity check.

Section 7.6, Domain Owner Actions, ends with the following sentence:

In particular, this document makes explicit that domains for
general-purpose email MUST NOT deploy a DMARC policy of p=reject.


I don't believe this to be true, however. Rather, Section 8.6,
Interoperability Considerations, says SHOULD NOT on the topic (e.g., "It

is

therefore critical that domains that host users who might post messages to
mailing lists SHOULD NOT publish p=reject")

Section 7.6 therefore should be updated to read "domains for
general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", yes?


___
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


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

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Scott Kitterman]

Did we?  The technical implications for interoperability are clear, so I don't 
see why we would have decided to ignore them?

If you want to change it now, I don't see how you avoid reopening the issue 
(you can't reopen the issue without reopening the issue).

Scott K

On February 29, 2024 7:53:10 PM UTC, Seth Blank 
 wrote:
>I thought we landed on SHOULD NOT, there was strong resistance to MUST NOT
>
>On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman 
>wrote:
>
>> Okay.  I think 8.6 is the one in error.  You see how this is going to go,
>> right?
>>
>> Scott K
>>
>> On February 29, 2024 7:45:15 PM UTC, Todd Herr > 40valimail@dmarc.ietf.org> wrote:
>> >It is not my intent here to relitigate any issues.
>> >
>> >Rather, I believe that the text in 7.6 is wrong, likely due to an
>> oversight
>> >on my part when the new text in 8.6 was published, and I just want to
>> >confirm that 7.6 is indeed wrong.
>> >
>> >On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman 
>> >wrote:
>> >
>> >> In what way is this a new issue that has not already been argued to
>> death
>> >> in the WG?  I think for WGLC, we've already done this. We will, no doubt
>> >> get to have this conversation during the IETF last call, but for the
>> >> working group, this strikes me as exactly the type of relitigation of
>> >> issues we've been counseled to avoid.
>> >>
>> >> Scott K
>> >>
>> >> On February 29, 2024 6:54:57 PM UTC, Todd Herr > >> 40valimail@dmarc.ietf.org> wrote:
>> >> >Colleagues,
>> >> >
>> >> >I've been reading DMARCbic rev -30 today with a plan to collect the
>> first
>> >> >set of minor edits and I came across a sentence that I believe goes
>> beyond
>> >> >minor, so wanted to get a sanity check.
>> >> >
>> >> >Section 7.6, Domain Owner Actions, ends with the following sentence:
>> >> >
>> >> >In particular, this document makes explicit that domains for
>> >> >general-purpose email MUST NOT deploy a DMARC policy of p=reject.
>> >> >
>> >> >
>> >> >I don't believe this to be true, however. Rather, Section 8.6,
>> >> >Interoperability Considerations, says SHOULD NOT on the topic (e.g.,
>> "It
>> >> is
>> >> >therefore critical that domains that host users who might post
>> messages to
>> >> >mailing lists SHOULD NOT publish p=reject")
>> >> >
>> >> >Section 7.6 therefore should be updated to read "domains for
>> >> >general-purpose email SHOULD NOT deploy a DMARC policy of p=reject",
>> yes?
>> >> >
>> >>
>> >> ___
>> >> 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] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Todd Herr]

I believe this to be the thread of reference on the topic -
https://mailarchive.ietf.org/arch/msg/dmarc/ink9cG3bono8O2Vif_ibiexad0A/

That's the thread I used to guide the updates to 8.6 in rev -29, anyway.

On Thu, Feb 29, 2024 at 2:53 PM Seth Blank  wrote:

> I thought we landed on SHOULD NOT, there was strong resistance to MUST NOT
>
> On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman 
> wrote:
>
>> Okay.  I think 8.6 is the one in error.  You see how this is going to go,
>> right?
>>
>> Scott K
>>
>> On February 29, 2024 7:45:15 PM UTC, Todd Herr > 40valimail@dmarc.ietf.org> wrote:
>> >It is not my intent here to relitigate any issues.
>> >
>> >Rather, I believe that the text in 7.6 is wrong, likely due to an
>> oversight
>> >on my part when the new text in 8.6 was published, and I just want to
>> >confirm that 7.6 is indeed wrong.
>> >
>> >On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman 
>> >wrote:
>> >
>> >> In what way is this a new issue that has not already been argued to
>> death
>> >> in the WG?  I think for WGLC, we've already done this. We will, no
>> doubt
>> >> get to have this conversation during the IETF last call, but for the
>> >> working group, this strikes me as exactly the type of relitigation of
>> >> issues we've been counseled to avoid.
>> >>
>> >> Scott K
>> >>
>> >> On February 29, 2024 6:54:57 PM UTC, Todd Herr > >> 40valimail@dmarc.ietf.org> wrote:
>> >> >Colleagues,
>> >> >
>> >> >I've been reading DMARCbic rev -30 today with a plan to collect the
>> first
>> >> >set of minor edits and I came across a sentence that I believe goes
>> beyond
>> >> >minor, so wanted to get a sanity check.
>> >> >
>> >> >Section 7.6, Domain Owner Actions, ends with the following sentence:
>> >> >
>> >> >In particular, this document makes explicit that domains for
>> >> >general-purpose email MUST NOT deploy a DMARC policy of p=reject.
>> >> >
>> >> >
>> >> >I don't believe this to be true, however. Rather, Section 8.6,
>> >> >Interoperability Considerations, says SHOULD NOT on the topic (e.g.,
>> "It
>> >> is
>> >> >therefore critical that domains that host users who might post
>> messages to
>> >> >mailing lists SHOULD NOT publish p=reject")
>> >> >
>> >> >Section 7.6 therefore should be updated to read "domains for
>> >> >general-purpose email SHOULD NOT deploy a DMARC policy of p=reject",
>> yes?
>> >> >
>> >>
>> >> ___
>> >> 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
>>
>
>
> --
>
> *Seth Blank * | Chief Technology Officer
> *e:* s...@valimail.com
> *p:*
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Seth Blank]

I thought we landed on SHOULD NOT, there was strong resistance to MUST NOT

On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman 
wrote:

> Okay.  I think 8.6 is the one in error.  You see how this is going to go,
> right?
>
> Scott K
>
> On February 29, 2024 7:45:15 PM UTC, Todd Herr  40valimail@dmarc.ietf.org> wrote:
> >It is not my intent here to relitigate any issues.
> >
> >Rather, I believe that the text in 7.6 is wrong, likely due to an
> oversight
> >on my part when the new text in 8.6 was published, and I just want to
> >confirm that 7.6 is indeed wrong.
> >
> >On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman 
> >wrote:
> >
> >> In what way is this a new issue that has not already been argued to
> death
> >> in the WG?  I think for WGLC, we've already done this. We will, no doubt
> >> get to have this conversation during the IETF last call, but for the
> >> working group, this strikes me as exactly the type of relitigation of
> >> issues we've been counseled to avoid.
> >>
> >> Scott K
> >>
> >> On February 29, 2024 6:54:57 PM UTC, Todd Herr  >> 40valimail@dmarc.ietf.org> wrote:
> >> >Colleagues,
> >> >
> >> >I've been reading DMARCbic rev -30 today with a plan to collect the
> first
> >> >set of minor edits and I came across a sentence that I believe goes
> beyond
> >> >minor, so wanted to get a sanity check.
> >> >
> >> >Section 7.6, Domain Owner Actions, ends with the following sentence:
> >> >
> >> >In particular, this document makes explicit that domains for
> >> >general-purpose email MUST NOT deploy a DMARC policy of p=reject.
> >> >
> >> >
> >> >I don't believe this to be true, however. Rather, Section 8.6,
> >> >Interoperability Considerations, says SHOULD NOT on the topic (e.g.,
> "It
> >> is
> >> >therefore critical that domains that host users who might post
> messages to
> >> >mailing lists SHOULD NOT publish p=reject")
> >> >
> >> >Section 7.6 therefore should be updated to read "domains for
> >> >general-purpose email SHOULD NOT deploy a DMARC policy of p=reject",
> yes?
> >> >
> >>
> >> ___
> >> 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
>


-- 

*Seth Blank * | Chief Technology Officer
*e:* s...@valimail.com
*p:*

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Scott Kitterman]

Okay.  I think 8.6 is the one in error.  You see how this is going to go, right?

Scott K

On February 29, 2024 7:45:15 PM UTC, Todd Herr 
 wrote:
>It is not my intent here to relitigate any issues.
>
>Rather, I believe that the text in 7.6 is wrong, likely due to an oversight
>on my part when the new text in 8.6 was published, and I just want to
>confirm that 7.6 is indeed wrong.
>
>On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman 
>wrote:
>
>> In what way is this a new issue that has not already been argued to death
>> in the WG?  I think for WGLC, we've already done this. We will, no doubt
>> get to have this conversation during the IETF last call, but for the
>> working group, this strikes me as exactly the type of relitigation of
>> issues we've been counseled to avoid.
>>
>> Scott K
>>
>> On February 29, 2024 6:54:57 PM UTC, Todd Herr > 40valimail@dmarc.ietf.org> wrote:
>> >Colleagues,
>> >
>> >I've been reading DMARCbic rev -30 today with a plan to collect the first
>> >set of minor edits and I came across a sentence that I believe goes beyond
>> >minor, so wanted to get a sanity check.
>> >
>> >Section 7.6, Domain Owner Actions, ends with the following sentence:
>> >
>> >In particular, this document makes explicit that domains for
>> >general-purpose email MUST NOT deploy a DMARC policy of p=reject.
>> >
>> >
>> >I don't believe this to be true, however. Rather, Section 8.6,
>> >Interoperability Considerations, says SHOULD NOT on the topic (e.g., "It
>> is
>> >therefore critical that domains that host users who might post messages to
>> >mailing lists SHOULD NOT publish p=reject")
>> >
>> >Section 7.6 therefore should be updated to read "domains for
>> >general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", yes?
>> >
>>
>> ___
>> 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] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Todd Herr]

It is not my intent here to relitigate any issues.

Rather, I believe that the text in 7.6 is wrong, likely due to an oversight
on my part when the new text in 8.6 was published, and I just want to
confirm that 7.6 is indeed wrong.

On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman 
wrote:

> In what way is this a new issue that has not already been argued to death
> in the WG?  I think for WGLC, we've already done this. We will, no doubt
> get to have this conversation during the IETF last call, but for the
> working group, this strikes me as exactly the type of relitigation of
> issues we've been counseled to avoid.
>
> Scott K
>
> On February 29, 2024 6:54:57 PM UTC, Todd Herr  40valimail@dmarc.ietf.org> wrote:
> >Colleagues,
> >
> >I've been reading DMARCbic rev -30 today with a plan to collect the first
> >set of minor edits and I came across a sentence that I believe goes beyond
> >minor, so wanted to get a sanity check.
> >
> >Section 7.6, Domain Owner Actions, ends with the following sentence:
> >
> >In particular, this document makes explicit that domains for
> >general-purpose email MUST NOT deploy a DMARC policy of p=reject.
> >
> >
> >I don't believe this to be true, however. Rather, Section 8.6,
> >Interoperability Considerations, says SHOULD NOT on the topic (e.g., "It
> is
> >therefore critical that domains that host users who might post messages to
> >mailing lists SHOULD NOT publish p=reject")
> >
> >Section 7.6 therefore should be updated to read "domains for
> >general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", yes?
> >
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[John Levine]

It appears that Scott Kitterman   said:
>In what way is this a new issue that has not already been argued to death in 
>the WG?  I think for WGLC, we've already done this. We will, no doubt get to 
>have this conversation during the IETF
>last call, but for the working group, this strikes me as exactly the type of 
>relitigation of issues we've been counseled to avoid.

Yup. No possible change will make everyone happier, or even everyone
no less happy than they are now, so leave it alone. I agree we'll hear
about it in IETF LC no matter what it says.

R's,
John


>On February 29, 2024 6:54:57 PM UTC, Todd Herr 
> wrote:
>>Colleagues,
>>
>>I've been reading DMARCbic rev -30 today with a plan to collect the first
>>set of minor edits and I came across a sentence that I believe goes beyond
>>minor, so wanted to get a sanity check.
>>
>>Section 7.6, Domain Owner Actions, ends with the following sentence:
>>
>>In particular, this document makes explicit that domains for
>>general-purpose email MUST NOT deploy a DMARC policy of p=reject.
>>
>>
>>I don't believe this to be true, however. Rather, Section 8.6,
>>Interoperability Considerations, says SHOULD NOT on the topic (e.g., "It is
>>therefore critical that domains that host users who might post messages to
>>mailing lists SHOULD NOT publish p=reject")
>>
>>Section 7.6 therefore should be updated to read "domains for
>>general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", yes?
>>
>


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

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Scott Kitterman]

In what way is this a new issue that has not already been argued to death in 
the WG?  I think for WGLC, we've already done this. We will, no doubt get to 
have this conversation during the IETF last call, but for the working group, 
this strikes me as exactly the type of relitigation of issues we've been 
counseled to avoid.

Scott K

On February 29, 2024 6:54:57 PM UTC, Todd Herr 
 wrote:
>Colleagues,
>
>I've been reading DMARCbic rev -30 today with a plan to collect the first
>set of minor edits and I came across a sentence that I believe goes beyond
>minor, so wanted to get a sanity check.
>
>Section 7.6, Domain Owner Actions, ends with the following sentence:
>
>In particular, this document makes explicit that domains for
>general-purpose email MUST NOT deploy a DMARC policy of p=reject.
>
>
>I don't believe this to be true, however. Rather, Section 8.6,
>Interoperability Considerations, says SHOULD NOT on the topic (e.g., "It is
>therefore critical that domains that host users who might post messages to
>mailing lists SHOULD NOT publish p=reject")
>
>Section 7.6 therefore should be updated to read "domains for
>general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", yes?
>

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

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Seth Blank]

This statement is patently false, though, and the guidance goes well beyond
operational reality. I think the statement should be struck in its entirety.

All the major free mail providers are moving to have DMARC policies on
their domains. Yahoo has it, 1und1 has it, Gmail has committed to do it.
That's 2.5bn+ inboxes protected by DMARC. Why would we have text says MUST
or SHOULD NOT against a practice that's protecting inboxes worldwide and is
picking up steam across them all due to the very real security benefit of
the document this guidance is in...?

On Thu, Feb 29, 2024 at 1:55 PM Todd Herr  wrote:

> Colleagues,
>
> I've been reading DMARCbic rev -30 today with a plan to collect the first
> set of minor edits and I came across a sentence that I believe goes beyond
> minor, so wanted to get a sanity check.
>
> Section 7.6, Domain Owner Actions, ends with the following sentence:
>
> In particular, this document makes explicit that domains for
> general-purpose email MUST NOT deploy a DMARC policy of p=reject.
>
>
> I don't believe this to be true, however. Rather, Section 8.6,
> Interoperability Considerations, says SHOULD NOT on the topic (e.g., "It
> is therefore critical that domains that host users who might post messages
> to mailing lists SHOULD NOT publish p=reject")
>
> Section 7.6 therefore should be updated to read "domains for
> general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", yes?
>
> --
>
> *Todd Herr * | Technical Director, Standards & Ecosystem
> *e:* todd.h...@valimail.com
> *p:* 703-220-4153
> *m:* 703.220.4153
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Seth Blank * | Chief Technology Officer
*e:* s...@valimail.com
*p:*

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

[Todd Herr]

Colleagues,

I've been reading DMARCbic rev -30 today with a plan to collect the first
set of minor edits and I came across a sentence that I believe goes beyond
minor, so wanted to get a sanity check.

Section 7.6, Domain Owner Actions, ends with the following sentence:

In particular, this document makes explicit that domains for
general-purpose email MUST NOT deploy a DMARC policy of p=reject.


I don't believe this to be true, however. Rather, Section 8.6,
Interoperability Considerations, says SHOULD NOT on the topic (e.g., "It is
therefore critical that domains that host users who might post messages to
mailing lists SHOULD NOT publish p=reject")

Section 7.6 therefore should be updated to read "domains for
general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", yes?

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc