Comments inline On Fri, Aug 30, 2024 at 11:29 AM Mark E. Mallett <[email protected]> wrote:
> > Pared down from a collection of notes that I mainly made for myself > while coding against stuff in the last several iterations of > dmarcbis. Mostly these are the trivial ones. > > ========== > 4.5 > > Similarly, a Mail Receiver (#mail-receiver) wishing to find the DMARC > Policy Record... > > This isn't really similar. It's more complementary -- publishing a > record vs looking one up. Remove "Similarly" and it makes more sense. > Changing "Similarly" to "and", i.e., For example, the Domain Owner of "example.com" would publish a DMARC Policy Record at the name "\_dmarc.example.com", and a [Mail Receiver](#mail-receiver) wishing to find the DMARC Policy Record > ========== > 4.5 > > a TXT record can comprise multiple "character-string" objects, each > with the same name. > > Not really "with the same name" -- they are in the same record attached > to the name. I think saying they have the same name is redundant. "each > being a component of the text" or something. > > Removing ", each with the same name" > ========== > 4.5 > > A Domain Owner can choose not to have some underlying authentication > mechanisms apply to DMARC evaluation of its Author Domain(s). For > example, if a Domain Owner only wants to use DKIM as the underlying > authentication mechanism, then the Domain Owner does not publish an > SPF record that can produce Identifier Alignment between an SPF- > Authenticated Identifier and the Author Domain. Alternatively, if > the Domain Owner wishes to rely solely on SPF, then it can send email > messages that have no DKIM-Signature header field that would produce > Identifier Alignment between a DKIM-Authenticated Identifier and the > Author Domain. > > No real problem, but mainly I find it interesting that here we have a > whole paragraph talking about this, but also A.2 talking about how there > is a lack of need for it. > I think A.2 says there is no need for a flag in the DMARC policy record that excludes SPF or DKIM from DMARC evaluation; this paragraph is a bit different than that, in that it describes how to exclude SPF or DKIM from DMARC evaluation simply by not participating in SPF or DKIM for that message. Regardless, it's probably better to get the same idea across in multiple places in the document, given what I believe to be the common behavior that folks will read/skim parts of the RFC vice read it from cover to cover. > ========== > 4.10.2 > > Says there's no need to do a Tree Walk if there is no DMARC policy found > for the Author Domain. How would you discover the policy that contains > e.g. a "sp" clause covering this author domain? I'm not saying there's > an error here, just that I don't get it. > I believe the text you're referring to here says "Note: There is no need to perform Tree Walk searches for Organizational Domains under any of the following conditions". This section is titled "Identifier Alignment Evaluation" and I will amend that phrase to read "Note: There is no need to perform Identifier Alignment Evaluations under any of the following conditions" > ========== > B.2.4 > > trivial: the example zonefile entry probably needs a space after > "example.net;" (before "t=y") > Will be done in rev -34. -- Todd Herr | Technical Director, Standards & Ecosystem Email: [email protected] Phone: 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 -- [email protected] To unsubscribe send an email to [email protected]
