Re: [dmarc-ietf] Fwd: [Editorial Errata Reported] RFC7489 (7835)

[Murray S. Kucherawy]

On Wed, Mar 6, 2024 at 11:42 AM Todd Herr  wrote:

> The text reported in the erratum doesn't really exist in DMARCbis; it's
> been replaced by the DNS Tree Walk (
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html#name-dns-tree-walk
> )
>
> Are we to issue an actual update to RFC 7489 here as well?
>

No, but I think you need to (or should) list any errata against RFC 7489
that we consider this document to have resolved.  That would include this
one if the section has been rewritten or the issue is fully obsolete.

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

[dmarc-ietf] DMARCbis WGLC Issue - Clarify When Tree Walk Starts?

[Todd Herr]

Colleagues,

Murray's post on RFC 7489 errata got me thinking that some language
associated with the Tree Walk could stand a bit more clarity.

Section 4.7, DMARC Policy Discovery, starts with the following sentence:

For policy discovery, a DNS Tree Walk starts at the domain found in the
RFC5322.From header of the message being evaluated.

I think the above is muddy, especially given that step 2 of the Tree Walk
reads:

Records that do not start with a "v=" tag that identifies the current
version of DMARC are discarded. If multiple DMARC records are returned,
they are all discarded. If a single record remains and it contains a
"psd=n" tag, stop


When it comes to policy discovery, if the RFC5322.From domain has a
published policy record, it's the policy regardless of the value of the
'psd' tag, is it not? Step 2 of the Tree Walk would seem to indicate that
if such a record didn't have psd=n then the Tree Walk would continue for
policy discovery.

I believe that the first sentence in Section 4.7 should be replaced as
follows:

For policy discovery, first query for a DMARC policy record at the name
created by prepending the label "_dmarc" to the RFC5322.From domain. If no
valid DMARC policy record is found there, then perform a DNS Tree Walk
starting with the parent domain of the RFC5322.From domain.


I think Section 4.8 is okay, because a Tree Walk will always have to be
performed for Organizational Domain Discovery, but for Policy Discovery,
the Tree Walk is only necessary if there's no policy published specifically
for the RFC5322.From domain.

I've created Issue #128 for this.


-- 

*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] Fwd: [Editorial Errata Reported] RFC7489 (7835)

[Todd Herr]

On Wed, Mar 6, 2024 at 1:10 PM Murray S. Kucherawy 
wrote:

> Since we're in WGLC here, this erratum is worth consideration.  I've
> recommended "Held For Document Update" as the disposition.
>
> My reply to the erratum was:
>
> ===
>
> The algorithm as presented is correct, but I understand this report.
>
> The steps are, paraphrased:
>
> (1) Go get a set of things.
>
> (2) Filter them.
>
> (3) If the set is now empty, go get a set of things from a different
> location.
>
> (4) Filter them.
>
> [...]
>
> If the filter at step (2) doesn't leave an empty set, step (3) is a no-op,
> and running the same filter at step (4) is also a no-op.  If the filter at
> (2) does leave an empty set, go get other data at (3), and then run the
> same filter on them at (4).
>
> It's correct, but it could be more explicit about what's going on here.
>

The text reported in the erratum doesn't really exist in DMARCbis; it's
been replaced by the DNS Tree Walk (
https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html#name-dns-tree-walk
)

Are we to issue an actual update to RFC 7489 here as well?

-- 

*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

[dmarc-ietf] Fwd: [Editorial Errata Reported] RFC7489 (7835)

[Murray S. Kucherawy]

Since we're in WGLC here, this erratum is worth consideration.  I've
recommended "Held For Document Update" as the disposition.

My reply to the erratum was:

===

The algorithm as presented is correct, but I understand this report.

The steps are, paraphrased:

(1) Go get a set of things.

(2) Filter them.

(3) If the set is now empty, go get a set of things from a different
location.

(4) Filter them.

[...]

If the filter at step (2) doesn't leave an empty set, step (3) is a no-op,
and running the same filter at step (4) is also a no-op.  If the filter at
(2) does leave an empty set, go get other data at (3), and then run the
same filter on them at (4).

It's correct, but it could be more explicit about what's going on here.

===

-MSK


-- Forwarded message -
From: RFC Errata System 
Date: Mon, Mar 4, 2024 at 1:07 AM
Subject: [Editorial Errata Reported] RFC7489 (7835)
To: 
Cc: , , 


The following errata report has been submitted for RFC7489,
"Domain-based Message Authentication, Reporting, and Conformance (DMARC)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7835

--
Type: Editorial
Reported by: Giuseppe Trotta 

Section: 6.6.3

Original Text
-
   2.  Records that do not start with a "v=" tag that identifies the
   current version of DMARC are discarded.

   3.  If the set is now empty, the Mail Receiver MUST query the DNS for
   a DMARC TXT record at the DNS domain matching the Organizational
   Domain in place of the RFC5322.From domain in the message (if
   different).  This record can contain policy to be asserted for
   subdomains of the Organizational Domain.  A possibly empty set of
   records is returned.

   4.  Records that do not start with a "v=" tag that identifies the
   current version of DMARC are discarded.

Corrected Text
--
   2.  Records that do not start with a "v=" tag that identifies the
   current version of DMARC are discarded.

   3.  If the set is now empty, the Mail Receiver MUST query the DNS for
   a DMARC TXT record at the DNS domain matching the Organizational
   Domain in place of the RFC5322.From domain in the message (if
   different).  This record can contain policy to be asserted for
   subdomains of the Organizational Domain.  A possibly empty set of
   records is returned.

Notes
-
In section 6.6.3 the points 2 and 4 are duplicated.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
will log in to change the status and edit the report, if necessary.

--
RFC7489 (draft-kucherawy-dmarc-base-12)
--
Title   : Domain-based Message Authentication, Reporting, and
Conformance (DMARC)
Publication Date: March 2015
Author(s)   : M. Kucherawy, Ed., E. Zwicky, Ed.
Category: INFORMATIONAL
Source  : INDEPENDENT
Area: N/A
Stream  : INDEPENDENT
Verifying Party : ISE & Editorial Board
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC Issue - Section 11.3

[Todd Herr]

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

> Maybe better?:
>
> NEW
> If they can block outgoing or reply DNS messages, they can prevent
> systems from discovering senders' DMARC policies.  Recipients will
> then use their local policies for handling mail in the absence of
> DMARC and will not be able to take the senders' policies into account.
> END
>
> (Or just skip the second sentence and do it as you suggest)
>
> Barry
>
> On Thu, Feb 29, 2024 at 4:44 PM Todd Herr
>  wrote:
> >
> > Colleagues,
> >
> > The second bullet of section 11.3 DNS Security reads:
> > "If they can block outgoing or reply DNS messages, they can prevent
> systems from discovering senders' DMARC policies, causing recipients to
> assume p=none by default." This seems inconsistent with the text in 5.7.2
> ("Continue if one is found, or terminate DMARC evaluation otherwise") and
> 4.7 ("Handling of DNS errors when querying for the DMARC policy record is
> left to the discretion of the Mail Receiver") neither of which describe a
> scenario where "No DMARC record found means DMARC record exists with a
> policy of p=none" I believe the phrase "causing recipients to assume p=none
> by default" should be stricken from the bullet in 11.3.
> > Please discuss.
>
>
I made the original proposed change of just striking the phrase "causing
recipients to assume p=none by default" and recorded same in closed issue
#123


-- 

*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

[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] The description of psd=n

[Alessandro Vesely]

On 05/03/2024 21:47, Scott Kitterman wrote:

On March 5, 2024 8:10:46 PM UTC, Todd Herr 
 wrote:

On Tue, Mar 5, 2024 at 1:30 PM Scott Kitterman  wrote:

On March 5, 2024 2:47:47 PM UTC, Todd Herr 
 wrote:

On Tue, Mar 5, 2024 at 6:12 AM Alessandro Vesely  wrote:


Section 5.3, in the format description of psd:

n:  The DMARC policy record is published for a PSD, but it is the
   Organizational Domain for itself and its subdomain.  There is
   no need to put psd=n in a DMARC record, except in the very
   unusual case of a parent PSD publishing a DMARC record without
   the requisite psd=y tag.

Perhaps a "not" is missing between "is" and "published"?  I'd 
just say the domain is not a PSD /and/ it is the 
Organizational Domain for itself and its subdomain. >


You may be correct in your assertion here; I'll wait for others to weigh 

in.


In the meantime, Issue 126 has been opened to track this.



I think it's missing a not, but is overwise fine.


John Levine commented directly on issue 126
,
indicating that he believes the text should read (emphasis added by me):

   n:  The DMARC policy record is published for a PSD, but it is NOT the
  Organizational Domain for itself and its subdomain.  There is
  no need to put psd=n in a DMARC record, except in the very
  unusual case of a parent PSD publishing a DMARC record without
  the requisite psd=y tag.

I think this is the correct place to put the 'not', as it's consistent with 
the second sentence here, as well as this text from the following sections:



I thought psd=n means the domain is not a PSD.  Why would the text say 
the opposite?



4.8 Organizational Domain Discovery - "If a valid DMARC record contains the 
psd= tag set to 'n' (psd=n), this is the Organizational Domain, and the 
selection process is complete."



This says psd=n means the domain IS the org domain.


11.8 Determination of Organizational Domain for Relaxed Alignment -  "If a 
PSD domain publishes a DMARC record without the appropriate psd=y tag, 
organizational domain owners can add psd=n to their organizational domain's 
DMARC record so that the PSD record will not be incorrectly evaluated to be 
the organizational domain."



Ditto.

Besides, to say that a record is "published for" may sound as indicating 
who are the target readers of such publication.  Holding that a domain 
owner publishes psd=n in the hope that its PSO will read it and 
consequently amend its own record is not a valid interpretation of the 
text proposed above...


Shouldn't it be thus:

  n:  The domain is NOT a PSD, it is the Organizational Domain for
 itself and its subdomain.  There is no need to put psd=n in a
 DMARC record, except in the very unusual case of a parent PSD
 publishing a DMARC record without the requisite psd=y tag.

Best
Ale
--






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