> 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,
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.
>
>
>
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
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
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,
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 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
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
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
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
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)
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.
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
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
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,
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
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
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
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
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
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.
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
22 matches
Mail list logo