[dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)
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"? -MSK -- Forwarded message - From: RFC Errata System Date: Mon, Nov 1, 2021 at 4:31 PM Subject: [Technical Errata Reported] RFC7489 (6729) 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/eid6729 -- Type: Technical Reported by: Scott Kitterman Section: 3.2 Original Text - 3. Search the public suffix list for the name that matches the largest number of labels found in the subject DNS domain. Let that number be "x". Corrected Text -- 3. Search the ICANN DOMAINS section of the public suffix list for the name that matches the largest number of labels found in the subject DNS domain. Let that number be "x". Notes - The PSL includes both public and private domains. RFC 7489 should have limited name matching to the public, ICANN DOMAINS section of the PSL. As an example, using the current PSL, the organizational domain for example.s3.dualstack.ap-northeast-1.amazonaws.com is example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com since it is listed in the private section of the PSL. This is clearly the wrong result. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can 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] Additions to introduction
On Fri, Dec 3, 2021 at 6:16 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > 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 actual impersonation. When a recipient intends to exempt a > high-value sender from content filtering, identity verification ensures > that such special treatment can be done safely, without concern for > impersonation.However, the same cannot be said about verification > failures. Verification failures can occur for many reasons, and many such > messages will be safe and desired by the recipient. Messages which do not > verify are optimally handled with manual review, but this may not be > feasible due to message volume.DMARC provides a way for senders and > receivers to safely cooperate to minimize the probability that automated > disposition decisions will be suboptimal. > I have no objection to adding text such as this. It's worth noting, though, that DKIM certainly says this already (at least in its Section 6.1), SPF probably says something similar, and DMARC clearly depends on those. DMARC alludes to this in RFC 7489, Section 10.5, but it's not as explicit as what's proposed here. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Additions to introduction
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 actual impersonation. When a recipient intends to exempt a high-value sender from content filtering, identity verification ensures that such special treatment can be done safely, without concern for impersonation.However, the same cannot be said about verification failures. Verification failures can occur for many reasons, and many such messages will be safe and desired by the recipient. Messages which do not verify are optimally handled with manual review, but this may not be feasible due to message volume.DMARC provides a way for senders and receivers to safely cooperate to minimize the probability that automated disposition decisions will be suboptimal. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5
It appears that Alessandro Vesely said: >Hi, > >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. Todd is right. We're deprecating the pct tag and adding a new t tag. No new version needed. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5
On Fri, Dec 3, 2021 at 12:40 PM Alessandro Vesely wrote: > Hi, > > 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. > I'm not sure I agree with your assertion here. I'm assuming you're referring to this paragraph: Note that given the rules of the previous paragraph, addition of a new tag into the registered list of tags does not itself require a new version of DMARC to be generated (with a corresponding change to the "v" tag's value), but a change to any existing tags does require a new version of DMARC. I contend that introducing 't' to replace 'pct' is not a change to an existing tag but rather an addition of a new tag. If you're contending that removing 'pct' is a change to 'pct', we can have that conversation, but I don't know that I'd agree with that contention either. There are other tags, namely 'rf' and 'ri', for which removal has been proposed and I've not heard anyone contend that either of those removals would constitute a change requiring a new version. > Given also that we discovered use cases that were not considered during > the > hasty discussion that resulted in the decision to change tags, cases where > pct=x with 0 < x < 100 is used as a press, gradually increasing x in order > to > urge various departments to comply, exactly as specified in DMARC1, I > appeal to > revert that decision. > > > 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: (plain-text integer between 0 and 100, inclusive; OPTIONAL; default is 100). Percentage of messages from the Domain Owner's mail stream to which the DMARC policy is to be applied. And I will go to my grave stating that DMARC policies cannot be applied to messages that pass DMARC authentication checks, and the definitions of 'quarantine' and 'reject' explicitly refer to messages that fail DMARC authentication checks. The sentence should read something like this: Percentage of messages using the Domain Owner's domain and failing DMARC authentication checks to which the DMARC policy is to be applied. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *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] dmarcbis-04, 5.3. General Record Format 3/5
Hi, we have: p: Domain Owner Assessment Policy (plain-text; RECOMMENDED for policy records). Indicates the message handling preference the Domain Owner or PSO has for mail using its domain but not passing DMARC verification. Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" or "np" tags. This tag is mandatory for policy records only, but not for third-party reporting records (see [DMARC-Aggregate-Reporting] and [DMARC-Failure-Reporting]) Possible values are as follows: RECOMMENDED and mandatory cannot coexist, and subdomain may publish their own policy. Alternative wording: p: Domain Owner Assessment Policy (plain-text; RECOMMENDED for policy records). Indicates the message handling preference the Domain Owner or PSO has for mail using its domain but not passing DMARC verification. Policy applies to the domain queried and to subdomains, unless a subdomain publishes its own policy or if subdomain policy is explicitly described using the "sp" or "np" tags. This tag is ignored for third-party reporting records (see [DMARC-Aggregate-Reporting] and [DMARC-Failure-Reporting]) Possible values are as follows: Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5
Hi, 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. Given also that we discovered use cases that were not considered during the hasty discussion that resulted in the decision to change tags, cases where pct=x with 0 < x < 100 is used as a press, gradually increasing x in order to urge various departments to comply, exactly as specified in DMARC1, I appeal to revert that decision. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] dmarcbis-04, 5.3. General Record Format 4/5
Hi, for psd: [...] This information will be used during policy discovery to determine how to apply any DMARC policy records that are discovered during the tree walk. It is not yet clear /how/ that information will be used. In general, what information do records found during the tree walk contribute? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] dmarcbis-04, 5.3. General Record Format 2/5
Hi. The np tag definition looks identical to that of rfc9091, except for the last sentence: Note that "np" will be ignored for DMARC records published on subdomains of Organizational Domains and PSDs due to the effect of the DMARC policy discovery mechanism described in Section 5.7.2.1. During a tree walk DMARC records at subdomain may be discovered if the subdomain name is short enough. Old DMARC filters using the PSL will still ignore it. This applies to "sp" definition as well. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] dmarcbis-04, 5.3. General Record Format 1/5
Hi, I have five issues on this section. 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 registry, are to be processed; unknown tags MUST be ignored. Couldn't it say something like so: Section 8 creates a registry for known DMARC tags and registers the initial set defined in this document. Only tags defined in that registry are to be processed. Unknown tags MUST be ignored. That way, fo, rua, and ruf definitions could be moved to the corresponding I-Ds. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] dmarcbis-04, 5. Policy
Hi, I don't understand the second paragraph: A Domain Owner or PSO may choose not to participate in DMARC evaluation by Mail Receivers simply by not publishing an appropriate DNS TXT record for its domain(s). A Domain Owner can also choose to not have some underlying authentication technologies apply to DMARC evaluation of its domain(s). In this case, the Domain Owner simply declines to advertise participation in those schemes. For example, if the results of path authorization checks ought not be considered as part of the overall DMARC result for a given Author Domain, then the Domain Owner does not publish an SPF policy record that can produce an SPF pass result. Trying to dissuade people from participating in SPF or DKIM authentication because they don't want DMARC does not convince me. How about the following: Often, a Domain Controller may choose to not participate in DMARC evaluation by Mail Receivers simply by not publishing an appropriate DNS TXT record for its domain(s). However, there are cases where its Public Suffix Operator (PSO) does publish a DMARC record, which would also involve domains below which don't publish a DMARC record. Although PSOs publishing such records presumably know what they're doing, a Domain Owner may still not want to participate. In that case, it can publish a DMARC record overriding policy and report dispositions. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] dmarcbis-04, 4.7.1. DKIM-Authenticated Identifiers
Hi, this paragraph is fine: To illustrate, in relaxed mode, if a verified DKIM signature successfully verifies with a "d=" domain of "example.com", and the RFC5322.From address is "ale...@news.example.com", the DKIM "d=" domain and the RFC5322.From domain are considered to be "in alignment", because both domains have the same Organizational Domain of "example.com". In strict mode, this test would fail because the d= domain does not exactly match the RFC5322.From domain. However, the following one is deceiving: However, a DKIM signature bearing a value of "d=com" would never allow an "in alignment" result, as "com" should be identified as a PSD and therefore cannot be an Organizational Domain. Should a PSL-free implementation walk the tree of the d= domain to determine the organizational domain of the signature? That's not necessary. I'd point out something like so: Note that, since the signature was verified and the public key retrieved, it is sufficient to verify that the signing domain is either the Organizational Domain or a subdomain of it. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] dmarcbis-04, 4.6. Determining the Organizational Domain
Hi, I looked up _dmarc.com and got no data, looked up _dmarc.gov.uk and got a DMARC record without a psd= tag. The spec says: Once such a record has been found, [...] That would be a goof place to say: If no labels remain and no record with a psd tag with a value of 'y' was found, the Organizational Domain can be determined using the procedure described in Appendix A6. Allowing to use the old procedure anyway would account for slow migration toward the tree walk, as psd=y tags become ubiquitous and credible. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] dmarcbis-04, 3.2.11. Report Receiver (nit)
Hi, could we stick to the term *Report Consumer*, please? The Producer/ Consumer terminology is used in Authentication-Results parlance. It is convenient because the term receiver is inevitably used without qualification in several sentences where it is clear from the context (to the writer) whether it is a mail receiver or a report receiver. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] dmarcbis-04 Abstract, domain controller?
Hi, the adoption of the PSD extension experiment brought some heavy-handed wording. On Thu 02/Dec/2021 21:54:56 +0100 internet-drafts wrote: Abstract: This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email author's domain name to enable verification of the domain's use, to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed verification, and to request reports about use of the domain name. Mail receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFC 7489. In the rest of the document, the phrase is shortened to "Domain Owner or PSO", which is less clumsy. Would it be useful to introduce the notion of Domain Controller? It is the entity which can publish records in the relevant zone. A Domain Owner is a Domain Controller which also manages a mail server. Using that term, I'd attempt a more readable version of the second paragraph of the Abstract like so: DMARC permits a Domain Controller to enable verification of the domain name usage for designating email authors, to indicate the Domain Controller's message handling preference regarding failed verification, and to request reports about such usage of the domain name. Mail receiving organizations can use this information when evaluating handling choices for incoming mail. Does it sound better? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
