Subject: [dmarc-ietf] text correction on DMARC spec re reporting DNS record

From: Franck Martin <[email-masked]>
Date: Wed, 25 Sep 2013 16:44:13 -0500 (CDT)

Section 7.1 Verifying External Destinations 

3rd paragraph from the end of the section. 

"The Domain Owner confirming via the DNS that it wishes to receive 
reports can use a wildcard DNS record to confirm that it is willing 
to receive reports for any domain. For example, a TXT resource 
record at "*._report._dmarc.example.com" containing at least 
"v=DMARC1" confirms that example.com is willing to receive DMARC 
reports for any child domain." 

Should be 

"The report receiver confirming via the DNS that it wishes to receive 
reports can use a wildcard DNS record to confirm that it is willing 
to receive reports for any domain. For example, a TXT resource 
record at "*._report._dmarc.example.com" containing at least 
"v=DMARC1" confirms that example.com is willing to receive DMARC 
reports for any domain."

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 26 Sep 2013 00:22:07 +0200

>  "v=DMARC1" confirms that example.com is willing to receive DMARC

Report receivers and domain owners are two different functions. And 
although both functions can be assigned to a single person, in general 
one cannot say (imho) that a report receiver is able to do something 
(confirm willingness to receive reports) in DNS.

What about:

"The Domain Owner of the domain of a Report Receiver who is willing
to receive reports for any domain, can use a wildcard DNS record. For
example, a TXT resource record at "*._report._dmarc.example.com"
containing at least "v=DMARC1" confirms that example.com is willing
to receive DMARC reports for any child domain."

And BTW: I do believe that 'child domain' here is not correct 
terminology: the wildcard indicates any domain on the Internet, which 
can have "rua" or "ruf" tags that points to this domain.

Example: domainA.com has rua tag that points to a receiver in 
domainC.com and domainB.com has also a rua tag that points to a receiver 
in domainC.com. Then it is possible to have:

domainA.com._report._dmarc.domainC.com
and
domainB.com._report._dmarc.domainC.com

but is is also possible to use the wildcard construct:

*._report._dmarc.domainC.com

But domainA.com and domainB.com are not child domains of domainC.com.

This makes me wonder: is the DMARC spec at dmarc.org the one that will 
need to be reviewed, or will a new version be presented (during Last 
Call?). And are comments like Franck's and mine already welcome, or do 
we have to wait until a new version will be released for an official 
round of review?

/rolf

---

From: Matt Simerson <[email-masked]>
Date: Wed, 25 Sep 2013 16:31:02 -0700

On Sep 25, 2013, at 3:22 PM, "Rolf E. Sonneveld" <[email-masked]> wrote:

> Report receivers and domain owners are two different functions. And although both functions can be assigned to a single person, in general one cannot say (imho) that a report receiver is able to do something (confirm willingness to receive reports) in DNS.

-1

> And BTW: I do believe that 'child domain' here is not correct terminology: the wildcard indicates any domain on the Internet, which can have "rua" or "ruf" tags that points to this domain.

+1

Agreed, the term 'child domain' is misleading to the point of being factually wrong. The asterisk will match any domain name, including a parent or even a tld.

Matt

---

From: Roland Turner <[email-masked]>
Date: Thu, 26 Sep 2013 09:39:32 +0800

>> Report receivers and domain owners are two different functions. And although both functions can be assigned to a single person, in general one cannot say (imho) that a report receiver is able to d…

Rolf, are you suggesting that the [already deployed, working] mechanism 
described in 7.1 whereby a putative report receiver can purportedly do 
that exact thing (confirm willingness to receive, via DNS) is 
unworkable? Something else?

> Agreed, the term 'child domain' is misleading to the point of being factually wrong. The asterisk will match any domain name, including a parent or even a tld.

Agreed, it looks as though the wildcard and "specific child" cases have 
been merged incorrectly.

- Roland

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 26 Sep 2013 10:15:24 +0200

Hi, Roland,

On 09/26/2013 03:39 AM, Roland Turner wrote:
>>> although both functions can be assigned to a single person, in 
>>> general one cannot say (imho) that a report receiver is able to do 
>>> something (confirm willingness to receive reports) in DNS.
>
> Rolf, are you suggesting that the [already deployed, working] 
> mechanism described in 7.1 whereby a putative report receiver can 
> purportedly do that exact thing (confirm willingness to receive, via 
> DNS) is unworkable? 

No.

> Something else?

The text I proposed is in the category 'minor improvements'. As "[...] 
The mission of the IETF is to produce high quality, relevant technical 
and engineering documents [...]" (RFC3935, BCP95) the proposed text is 
an attempt to differentiate between the various roles that exists in any 
medium to large organization.

All in all, when trying to come up with some text I realized that it 
would help when some 'domain' definitions would be added to the DMARC 
spec, to address the various sorts of domains there are in the context 
of DMARC. I'd suggest to move the currently present Domain definitions 
from the intro of chapter 3 to a separate paragraph ("3.1 Domain 
Definitions", for example) and add definitions for:

- Author Domain
- Submission Domain (see RFC5598, par 4.1.4, discussion on RFC5321.MailFrom)
- Receiver Domain
- Report Receiver Domain

and then use these names/definitions throughout the document.

I'd be happy to come up with some text, but maybe it's better to wait 
for the formal review phase?

/rolf