[dmarc-ietf] DMARC exceptions

DMARC is an imperfect tool, as evidenced by the mailing list problem, among others. DMARCbis has failed to integrate RFC7489 with RFC 7960, because it provides no discussion of the circumstances where an evaluator should override the DMARC result. I believe DMARCbis needs a discussion about the

Re: [dmarc-ietf] Problem with multiple policies, different alignment

Some universities' resolvers return NOERROR instead of NXDOMAIN (samba4 server used as AD, and resolvers) They still do that? Wow. At least that won't screw up DMARC evaluators too much. In any event, I don't think it's our job to redesign our specs for the benefit of people who've

Re: [dmarc-ietf] Problem with multiple policies, different alignment

> I'm fairly sure they would say that behavior is extremely broken. It is so broken that I doubt it's actuallly happening other than in obscure corner cases involving ancient hardware with a thick layer of dust. Some universities' resolvers return NOERROR instead of NXDOMAIN (samba4 server

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

> If we need some real world examples of this, got a few here: According to my measurements, 14M domain names out of 280M active domains have a CNAME at _dmarc. 871,245 has a valid DMARC record. Part of them, 7609 are a 1M top popular domain (tranco) For those without DMARC records (I

Re: [dmarc-ietf] Problem with multiple policies, different alignment

It appears that Murray S. Kucherawy said: >It's alarming to hear that NXDOMAIN replies are never issued or (perhaps >more likely) are dropped by some software or firewalls. It completely >prevents any benefits of negative caching. I wonder what the DNS community >might have to say about this

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

On Fri, Mar 15, 2024 at 9:11 AM John Levine wrote: > It appears that Todd Herr said: > >I agree that clarifying it can't hurt, obviously, ... > > I disagree, it does hurt. > > If we say you're allowed to use CNAMEs to point to DMARC records, > people are to say uh oh, is there something

Re: [dmarc-ietf] A.5 Issues with ADSP in Operation

On Fri, Mar 15, 2024 at 12:55 AM Alessandro Vesely wrote: > On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote: > > On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely > wrote: > >> On 12/03/2024 03:18, Neil Anuskiewicz wrote: > >> > Please remove the pct tag from the spec. > >> > >> It has been

Re: [dmarc-ietf] DMARCbis WGLC Issue 134 - What To Do With Appendix A.5?

On Fri, Mar 15, 2024 at 3:20 AM John Levine wrote: > As an author of the ADSP RFC, I enthusiastically support dropping it > into the memory hole. It was a bad idea then and time has not improved > it. I tend to agree. That appendix was meant to answer the question "Why DMARC and not ADSP?"

Re: [dmarc-ietf] Problem with multiple policies, different alignment

On Thu, Mar 14, 2024 at 9:17 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > All of this is based on my slightly confrontational comment that "Tree > Walk is inefficient and unreliable", which maybe needs elaboration. My > approach to the problem changed dramatically when I

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

On 3/14/2024 6:11 PM, John Levine wrote: It appears that Todd Herr said: I agree that clarifying it can't hurt, obviously, ... I disagree, it does hurt. If we say you're allowed to use CNAMEs to point to DMARC records, people are to say uh oh, is there something special here? What about

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

It appears that Todd Herr said: >I agree that clarifying it can't hurt, obviously, ... I disagree, it does hurt. If we say you're allowed to use CNAMEs to point to DMARC records, people are to say uh oh, is there something special here? What about DKIM records? what about SPF records? how

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

It appears that Todd Herr said: >The reasons given were: > > 1. https://www.rfc-editor.org/rfc/rfc5863#section-4.1 I am reasonably sure it was referring to DNS crudware that wouldn't let you put an underscore in the name, or that limited TXT records to a single 255 byte string, not CNAMEs. >

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

"Explaining how DNS works is out of scope." Scott is right. Also, some folks point use something other than CNAME $ dig +noall +answer _dmarc.valimail.com ns _dmarc.valimail.com. 300 IN NS ns.vali.email. tjw@m2[1098]: dig +noall +answer _dmarc.valimail.com txt _dmarc.valimail.com. 595 IN TXT

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

On March 14, 2024 8:38:17 PM UTC, Todd Herr wrote: >On Thu, Mar 14, 2024 at 4:34 PM Scott Kitterman >wrote: > >> >> I think this is correct. I think it's obviously enough correct that I'm >> surprised anyone was confused. >> >> Do we know what the theory was that led people to think

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

On Thu, Mar 14, 2024 at 4:52 PM Hector Santos wrote: > > On Mar 14, 2024, at 4:02 PM, Todd Herr 40valimail@dmarc.ietf.org> wrote: > > On Thu, Mar 14, 2024 at 3:25 PM Hector Santos 40isdg@dmarc.ietf.org> wrote: > >> On Mar 14, 2024, at 10:09 AM, Todd Herr >

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

On Thu, Mar 14, 2024 at 5:05 PM Mark Alley wrote: > On 3/14/2024 3:49 PM, Todd Herr wrote: > > On Thu, Mar 14, 2024 at 4:43 PM Mark Alley 40tekmarc@dmarc.ietf.org> wrote: > >> On 3/14/2024 3:38 PM, Todd Herr wrote: >> >> On Thu, Mar 14, 2024 at 4:34 PM Scott Kitterman >> wrote: >> >>> >>>

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

On 3/14/2024 3:49 PM, Todd Herr wrote: On Thu, Mar 14, 2024 at 4:43 PM Mark Alley wrote: On 3/14/2024 3:38 PM, Todd Herr wrote: On Thu, Mar 14, 2024 at 4:34 PM Scott Kitterman wrote: I think this is correct.  I think it's obviously enough correct that I'm

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

> On Mar 14, 2024, at 4:02 PM, Todd Herr > wrote: > > On Thu, Mar 14, 2024 at 3:25 PM Hector Santos > mailto:40isdg@dmarc.ietf.org>> wrote: >>> On Mar 14, 2024, at 10:09 AM, Todd Herr >>> >> > wrote: >>> To configure SPF for DMARC, the Domain Owner

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

There are folks who publish NS records at _dmarc.example.com that point to some super fancy DNS service that return DMARC TXT records. tim On Thu, Mar 14, 2024 at 4:19 PM Todd Herr wrote: > Colleagues, > > There was a discussion among M3AAWG members on March 13 that centered on > the question

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

On Thu, Mar 14, 2024 at 4:43 PM Mark Alley wrote: > On 3/14/2024 3:38 PM, Todd Herr wrote: > > On Thu, Mar 14, 2024 at 4:34 PM Scott Kitterman > wrote: > >> >> I think this is correct. I think it's obviously enough correct that I'm >> surprised anyone was confused. >> >> Do we know what the

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

- Mark Alley On 3/14/2024 3:38 PM, Todd Herr wrote: On Thu, Mar 14, 2024 at 4:34 PM Scott Kitterman wrote: I think this is correct.  I think it's obviously enough correct that I'm surprised anyone was confused. Do we know what the theory was that led people to think otherwise?

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

On Thu, Mar 14, 2024 at 4:34 PM Scott Kitterman wrote: > > I think this is correct. I think it's obviously enough correct that I'm > surprised anyone was confused. > > Do we know what the theory was that led people to think otherwise? > > Seems to me we don't really need this, but maybe there's

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

On March 14, 2024 8:18:31 PM UTC, Todd Herr wrote: >Colleagues, > >There was a discussion among M3AAWG members on March 13 that centered on >the question of whether DMARC records can be published in DNS as CNAMEs, >e.g., > >_dmarc.example.com IN CNAME _dmarc.example.org > >_dmarc.example.org

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

If we need some real world examples of this, got a few here: _dmarc.oit.alabama.gov _dmarc.tjx.com _dmarc.walmart.com _dmarc.novanta.com - Mark Alley On 3/14/2024 3:18 PM, Todd Herr wrote: Colleagues, There was a discussion among M3AAWG members on March 13 that centered on the question

[dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

Colleagues, There was a discussion among M3AAWG members on March 13 that centered on the question of whether DMARC records can be published in DNS as CNAMEs, e.g., _dmarc.example.com IN CNAME _dmarc.example.org _dmarc.example.org IN TXT "v=DMARC1; p=reject; rua= mailto:dmarc-repo...@example.org

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

On Thu, Mar 14, 2024 at 3:25 PM Hector Santos wrote: > On Mar 14, 2024, at 10:09 AM, Todd Herr 40valimail@dmarc.ietf.org> wrote: > > To configure SPF for DMARC, the Domain Owner MUST choose a domain to use > as the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail > that

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

> On Mar 14, 2024, at 10:09 AM, Todd Herr > wrote: > > > In the ticket, I propose the following replacement text: > > == > Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376], in order to take > full advantage of DMARC, a Domain Owner

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

It appears that Scott Kitterman said: >> SPF it treated in multiple places. We cannot warn against a bad practice in >> one place (135) and recommend it unconditionally in another (132). > >That is exactly how one handles Security Considerations. So 132 says do SPF. >Security Considerations

Re: [dmarc-ietf] A.5 Issues with ADSP in Operation

> On Mar 9, 2024, at 10:05 AM, Alessandro Vesely wrote: > > Hi, > > as ADSP is historical, perhaps we can strike A5 entirely. If not, we should > at least eliminate bullet 5: > > 5. ADSP has no support for a slow rollout, i.e., no way to configure > a percentage of email on which

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

On Thursday, March 14, 2024 1:59:58 PM EDT Alessandro Vesely wrote: > On Thu 14/Mar/2024 18:35:05 +0100 Scott Kitterman wrote: > > On Thursday, March 14, 2024 11:27:03 AM EDT Alessandro Vesely wrote: > >> On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote: > >>> [...] > >>> > >>> In the ticket, I

Re: [dmarc-ietf] A.5 Issues with ADSP in Operation

On 14/03/2024 19:06, Matt V wrote: On Thu, Mar 14, 2024 at 10:55 AM Alessandro Vesely wrote: On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote: On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely wrote: On 12/03/2024 03:18, Neil Anuskiewicz wrote: Please remove the pct tag from the spec.

Re: [dmarc-ietf] A.5 Issues with ADSP in Operation

On Thu, Mar 14, 2024 at 10:55 AM Alessandro Vesely wrote: > On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote: > > On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely > wrote: > >> On 12/03/2024 03:18, Neil Anuskiewicz wrote: > >> > Please remove the pct tag from the spec. > >> > >> It has been

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

On Thu 14/Mar/2024 18:35:05 +0100 Scott Kitterman wrote: On Thursday, March 14, 2024 11:27:03 AM EDT Alessandro Vesely wrote: On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote: [...] In the ticket, I propose the following replacement text: ==

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

On Thursday, March 14, 2024 11:27:03 AM EDT Alessandro Vesely wrote: > On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote: > > [...] > > > > In the ticket, I propose the following replacement text: > > > > == > > Because DMARC relies on SPF

Re: [dmarc-ietf] DMARCbis WGLC Issue 134 - What To Do With Appendix A.5?

It appears that Todd Herr said: >-=-=-=-=-=- > >Colleagues, > >Two people have spoken up on list asking for removal of this section >(thread subject is "A.5 Issues with ADSP in Operation") while one person >has registered opposition to the idea. I don't believe this is anywhere >close to

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote: > Colleagues, > > Issue 135 is open for the subject topic. Please add your thoughts to this > thread and/or to the issue in Github. > > Thank you. I'd suggest we discuss where to say it first. I think the right place is security

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

On Thu 14/Mar/2024 16:44:22 +0100 Todd Herr wrote: Issue 135 is open for the subject topic. Please add your thoughts to this thread and/or to the issue in Github. I proposed an alternative text for section 5, Policy[*]. I repeat it here with an added sentence: OLD A Domain Owner or

Re: [dmarc-ietf] Problem with multiple policies, different alignment

On Thu 14/Mar/2024 12:17:17 +0100 Douglas Foster wrote: Your latter questions were similar to Ale's - If the SPF/DKIM domain is a parent of the From domain, then we check its relationship to the organizational domain. If it is a parent of the organizational domain, the result is unaligned.

[dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

Colleagues, Issue 135 is open for the subject topic. Please add your thoughts to this thread and/or to the issue in Github. Thank you. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com Phone: 703-220-4153 This email and all data transmitted with it

Re: [dmarc-ietf] DMARCbis WGLC Issue 134 - What To Do With Appendix A.5?

On Thu 14/Mar/2024 15:53:30 +0100 Todd Herr wrote: Colleagues, Two people have spoken up on list asking for removal of this section (thread subject is "A.5 Issues with ADSP in Operation") while one person has registered opposition to the idea. I don't believe this is anywhere close to critical

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote: [...] In the ticket, I propose the following replacement text: == Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376], in order to take full advantage of DMARC, a Domain Owner MUST first

Re: [dmarc-ietf] picking nits with the ABNF

On Thu, Mar 14, 2024 at 11:04 AM Alessandro Vesely wrote: > On Thu 14/Mar/2024 15:38:23 +0100 Todd Herr wrote: > > To summarize this thread, I see three nits, all of which have been added > to > > issue 133: > > > [snip] > > > > 3. Section 5.3., General Record Format, update the description of

Re: [dmarc-ietf] picking nits with the ABNF

On Thu 14/Mar/2024 15:38:23 +0100 Todd Herr wrote: To summarize this thread, I see three nits, all of which have been added to issue 133: 1. Section 5.4, Formal Definition, reword the comments for dmarc-uri to be: ; "URI" is imported from [RFC3986]; ; commas (ASCII

Re: [dmarc-ietf] A.5 Issues with ADSP in Operation

On Thu 14/Mar/2024 15:47:14 +0100 Todd Herr wrote: On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely wrote: On 12/03/2024 03:18, Neil Anuskiewicz wrote: > Please remove the pct tag from the spec. It has been removed already, which is incompatible with current records. I don't believe your

[dmarc-ietf] DMARCbis WGLC Issue 134 - What To Do With Appendix A.5?

Colleagues, Two people have spoken up on list asking for removal of this section (thread subject is "A.5 Issues with ADSP in Operation") while one person has registered opposition to the idea. I don't believe this is anywhere close to critical mass for consensus. I've opened the subject issue

Re: [dmarc-ietf] A.5 Issues with ADSP in Operation

On Tue, Mar 12, 2024 at 5:19 AM Alessandro Vesely wrote: > On 12/03/2024 03:18, Neil Anuskiewicz wrote: > > Please remove the pct tag from the spec. > > It has been removed already, which is incompatible with current records. > I don't believe your assertion of incompatibility to be true, Ale.

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

On Thu, Mar 14, 2024 at 10:22 AM Scott Kitterman wrote: > > I think MUST do SPF or DKIM, SHOULD do SPF, to do SPF MUST do xxx, SHOULD > do > DKIM, to do DKIM MUST do yyy is reasonable (that's how I parsed your > proposed > changes, is that right?). I think it's an improvement and assuming I am

Re: [dmarc-ietf] picking nits with the ABNF

To summarize this thread, I see three nits, all of which have been added to issue 133: 1. Section 5.4, Formal Definition, reword the comments for dmarc-uri to be: ; "URI" is imported from [RFC3986]; ; commas (ASCII 0x2C) and exclamation ; points (ASCII 0x21)

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

On Thursday, March 14, 2024 10:09:37 AM EDT Todd Herr wrote: > Colleagues, > > After reviewing the "Another point SPF advice" thread and Murray's separate > post re: SHOULD vs. MUST, I have opened issue 132 on the topic: > > The current text of section 5.5.1, Publish and SPF Policy for an

Re: [dmarc-ietf] Fwd: [Errata Held for Document Update] RFC7489 (7835)

Issue 129 is already open to discuss all existing RFC 7489 Errata in DMARCbis On Mon, Mar 11, 2024 at 12:40 PM Eliot Lear wrote: > FYI > > Forwarded Message > Subject: [Errata Held for Document Update] RFC7489 (7835) > Date: Mon, 11 Mar 2024 09:34:11 -0700 (PDT) > From: RFC

Re: [dmarc-ietf] Appendix B.2.3. Per-Message Failure Reports Directed to Third Party

On Sun, Mar 10, 2024 at 8:56 AM Alessandro Vesely wrote: > Hi, > > it would be much more real-life to exemplify directing /aggregate/ > reports to third parties, which is quite common. Directing failure > reports to third parties would be a privacy nightmare. > > I'd suggest turning the

Re: [dmarc-ietf] Nit: Appendix B.1, examples parallelism and typo

These have been added to Issue 133 On Sun, Mar 10, 2024 at 8:29 AM Alessandro Vesely wrote: > Hi, > > first the typo. Example 3 in appendix B.1.2 uses sample.net (an > existing domain) instead of example.net: > > DKIM-Signature: v=1; ...; d=sample.net; ... > > Second, Example 2 is

Re: [dmarc-ietf] Section 9.5 DMARC Report Format Registry

Acknowledged that Issue 130 is open for this. On Sat, Mar 9, 2024 at 7:21 PM Tim Wicinski wrote: > > Re-reading section 9.5, I think we should rewrite this to mention the > registry being deprecated. > > I open an issue on this > > tim > > > On Fri, Mar 8, 2024 at 12:00 PM Tim Wicinski wrote:

Re: [dmarc-ietf] Nit: missing angle brackets

Issue 133 has been opened for this and subsequent nits. On Sat, Mar 9, 2024 at 5:33 AM Alessandro Vesely wrote: > Hi, > > this is section 11.4, Display Name Attacks. It has: > >From: "u...@example.org via Bug Tracker" supp...@example.com >(mailto:supp...@example.com) > > Should

[dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

Colleagues, After reviewing the "Another point SPF advice" thread and Murray's separate post re: SHOULD vs. MUST, I have opened issue 132 on the topic: The current text of section 5.5.1, Publish and SPF Policy for an Aligned Domain, reads: ==

Re: [dmarc-ietf] Problem with multiple policies, different alignment

Your latter questions were similar to Ale's - If the SPF/DKIM domain is a parent of the From domain, then we check its relationship to the organizational domain. If it is a parent of the organizational domain, the result is unaligned. If it is anywhere between the organizational domain and