Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 1/5

On Saturday, December 4, 2021 11:12:22 PM EST Murray S. Kucherawy wrote: > On Fri, Dec 3, 2021 at 9:37 AM Alessandro Vesely wrote: > > The second paragraph says: > > Section 8 creates a registry for known DMARC tags and registers the > > initial set defined in this document. Only tags def

Re: [dmarc-ietf] 3.2.6. Non-existent Domains

On Sat, Dec 4, 2021 at 11:14 PM Scott Kitterman wrote: > Should we modify the definition of non-existent domains so that a domain > that > only has an RFC 7505 null mx record is still considered non-existent? > > I'll propose text if it's agreed this would be a useful change? > > Scott K > > This

[dmarc-ietf] PSD Flag

I think the addition of the PSD flag to support organizational domain determination is a good change. I have some quibbles about the exact definition though: > psd: A flag indicating whether the domain is a PSD. (plain-text; > OPTIONAL; default is 'n'). Possible values are: > >

[dmarc-ietf] 3.2.6. Non-existent Domains

Should we modify the definition of non-existent domains so that a domain that only has an RFC 7505 null mx record is still considered non-existent? I'll propose text if it's agreed this would be a useful change? Scott K ___ dmarc mailing list dmarc@i

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 1/5

On Fri, Dec 3, 2021 at 9:37 AM Alessandro Vesely wrote: > The second paragraph says: > > Section 8 creates a registry for known DMARC tags and registers the > initial set defined in this document. Only tags defined in this > document or in later extensions, and thus added to that reg

Re: [dmarc-ietf] draft-ietf-dmarc-dmarcbis-04 Release Notes

On Thu, Dec 2, 2021 at 12:51 PM Todd Herr wrote: > The change log (Appendix C) has been removed, because even though there > are only two new ideas introduced, there is enough shifting of text to make > this revision effectively a reboot. > No objection to that change, but this leads me to a sug

[dmarc-ietf] RFC 9091 Downrefs

Currently the draft (as did the previous revision) has: > 3.2.8. Public Suffix Domain (PSD) > > The term Public Suffix Domain is defined in [RFC9091]. > > 3.2.9. Public Suffix Operator (PSO) > > The term Public Suffix Operator is defined in [RFC9

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

On Sat, Dec 4, 2021 at 4:51 PM Dave Crocker wrote: > I'm going to suggest that that analysis is not formally correct. > > The DKIM specification precisely defines validation for the signature > and it precisely defines what coverage is 'required'. > > A receiver can indeed choose to apply stricte

Re: [dmarc-ietf] Additions to introduction

On December 4, 2021 10:09:48 PM UTC, Seth Blank wrote: >On Sat, Dec 4, 2021 at 1:34 PM Tim Wicinski wrote: > >> >> I am Ok with adding text of this nature, and I think it's helpful in >> explaining to folks approaching >> DMARC for the first time. But I start to lose focus on reading long >>

Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)

As discussion after I had filed this makes clear, my proposed solution isn't a great one. Since we're well on our way towards removing PSL use from the DMARC revision, I don't think it matters a lot whether we reject it or hold for document update and mark it resolved when the new revision is f

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

On December 4, 2021 10:35:17 PM UTC, Douglas Foster wrote: >I have multiple objections to this paragraph in section 5.7.2 > >"Heuristics applied in the absence of use by a Domain Owner of either SPF >or DKIM (e.g., [Best-Guess-SPF >

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

On Sat, Dec 4, 2021 at 17:48 Scott Kitterman wrote: > > > On December 5, 2021 12:23:40 AM UTC, "Murray S. Kucherawy" < > superu...@gmail.com> wrote: > >On Sat, Dec 4, 2021 at 2:35 PM Douglas Foster < > >dougfoster.emailstanda...@gmail.com> wrote: > > > >> I think this text was inserted because of

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

On December 5, 2021 12:23:40 AM UTC, "Murray S. Kucherawy" wrote: >On Sat, Dec 4, 2021 at 2:35 PM Douglas Foster < >dougfoster.emailstanda...@gmail.com> wrote: > >> I think this text was inserted because of an open ticket when discussion >> was going nowhere and a new draft was created. Perha

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

On 12/4/2021 4:23 PM, Murray S. Kucherawy wrote: DKIM, for example, allows verifiers to decide what an acceptable signature is (a favorite I remember from the early days was "I don't want to accept a DKIM signature that didn't cover the Subject field"), which again means one site's "pass" is an

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

On Sat, Dec 4, 2021 at 2:35 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I think this text was inserted because of an open ticket when discussion > was going nowhere and a new draft was created. Perhaps the originator of > that ticket can elaborate on his thinking. > I belie

[dmarc-ietf] Best Guess SPF should not be deprecated.

I have multiple objections to this paragraph in section 5.7.2 "Heuristics applied in the absence of use by a Domain Owner of either SPF or DKIM (e.g., [Best-Guess-SPF ]) SHOULD NOT be used, as it may be the case tha

Re: [dmarc-ietf] Additions to introduction

On Sat, Dec 4, 2021 at 1:34 PM Tim Wicinski wrote: > > I am Ok with adding text of this nature, and I think it's helpful in > explaining to folks approaching > DMARC for the first time. But I start to lose focus on reading long > introductions (okay boomer). > > Maybe the Intro could get a sectio

Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)

On Sat, Dec 4, 2021 at 10:00 AM John Levine wrote: > It appears that Murray S. Kucherawy said: > >-=-=-=-=-=- > > > >This was reported but not sent to the WG. I believe the right disposition > >is "Hold for Document Update". Does anyone want to argue for "Rejected" > or > >"Verified"? > > Rej

Re: [dmarc-ietf] Additions to introduction

I am Ok with adding text of this nature, and I think it's helpful in explaining to folks approaching DMARC for the first time. But I start to lose focus on reading long introductions (okay boomer). Maybe the Intro could get a section or two to help focus it. I am glad to assist wordsmithing Doug'

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5

Argh: On Sat, Dec 4, 2021 at 1:30 PM Murray S. Kucherawy wrote: > > I'd be happy with either of these two definitions: > > (a) All messages are subjected to DMARC checking, and "pct" identifies the > percentage of messages failing the check that should be subjected to the > policy; > > (b) "pct"

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5

On Fri, Dec 3, 2021 at 10:38 AM Todd Herr wrote: > We can have this conversation too. I will promise, however, that if the > group decides to keep 'pct', I will absolutely insist that the first > sentence in its definition be changed. Somehow, RFC 7489 got released with > this text: > >pct:

Re: [dmarc-ietf] Additions to introduction

On Sat, Dec 4, 2021 at 9:55 AM John Levine wrote: > The point of a spec is to tell people how to interpoerate. I don't see > how this > contributes to that. > Lots of specifications include informative guidance or best practices advice as well as normative specification. DKIM has loads of it.

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5

On Sat, Dec 4, 2021 at 6:20 AM Alessandro Vesely wrote: > On Fri 03/Dec/2021 19:38:26 +0100 Todd Herr wrote: > > On Fri, Dec 3, 2021 at 12:40 PM Alessandro Vesely > wrote: > >> > >> last message for today: the "t" tag instead of "pct". > >> > >> That's the only part which breaks existing record

Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)

I must agree with Mr Levine on this. tim On Sat, Dec 4, 2021 at 1:00 PM John Levine wrote: > It appears that Murray S. Kucherawy said: > >-=-=-=-=-=- > > > >This was reported but not sent to the WG. I believe the right disposition > >is "Hold for Document Update". Does anyone want to argue

Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)

It appears that Murray S. Kucherawy said: >-=-=-=-=-=- > >This was reported but not sent to the WG. I believe the right disposition >is "Hold for Document Update". Does anyone want to argue for "Rejected" or >"Verified"? Reject it. Whether you choose to believe the non-ICANN part of the PSL i

Re: [dmarc-ietf] Additions to introduction

It appears that Douglas Foster said: >-=-=-=-=-=- > >I propose that a paragraph along these lines be inserted into the >introduction: > >The DMARC test is characterized by a one-tailed error distribution: > Messages which pass verification have a low probability of being false >positives of actua

Re: [dmarc-ietf] Additions to introduction

After I sent this, I wondered if I needed to add more text to explain that "manual review" means "manual review, followed by local policy changes, so that manual review will no longer be necessary on messages with the same identifiers." If a reader thinks "manual review" means "look at every mess

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5

On Fri 03/Dec/2021 19:38:26 +0100 Todd Herr wrote: On Fri, Dec 3, 2021 at 12:40 PM Alessandro Vesely wrote: last message for today: the "t" tag instead of "pct". That's the only part which breaks existing records. According to the last paragraph of this section, doing so requires v=DMARC2.