[dmarc-ietf] Re: Discussion Thread for Issue 155
On Tue, Oct 22, 2024 at 11:38 PM Murray S. Kucherawy wrote: > On Mon, Oct 21, 2024 at 8:51 AM Todd Herr 40valimail@dmarc.ietf.org> wrote: > >> Issue is here - >> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/155 >> > > For the sake of trying to spark discussion: > > I think this might be the most important point that needs discussion > before we Last Call this document. The specific thing that concerns me is > that we're seeking Standards Track status for something that has well > documented interoperability problems, and -- conspicuously, in my view -- > this version of the DMARC specification doesn't improve on any of that > since RFC 7489, which was the tacit agreement between the IESG and the > working group. This should be explained. > > I believe it is related to, but not exactly the same as, the MUST NOT vs. > SHOULD NOT decision that was made not long ago regarding interoperability > advice. It's clear where consensus ended up, but I think the document > falls short of explaining to the reader why this WG is prepared to get > behind something that has these aspects to it, and that's something that > should be fixed before it advances. I think the reasoning is scattered in > that discussion thread and elsewhere in the archive, but someone should > probably take a shot at synthesizing it into a few sentences. > > So does anyone want to propose text to add that explains this? This could > go in the document itself (my preference, as that's going to be the most > obvious place to look for a rationale later), or if we prefer, it could be > added to the shepherd writeup. > > While I appreciate the IETF mantra of "rough consensus and running code", I think DMARC may perhaps be an outlier for the IETF, in that it's been in use for nigh on ten years without being formally codified by the IETF. Furthermore, as of a year ago, DMARC finds itself to be a required implementation for many Domain Owners in the email community, despite its interoperability issues. To that end, any text I might draft on this topic would lean toward "We wrote this to capture how things are being done" rather than "We wrote this to describe how to do things", but I don't know how such language might be received. So, two questions... 1. Does "We wrote this to capture how things are being done" capture the consensus of the working group? 2. If so, how would such language be received by those reviewing the document outside of this working group? -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Discussion Thread for Issue 157
Issue is here - https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/157 -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Discussion Thread for Issue 156
Issue is here - https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/156 -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Discussion Thread for Issue 155
Issue is here - https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/155 -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Fwd: New Version Notification for draft-ietf-dmarc-dmarcbis-34.txt
This version was published in response to Murray's AD Evaluation. The diff between this and rev -33 will be quite extensive, but much of the diff is due to punctuation changes from single quotes to double quotes. The AD Evaluation also resulted in the opening of three issues in GitHub: - Issue 155 <https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/155>, regarding the working group's perceived failure to fully address the problem with indirect mail flows - Issue 156 <https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/156>, regarding the Tree Walk and what to do if the first query of the Tree Walk returns a DMARC Policy record that includes a "psd=y" tag - Issue 157 <https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/157>, regarding clarifying language as to whether or not reports should be sent to addresses found in DMARC Policy Records that contain a "psd=y" tag I will start individual discussion threads for each of these issues, and humbly request that you follow the links to the issues and read what's written there before contributing to the thread. -- Forwarded message - From: Date: Mon, Oct 21, 2024 at 11:41 AM Subject: New Version Notification for draft-ietf-dmarc-dmarcbis-34.txt To: Todd M. Herr , John Levine < standa...@standore.com> A new version of Internet-Draft draft-ietf-dmarc-dmarcbis-34.txt has been successfully submitted by Todd M. Herr and posted to the IETF repository. Name: draft-ietf-dmarc-dmarcbis Revision: 34 Title:Domain-based Message Authentication, Reporting, and Conformance (DMARC) Date: 2024-10-21 Group:dmarc Pages:79 URL: https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-34.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ HTML: https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-34.html HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-dmarcbis-34 Abstract: This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email's Author Domain (#author-domain) to enable validation of the domain's use, to indicate the Domain Owner's (#domain-owner) or Public Suffix Operator's (#public-suffix- operator) message handling preference regarding failed validation, and to request reports about the use of the domain name. Mail receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFCs 7489 and 9091. The IETF Secretariat -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: AD Evaluation for draft-ietf-dmarc-dmarcbis-33
ecause (give reasons here). This could go here or in its own > section (definitely not in an appendix). RFC 6377 is available as a > reference to describe some of the disruption. Just as with the principle > behind Security Considerations sections, I think it's more important to > highlight that we know there are problems, but believe this is worth > publishing at Proposed Standard anyway. > > Same section: We're saying receivers MUST NOT reject based solely on the > DMARC result. I feel like we're pushing the interoperability problem onto > receivers here. What advice do we have for them around how to go about > doing this? What properties of a message should they be looking at to head > off this problem? Is anyone successfully doing this today? > > In several spots in Section 8, the text talks about creating a registry, > but the registry already exists. For each, we should instead say that RFC > 7489 created the registry, but all existing references to that document > should now point here. > > Section 10.4 talks about display name attacks, and I wonder if we have any > (even vague) figures that compare the display name problem to the direct > domain attack problem. If we think this is going to take out a small > portion of the problem, or if we think the display name attack will grow as > a result, we should probably say so. > > The second paragraph of Section 10.8 took me several times to read and > parse. Maybe an example would help. Same sort of remark about the fourth. > > Section 10.8 also talks about "periodically checking the DMARC Policy > Records, if any, of PSDs" but doesn't talk about how one might achieve > knowledge of where they are. Is this just caching of the ones you've > discovered? > > In Appendix A.1, S/MIME is RFC 8551. > > In Appendix A.3, DomainKeys is RFC 4870. > > Appendix A.6, third paragraph, third sentence, total parse failure. > > Appendix C.1, a correction: RFC 7489 has no IETF category or status at > all. It's an informational RFC that was not a product of the IETF. In > fact the only IETF review it got was the IESG confirming that it doesn't > conflict with any work in the IETF already in progress. > > -MSK > ___ > dmarc mailing list -- dmarc@ietf.org > To unsubscribe send an email to dmarc-le...@ietf.org > -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: DMARCbis version -33 is ready for document shepherd and AD processing
My current working copy of the document has these two paragraphs: As discussed in "Interoperability Issues between DMARC and Indirect Email Flows" [@!RFC7960], use of p=reject can be incompatible with and cause interoperability problems to indirect message flows such as "alumni forwarders", role-based email aliases, and mailing lists across the Internet. As an example of this, a bank might send only targeted messages to account holders. Those account holders might have given their bank addresses such as jo...@alumni.example.edu (an address that relays the messages to another address with a real mailbox) or finance@association.example (a role-based address that does similar relaying for the current head of finance at the association). When such mail is delivered to the actual recipient mailbox, it will most likely fail SPF checks unless the RFC5321.MailFrom address is rewritten by the relaying MTA, as the incoming IP address will be that of example.edu or association.example, and not an IP address authorized the originating RFC5321.MailFrom domain. DKIM signatures will generally remain valid in these relay situations. and I believe that the referenced RFC (RFC 7960) does a pretty good job of describing why forwarding might cause issues with DMARC and SPF here: If the RFC5321 <https://datatracker.ietf.org/doc/html/rfc5321>.MailFrom is present and the forwarder maintains the original RFC5321 <https://datatracker.ietf.org/doc/html/rfc5321>.MailFrom, SPF validation will fail unless the forwarder is an authorized part of the originator's email sending infrastructure. If the forwarder replaces the RFC5321 <https://datatracker.ietf.org/doc/html/rfc5321>.MailFrom with its own domain, SPF might pass, but Identifier Alignment with the RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From header field will fail. https://datatracker.ietf.org/doc/html/rfc7960#section-2.2 so can we please just call this good and move on? On Fri, Sep 13, 2024 at 12:07 PM Tero Kivinen wrote: > Alessandro Vesely writes: > > I googled a bit on that but didn't find a satisfactory analysis. There > are > > several good files, e.g. http://www.open-spf.org/whitepaper.pdf or > > > https://www.maawg.org/sites/maawg/files/news/MAAWG_Email_Forwarding_BP.pdf > . > > M3AAWG is just now in process of updating that Email forwarding best > practice. There should be new version published in few months. > -- > kivi...@iki.fi > > ___ > dmarc mailing list -- dmarc@ietf.org > To unsubscribe send an email to dmarc-le...@ietf.org > -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Review of the dmarc draft documents
Suggested changes from https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/pull/154, save for one suggestion to change "its" to "it", have been incorporated into branch rev-34, which was committed to github today. The pull request was closed, as the new branch also incorporates a few updates from other on-list threads. This was noted in the comments closing the pull request. On Thu, Sep 5, 2024 at 11:02 AM Daniel K. wrote: > On 7/30/24 22:31, John R. Levine wrote: > > If you're willing to futz with the markdown, pull requests with proposed > > changes would be great. > > I've worked through the dmarcbis and failure reporting drafts and here's > the result. > > https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/pull/154 > > https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/pull/5 > > > I propose to remove the Examples from failure reporting in its entirety > and expanding with a new example in dmarcbis. That way dmarcbis can > focus on all aspects of configuration and give all examples, while the > companion drafts can focus on specification and implementation details > of aggregate and failure reports. > > > I collected a few questions along the way, and I'll follow up with those > as soon as I've sorted them out in my head and are able to ask them in a > comprehensible way. > > > Here's a rundown of the remaining points from my initial email. > > > On Mon, 29 Jul 2024, Daniel K. wrote: > >> 4) This warning text is sometimes shown even if > > Handled earlier. > > > >> 5) Overlap in the examples of dmarcbis and failure-reporting > > Will be resolved if both pull requests are accepted. > > > >> 6) Inconsistent requirements for validating third party report > consumers. > > I propose to change this to a MUST in the above dmarcbis pull-request. > > > >> 7) Formal definition > >> > >> "Keyword" is no longer referenced, and the note about it being imported > >> from RFC 5321 can be dropped. > > I've included a commit to remove it. > > > >> 8) The txt versions are hard to read > >> > >> Due to: (#identifiers) interspersed throughout the text > > This is an artifact of the txt output format, as far as I can tell. > Maybe there's an option to turn it off, but I have not looked for it. > > > Daniel K. > > ___ > dmarc mailing list -- dmarc@ietf.org > To unsubscribe send an email to dmarc-le...@ietf.org > -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: minor draft-ietf-dmarc-dmarcbis-32 comments
Comments inline On Fri, Aug 30, 2024 at 11:29 AM Mark E. Mallett 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: todd.h...@valimail.com 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: DMARCbis version -33 is ready for document shepherd and AD processing
Getting back on the horse after time away...
I propose the following text to address Eliot's concerns (and I include the
preceding paragraph as context):
As discussed in "Interoperability Issues between DMARC and Indirect
Email Flows" [@!RFC7960], use of p=reject can be incompatible with and
cause interoperability problems to indirect message flows such as
"alumni forwarders", role-based email aliases, and mailing lists
across the Internet.
As an example of this, a bank might send only targeted messages to
account holders. Those account holders might have given their bank
addresses such as jo...@alumni.example.edu (an address that relays
the messages to another address with a real mailbox) or
finance@association.example (a role-based address that does similar
relaying for the current head of finance at the association). When
such mail is delivered to the actual recipient mailbox, it will
necessarily fail SPF checks, as the incoming IP address will be that
of example.edu or association.example, and not an address authorized
for the sending domain. DKIM signatures will generally remain valid
in these relay situations.
On Tue, Aug 27, 2024 at 5:54 AM Eliot Lear wrote:
> Hi Barry,
>
> I just noticed something editorial in nature in the following paragraph in
> Section 7.5:
>
> A domain that expects to send only targeted messages to account holders -
> a bank, for example - could have account holders using addresses such as
> jo...@alumni.example.edu (an address that relays the messages to another
> address with a real mailbox) or finance@association.example (a role-based
> address that does similar relaying for the current head of finance at the
> association). When such mail is delivered to the actual recipient
> mailbox...
>
> That first sentence is long and difficult to parse; and domains don't have
> expectations. I suggest the following alternative in line with existing
> practice and intent:
>
> Some senders use email addresses from domains that are not associated with
> a particular SMTP server. For example, Robin Jones might send messages as
> jo...@alumni.example.edu when in reality that person's mail flows through
> some other bigmailserver.example.com. Another example would be someone
> who sends from a role-based address such as
> headhon...@standards-organization.example.org. When such mail is
> delivered to the actual recipient mailbox...
>
> {yes, I changed the examples. Change them back if you like}
>
> This is intended strictly (so to speak) as a friendly amendment. If
> anyone has concerns, I've seen worse writing (from myself, I might add),
> and we should just move on.
>
> Eliot
> On 08.08.2024 20:58, Barry Leiba wrote:
>
> I've asked the document shepherd (Tim Wicinski, and thanks for
> volunteering to handle this!) to do his final review and get the
> writeup done, and I've alerted Murray that it's coming soon. I hope
> those next steps will happen very soon.
>
> Barry, as chair
>
> ___
> dmarc mailing list -- dmarc@ietf.org
> To unsubscribe send an email to dmarc-le...@ietf.org
>
> ___
> dmarc mailing list -- dmarc@ietf.org
> To unsubscribe send an email to dmarc-le...@ietf.org
>
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
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 -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-17.txt and "domain holders"
Greetings. The current version of the aggregate reporting document contains a variant of the phrase "domain holders" in five locations. This term does not appear in DMARCbis, but the term "Domain Owner" does, and I think the aggregate reporting document should use the term "Domain Owner" in lieu of "domain holder(s)". https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-33.html#name-domain-owner -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: I-D Action: draft-ietf-dmarc-dmarcbis-32.txt
With this release, there are currently no open issues for DMARCbis in github, as I believe they have all been addressed. I of course welcome discussion on that topic. On Tue, Jun 25, 2024 at 10:14 AM wrote: > Internet-Draft draft-ietf-dmarc-dmarcbis-32.txt is now available. It is a > work > item of the Domain-based Message Authentication, Reporting & Conformance > (DMARC) WG of the IETF. > >Title: Domain-based Message Authentication, Reporting, and > Conformance (DMARC) >Authors: Todd M. Herr > John Levine >Name:draft-ietf-dmarc-dmarcbis-32.txt >Pages: 76 >Dates: 2024-06-25 > > Abstract: > >This document describes the Domain-based Message Authentication, >Reporting, and Conformance (DMARC) protocol. > >DMARC permits the owner of an email's Author Domain (#author-domain) >to enable validation of the domain's use, to indicate the Domain >Owner's (#domain-owner) or Public Suffix Operator's (#public-suffix- >operator) message handling preference regarding failed validation, >and to request reports about the use of the domain name. Mail >receiving organizations can use this information when evaluating >handling choices for incoming mail. > >This document obsoletes RFCs 7489 and 9091. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-32.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-dmarcbis-32 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > I-D-Announce mailing list -- i-d-annou...@ietf.org > To unsubscribe send an email to i-d-announce-le...@ietf.org > -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Issue 133 and the 'fo' Tag
On Fri, Jun 21, 2024 at 10:06 AM Alessandro Vesely wrote: > On Thu 20/Jun/2024 18:24:30 +0200 Todd Herr wrote: > > Second question... > > > > Both RFC 7489 and DMARCbis describe the 'd' and 's' values as requesting > the > > generation of a DKIM failure report (RFC 6651) or SPF failure report > (RFC > > 6652). Is that what we want, or should it be a report in the format > defined > > in draft-ietf-dmarc-failure-reporting? > > > I think RFC 7489's usage of the terms DKIM and SPF in that context is a > typo. > It meant to say, e.g., "Generate a DMARK failure report with DKIM > characteristics if..." rather than "Generate a DKIM failure report > if...". In > fact, Section 7.3.1 extends AFRF in two flavors, dkim and spf. They both > have > type "dmarc". > I'm not sure that I agree with your assertion here. I'd be more inclined to think you correct if the text in 7489 didn't explicitly reference RFCs 6651 and 6652: d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment. DKIM- specific reporting is described in [AFRF-DKIM <https://datatracker.ietf.org/doc/html/rfc7489#ref-AFRF-DKIM>]. s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment. SPF-specific reporting is described in [AFRF-SPF <https://datatracker.ietf.org/doc/html/rfc7489#ref-AFRF-SPF>]. If it was an error on the part of the authors of 7489 to describe 'd' and 's' in this way, it's on a scale that's much larger than just a typo. > The last paragraph in that section explicitly says: > > > 3. Authentication Failure Type "dmarc" is defined, which is to be > used when a failure report is generated because some or all of > the authentication mechanisms failed to produce aligned > identifiers. [...] > > https://datatracker.ietf.org/doc/html/rfc7489#section-7.3.1 > > That seems to say that fo= is meant to identify under what conditions a > "dmarc" > failure report is generated, not what Type of failure report is generated. > > Best > Ale > -- > > > ___ > dmarc mailing list -- dmarc@ietf.org > To unsubscribe send an email to dmarc-le...@ietf.org > -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Issue 133 and the 'fo' Tag
Colleagues, In revisiting https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/133 there seems to be some disagreement about the values for the 'fo' tag, specifically the definitions of the 'd' and 's' values for this tag. DMARCbis rev -31's text has a slightly different description of the 'fo' tag than does RFC 7489, but the four values shown for 'fo' have identical text across the two documents. Questions: In describing the 'fo' tag, RFC 7489 includes this sentence: "The value of this tag is a colon-separated list of characters that indicate failure reporting options as follows:" Meanwhile, DMARCbis currently says: "The value of this tag is either "0", "1", or a colon-separated list of the options represented by alphabetic characters." So RFC 7489 allows for something like "fo=0:d:s" while DMARCbis allows only "fo=0", "fo=1", OR "fo=d", "fo=s", or "fo=d:s" What is the consensus of the group here? Second question... Both RFC 7489 and DMARCbis describe the 'd' and 's' values as requesting the generation of a DKIM failure report (RFC 6651) or SPF failure report (RFC 6652). Is that what we want, or should it be a report in the format defined in draft-ietf-dmarc-failure-reporting? Thanks. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Inconsistent Organizational Domain definition
On Wed, Jun 5, 2024 at 11:33 AM Alessandro Vesely wrote: > Hi all, > > there is an inconsistency in the org domain definition. The beginning of > the > algorithm states: > > For each Tree Walk that retrieved valid DMARC Policy Records, select > the Organizational Domain from the domains for which valid DMARC > Policy Records were retrieved from the longest to the shortest: > > That sentence implies that a record was found for the org domain. > However, > step 2 says: > > 2. If a valid DMARC Policy Record, other than the one for the domain > where the tree walk started, contains the psd= tag set to 'y' > (psd=y), the Organizational Domain is the domain one label below > this one in the DNS hierarchy, and the selection process is > complete. > > The domain one label below PSD doesn't necessarily have a DMARC record, > though. > > We can either relax the requirement that the org domain has a record, or > define > the org domain to be the longest record below the PSD /having a record/. > I'd > opt for the latter disjunct. > > For example, consider a global bank having From: identifiers such as > ny.us.glob.bank, paris.fr.glob.bank and the like. _dmarc.bank has psd=y. > What > if glob.bank publishes no record while both us.glob.bank and fr.glob.bank > do? > Shall the policy be that of the PSD? Are the two From: IDs above aligned? > > My interpretation of the text as currently written is that there does not have to be a DMARC policy record published at glob.bank in order for it to be the Organizational Domain in this scenario. The text says "the Organizational Domain is the domain one label below [the domain where the psd=y tag was found] in the DNS hierarchy" Whether or not it is our collective intent for a domain with no explicit DMARC policy record to be an Organizational Domain in this scenario is a discussion I'll invite now. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: I-D Action: draft-ietf-dmarc-dmarcbis-31.txt
Colleagues,
My efforts in producing this rev focused on incorporating many of the
comments from WGLC. Some of those comments were in regards to lack of
clarity in language, section ordering, and the like, and the comments
weren't wrong.
I've made a concerted effort to go through the entire document from front
to back and ensure a consistency of usage of terminology, so that every
time $THING was discussed, the same term was used for it. One prime example
of this was my replacing all references to RFC5322.From domain with Author
Domain, since Author Domain is a defined term in the document ("The domain
name of the apparent author as extracted from the RFC5322.From Header
field.") and its usage flows better when reading (in my opinion) than does
"RFC5322.From domain".
I also took great pains to try to ensure that the first usage of a defined
term in a given section was then linked back to the term's definition, so
there's now lots of, sticking with our example, "[Author
Domain](#author-domain)" in the markdown version of the document. I may
have missed a few places to do this, and this may have been massive
overkill on my part, but I was inspired by Mr. Fenton's WGLC comments (
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/142).
The upshot here is that rev -31 is both significantly different from rev
-30 and not that different at all, in my opinion. The text is certainly
different, and the ordering of some sections has changed, but the contents
are not all that different (save for this rev having N=8 for the Tree Walk,
vice 5 in the previous version and one or two other bits).
Have at it.
On Mon, May 20, 2024 at 2:46 PM wrote:
> Internet-Draft draft-ietf-dmarc-dmarcbis-31.txt is now available. It is a
> work
> item of the Domain-based Message Authentication, Reporting & Conformance
> (DMARC) WG of the IETF.
>
>Title: Domain-based Message Authentication, Reporting, and
> Conformance (DMARC)
>Authors: Todd M. Herr
> John Levine
>Name:draft-ietf-dmarc-dmarcbis-31.txt
>Pages: 76
>Dates: 2024-05-20
>
> Abstract:
>
>This document describes the Domain-based Message Authentication,
>Reporting, and Conformance (DMARC) protocol.
>
>DMARC permits the owner of an email's Author Domain (#author-domain)
>to enable validation of the domain's use, to indicate the Domain
>Owner's (#domain-owner) or Public Suffix Operator's (#public-suffix-
>operator) message handling preference regarding failed validation,
>and to request reports about the use of the domain name. Mail
>receiving organizations can use this information when evaluating
>handling choices for incoming mail.
>
>This document obsoletes RFCs 7489 and 9091.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-31.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-dmarcbis-31
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> I-D-Announce mailing list -- i-d-annou...@ietf.org
> To unsubscribe send an email to i-d-announce-le...@ietf.org
>
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
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 -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org
Re: [dmarc-ietf] Intent To Produce DMARCbis rev -31 - Request for Discussion Pause
On Mon, Apr 22, 2024 at 10:01 AM Todd Herr wrote: > Colleagues, > > I intend to produce the next draft of DMARCbis this week, incorporating as > best as I can all the parallel threads that have spun up since WGLC was > called. > > In order for me to be most effective in this task, I humbly request that > we hit pause on discussion until the revision is published, as the editing > process suffers when the target keeps moving. > > Thank you for your consideration in this matter. > > Colleagues, There won't be a new revision published this week, as the editors are still working on it. We'll keep you posted on progress. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Intent To Produce DMARCbis rev -31 - Request for Discussion Pause
Colleagues, I intend to produce the next draft of DMARCbis this week, incorporating as best as I can all the parallel threads that have spun up since WGLC was called. In order for me to be most effective in this task, I humbly request that we hit pause on discussion until the revision is published, as the editing process suffers when the target keeps moving. Thank you for your consideration in this matter. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Wed, Apr 17, 2024 at 1:06 AM Scott Kitterman wrote: > > I am confused. > > Under the current (7489) rules a record for _dmarc.c.d.e.f.tld won't be > found > either in this case. Why do we need to support something that is > currently > unsupported? > > We picked n=5 to allow the current org level record to be detected by the > tree > walk. It's true that the tree walk provides some additional flexibility > for > subordinate organizations within what we would call a DMARC org domain > based > on RFC 7489, but that was by no means anything we ever described as a > feature > or a goal. > I don't share your understanding here. I interpret some of the text of https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/79, "Do away with the PSL and Org Domain entirely; just walk the tree" to at least imply that the tree walk was designed to provide this flexibility, to wit: When DMARC was first developed, there was concern about DNS load and needing to minimize DNS lookups. Operational expertise now shows that this is no longer cause for concern. Short circuiting a tree walk has led to many issues, like a reliance on the PSL, complicated algorithms for Org Domain discovery, many types of domains (PSDs, per https://tools.ietf.org/wg/dmarc/draft-ietf-dmarc-psd/) being unable to utilize DMARC even though they wish to, and larger organizations (such as universities and governments) that are comprised of sub-organizations that use subdomains having material problems getting everything authenticated. All these issues disappear, and DMARC becomes a lot simpler conceptually, if DMARC simply walks the DNS hierarchy for the exact sending domain down to the TLD until it finds a DMARC record, and stops. It's the second paragraph, specifically the "and larger organizations..." bits to which I'm referring here. > Even if some organizations have very deep DNS trees, the fact that some > entity > uses a.b.c.d.e.f.tld doesn't affect DMARC. The record for the top level > of > their organization will still be found. > > In any case, any domain, at any depth in the tree can publish their own > DMARC > record if they need some special thing. The value of N does not affect > that at > all. > > Fair enough. You're correct that a DMARC policy can be published for any specific domain used as the RFC5322.From domain, so perhaps a bit of text in the Tree Walk section describing the really deep use case and the solution for it might be a compromise. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk
On Wed, Apr 17, 2024 at 1:18 AM Neil Anuskiewicz wrote:
>
>
> On Apr 16, 2024, at 2:18 PM, Todd Herr 40valimail@dmarc.ietf.org> wrote:
>
>
> Colleagues,
>
> DMARCbis currently describes the value of 'n' for the 'psd' tag in a
> policy record as follows:
>
> 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 don't think this is entirely accurate, especially the second sentence
> ("no need ... except in the very unusual case"), and here's why. Either
> that, or the description of the Tree Walk needs to be changed.
>
> The Tree Walk is intended for both DMARC Policy discovery and
> Organizational Domain discovery, and section 4.7 (DMARC Policy Discovery)
> says the policy to be applied will be the DMARC record found at one of
> these three locations:
>
>- The RFC5322.From domain
>- The Organizational Domain of the RFC5322.From domain
>- The Public Suffix Domain of the RFC5322.From domain
>
> Meanwhile, section 4.8, Organizational Domain Discovery, gives the
> following three options for where the Organizational Domain is:
>
>1. DMARC record with psd=n
>2. The domain one level below the domain with a DMARC record with the
>tag psd=y
>3. The record for the domain with the fewest number of labels.
>
> The Tree Walk, as described in section 4.6, defines two explicit places to
> stop, both of which rely on discovery of a DMARC policy record with a psd
> tag defined.
>
>
> One of your concerns is that without a PSD tag, but I think the default is
> PSD=n. Does,that address that concern or did I misunderstand the concern?
>
>
The default for the psd tag is 'u', not 'n'.
See
https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html#name-general-record-format
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk
Colleagues,
DMARCbis currently describes the value of 'n' for the 'psd' tag in a policy
record as follows:
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 don't think this is entirely accurate, especially the second sentence
("no need ... except in the very unusual case"), and here's why. Either
that, or the description of the Tree Walk needs to be changed.
The Tree Walk is intended for both DMARC Policy discovery and
Organizational Domain discovery, and section 4.7 (DMARC Policy Discovery)
says the policy to be applied will be the DMARC record found at one of
these three locations:
- The RFC5322.From domain
- The Organizational Domain of the RFC5322.From domain
- The Public Suffix Domain of the RFC5322.From domain
Meanwhile, section 4.8, Organizational Domain Discovery, gives the
following three options for where the Organizational Domain is:
1. DMARC record with psd=n
2. The domain one level below the domain with a DMARC record with the
tag psd=y
3. The record for the domain with the fewest number of labels.
The Tree Walk, as described in section 4.6, defines two explicit places to
stop, both of which rely on discovery of a DMARC policy record with a psd
tag defined:
- Step 2, if the DMARC record has psd=n
- Step 7, if the DMARC record has psd=n or psd=y
There is no other stopping place described, and no instructions to collect
DMARC policy records that don't have the psd tag defined during the walk,
and while Organizational Domain Discovery speaks of records retrieved
during the Tree Walk, there are no instructions in the Tree Walk steps
themselves in section 4.6 to put all the DMARC records with no psd tag in a
basket somewhere for later usage.
So the questions I have are...
1. Should the description of the 'n' value for the 'psd' tag be updated
to discuss its usage in a decentralized control model (e.g., seven label
RFC5322.From with DMARC policy published at a five label name to allow for
"local" control, with said policy being different from the policy published
at the "traditional" org domain leve)?
2. Should the description of the Tree Walk in section 4.6 be updated, to
mention that valid DMARC records with no explicit psd tag might be found
during the walk, and these should be preserved for later comparison to
determine the organizational domain?
I look forward to the discussion.
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Mon, Apr 15, 2024 at 8:08 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Todd, can you clarify this? > > N is not concerned with maximum labels on a subdomain. We are interested > in the maximum length of an org domain used for relaxed alignment. > > If this client wants to use level 7 as an org domain and apply relaxed > alignment for 8-label domains, then N needs to be 7. If the client's > lowest-desired org domain is at or above 4-labels, then N=4 is sufficient. > Similarly, if the7-label domain only needs strict authentication, then N=7 > is not needed. > > Has this or another client genuinely chafed at the insufficient > granularity of the old PSL? > My understanding of the Tree Walk is that in DMARCbis it is the defined method for performing two separate jobs: - Discover the controlling DMARC policy record for the RFC5322.From domain in a given email message; this controlling DMARC policy will be found at either the RFC5322.From domain, the organizational domain for the RFC5322.From domain, or the PSD of the RFC5322.From domain. - Determine the organizational domains for the SPF domain,and the DKIM domain in a given email message, in order to determine whether the domains are in relaxed alignment with the RFC5322.From domain As I wrote in an earlier message, we have data showing use of seven label domains in the RFC5322.From domains; it's not a lot of data, but it's there. So, in my current scenario with an RFC5322.From domain of a.b.c.d.e.f.tld, DMARC Policy Discovery would be done by querying for these five (5) records: - _dmarc.a.b.c.d.e.f.tld - _dmarc.d.e.f.tld - _dmarc.e.f.tld - _dmarc.f.tld - _dmarc.tld Let's imagine that the Domain Owner for f.tld publishes this DMARC record: - v=DMARC1; p=none; psd=n; rua=mailto:f...@f.tld; but they allow for distributed, rather than central, administrative control, and therefore those who manage c.d.e.f.tld publish a DMARC record like this: - v=DMARC1; p=reject; psd=n; rua=mailto:f...@c.d.e.f.tld; Perfectly valid configurations as DMARCbis is currently written. The plausibility of same is unknown, but because RFC 7489 didn't contemplate organizational domains as anything other than domains one level below the domains on the PSL, it's not likely anyone ever tried to publish a DMARC record at c.d.e.f.tld. If we leave N at 5, the organizational domain and thus the intended DMARC policy for a.b.c.d.e.f.tld won't be discovered, as it's published at _dmarc.c.d.e.f.tld and that query will be skipped by the Tree Walk. My argument therefore for N=8 is to support distributed policy settings for RFC5322.From domains with eight or more labels and therefore organizational domains with seven or fewer labels, with 8 chosen to allow for one more label than has been currently observed. I will post a separate thread about the meaning and usage of the 'n' value for the 'psd' tag, because regardless of where we land on N for the tree walk, I think the description of the value of 'n' for the 'psd' tag is inadequate, a conclusion I've arrived at during the writing of this reply. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Mon, Apr 15, 2024 at 7:58 AM Scott Kitterman wrote: > > > On April 15, 2024 11:43:08 AM UTC, Alessandro Vesely > wrote: > >On Mon 15/Apr/2024 13:16:50 +0200 Douglas Foster wrote: > >> Our original choice of N was based on the PSL.The PSL could not > detect organizational boundaries could not boundaries below level 5, > because it had no entries longer than 5 labels, and we determined that the > 5-label entries were not used for mail.Therefore, any increase in N is > new capability. That new capability is probably desirable, but need not > be limitless. Using an N of 8 introduces a lot of new capability. > > > > > >8 is not needed and not justified. A mail site using 8 labels would have > troubles with the RFC 7489 version, which uses the PSL. They'd have to ask > for PSL upgrades, right? > > > >Now, we can relax our ambition to be PSL-free and state N=max number of > labels of public suffixes used by mail. Or we could put N in an IANA > registry that can be updated by expert review. Such methods allow to have > N low enough, yet upgradable and equal for all (compliant) implementations. > > > >Otherwise we can drop the requirement that N be equal for all > implementations, and just make it configurable. After all, it is an > anti-abuse measure, akin to SPF lookup limit. We can also keep it fixed at > 5 and be sure that implementations will differ anyway. > > > Whatever we decide, I think it needs to be specified. If N is whatever, > you will end up with difficult to troubleshoot interoperability issues when > various sites pick different values. > > I don't think we need to worry about revising it later. In general, DNS > is getting wider (new TLDs), not deeper. > > An inspection of data collected by my employer reveals the longest observed RFC5322.From address to include seven labels in the domain part. I am not at liberty to reveal the specific domains due to customer privacy, but they're there. For a domain with seven labels, a.b.c.d.e.f.g, the Tree Walk as currently described would miss any DMARC policy records published at b.c.d.e.f.g and c.d.e.f.g. I would propose the following first draft of expository text regarding setting N at 8: The point of the Tree Walk is to allow for the publishing and discovery of DMARC policy records at any level in the DNS hierarchy that strikes a balance between what the domain registrant deems reasonable and what operational needs deem reasonable. The setting of N is done with an eye to putting a thumb on the scale on the side of operational needs, to guard against the truly silly or abusive cases with domain names with label counts in the dozens or even triple digits. Based on an observation at the time of publishing that RFC5322.From domains with seven labels were in active but uncommon use, eight was chosen as the value of N in order to not only accommodate for current usage but also to allow for a bit of future expansion of the depth of the name space used for RFC5322.From domains. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis
Greetings. Issue 144 has been opened for the question of what to say about ARC (RFC 8617) in the context of indirect mail flows, a la Murray's example text from this post <https://mailarchive.ietf.org/arch/msg/dmarc/v5NMVIZqvRuEfopf7gc0Q1i4Ywo/>: "One possible mitigation to problem X is [ARC], which provides for a mechanism to demonstrate 'chain-of-custody' of a message. However, use of ARC is nascent, as is industry experience with it in connection with DMARC." https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/144 -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARCbis WGLC - Issue 143 Blank's "Contentious Issues"
Greetings. Issue 143 has been created from Seth Blank's post kicking off the thread <https://mailarchive.ietf.org/arch/msg/dmarc/mSP2yYek6F7HmUmLE-3Y0hQtVe0/> "WGLC contentious topics (I'm in the rough and I know it) in draft-ietf-dmarc-dmarcbis-30" https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/143 -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARCbis WGLC - Issue 142 - Fenton Review of DMARCbis rev-30
Greetings. Jim Fenton's message kicking off the thread <https://mailarchive.ietf.org/arch/msg/dmarc/zwZtb3w4mD87OcFaOh_nCyREBPM/> "WGLC review of draft-ietf-dmarc-dmarcbis-30" has been captured as Issue 142 - https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/142 -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all
Greetings. Issue 141 has been opened to collect ideas around the discussion about what to say in DMARCbis (if anything) about honoring SPF records that end in -all when SPF fails. https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/141 -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARCbis WGLC - Issue 140 Blank Editorial Review
Greetings, Seth Blank's initial post to the thread <https://mailarchive.ietf.org/arch/msg/dmarc/p9Ll1zkx-wn2LEZ5zoQDoVyDQoE/> "WGLC editorial review of draft-ietf-dmarc-dmarcbis-30" has been collected into Issue 140 - https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/140 -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30
On Mon, Apr 1, 2024 at 12:53 PM Jim Fenton wrote: > On 1 Apr 2024, at 9:26, Todd Herr wrote: > > > I'm digesting the threads for the purpose of preparing tickets to track > the > > work, and I suspect one of the tickets will include, "Add reference to > the > > following two M3AAWG documents": > > > >1. > > > https://www.m3aawg.org/sites/default/files/m3aawg_managing-spf_records-2017-08.pdf > >2. > > > https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf > > These are useful documents. > > The second one seems to be saying that the recommended action for > intermediaries is to use ARC, and doesn’t mention address rewriting. I have > some concerns about whether enough receivers interpret ARC header fields > for that to be viable, but that seems to be a better solution than address > rewriting. To echo Murray’s comment, should DMARC-bis reference ARC? > > The second document also recommends that receivers "Make use of ARC headers", but I do not believe that ARC header consumption is yet widespread enough to consider that recommendation to be commonly implemented. I myself am not a receiver, but I've been in enough conversations on the topic, including a present M3AAWG initiative, to understand the the long poles in that tent don't involve consumption of the headers per se, but rather knowing or deciding which ARC signers to trust and what to do when the message passes through multiple intermediaries and not all of them ARC sign the message. Should DMARC-bis reference ARC? I don't know; can it? What I mean by that is that some of us have an interest in DMARC-bis being published as Standards track, and ARC is Experimental, and I don't fully understand the rules regarding down-referencing (is that the right term?). -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30
On Mon, Apr 1, 2024 at 12:17 PM Tim Wicinski wrote: > I have to agree with Seth's comments that "security teams believe an SPF > hard fail is more secure". > I've been on the receiving end of that discussion more than once. > > Also, can we reference those two M3AAWG documents ? That seems like > operational guidance. > > I'm digesting the threads for the purpose of preparing tickets to track the work, and I suspect one of the tickets will include, "Add reference to the following two M3AAWG documents": 1. https://www.m3aawg.org/sites/default/files/m3aawg_managing-spf_records-2017-08.pdf 2. https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC result for DKIM testing and policy
On Thu, Mar 21, 2024 at 10:15 AM Todd Herr wrote: > On Thu, Mar 21, 2024 at 5:55 AM Alessandro Vesely wrote: > >> On Wed 20/Mar/2024 23:11:20 +0100 Matthäus Wander wrote: >> > Alessandro Vesely wrote on 2024-03-20 15:42: >> >> what is the result of DMARC on having, say >> >> >> >> dkim=pass (testing key) >> >> or >> >> dkim=policy (512 byte key) >> >> >> >> is that akin to SPF neutral, i.e. dmarc=fail? >> > >> > dkim=pass results in dmarc=pass (if the domain is aligned). The comment >> in >> > brackets is for human eyes and does not change the DMARC result. >> >> >> For t=y, DKIM says: >> >>y This domain is testing DKIM. Verifiers MUST NOT treat messages >> from Signers in testing mode differently from unsigned email, >> even should the signature fail to verify. Verifiers MAY wish >> to track testing mode results to assist the Signer. >> >> So reporting dkim=pass for testing keys seems to be a violation. >> >> >> > dkim=policy is like spf=neutral, i.e. dmarc=fail. >> >> >> Agreed. Should that be mentioned in DMARCbis? >> >> > I don't believe there's any need to discuss this topic in DMARCbis. > > DMARCbis, in section 4.1, DMARC Basics, says: > > === > > A message satisfies the DMARC checks if at least one of the supported > authentication mechanisms:¶ <#m_-6134626636375030691_section-4.1-3> > >1. > >produces a "pass" result, and ><#m_-6134626636375030691_section-4.1-4.1.1> >2. > >produces that result based on an identifier that is in alignment, as >described in Section 4.4 ><#m_-6134626636375030691_identifier-alignment-explained>. > > === > > If there's anything to say about reporting a DKIM pass result for DKIM > signatures where t=y exists and its possible ramifications for DMARC, then > I believe that's something for an update RFC 6376 to address. > > And upon further reflection I personally think two more things: 1. It is highly unlikely that a Domain Owner will publish a DMARC policy record with DKIM t=y in place when they can accomplish the same results with a DMARC policy of p=none and get aggregate and perhaps failure reporting to boot. 2. That part of 6376 might be better written as "Should the signature fail to verify, verifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email." as I see no reason to penalize a Domain Owner who successfully DKIM signs messages, even in testing mode. But I could very well be in the weeds here... -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC result for DKIM testing and policy
On Thu, Mar 21, 2024 at 5:55 AM Alessandro Vesely wrote: > On Wed 20/Mar/2024 23:11:20 +0100 Matthäus Wander wrote: > > Alessandro Vesely wrote on 2024-03-20 15:42: > >> what is the result of DMARC on having, say > >> > >> dkim=pass (testing key) > >> or > >> dkim=policy (512 byte key) > >> > >> is that akin to SPF neutral, i.e. dmarc=fail? > > > > dkim=pass results in dmarc=pass (if the domain is aligned). The comment > in > > brackets is for human eyes and does not change the DMARC result. > > > For t=y, DKIM says: > >y This domain is testing DKIM. Verifiers MUST NOT treat messages > from Signers in testing mode differently from unsigned email, > even should the signature fail to verify. Verifiers MAY wish > to track testing mode results to assist the Signer. > > So reporting dkim=pass for testing keys seems to be a violation. > > > > dkim=policy is like spf=neutral, i.e. dmarc=fail. > > > Agreed. Should that be mentioned in DMARCbis? > > I don't believe there's any need to discuss this topic in DMARCbis. DMARCbis, in section 4.1, DMARC Basics, says: === A message satisfies the DMARC checks if at least one of the supported authentication mechanisms:¶ <#section-4.1-3> 1. produces a "pass" result, and <#section-4.1-4.1.1> 2. produces that result based on an identifier that is in alignment, as described in Section 4.4 <#identifier-alignment-explained>. === If there's anything to say about reporting a DKIM pass result for DKIM signatures where t=y exists and its possible ramifications for DMARC, then I believe that's something for an update RFC 6376 to address. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] General Purpose Domain
Issue 137 has been opened for this. On Mon, Mar 18, 2024 at 9:50 AM Todd Herr wrote: > On Sun, Mar 17, 2024 at 7:17 AM Alessandro Vesely wrote: > >> On Sat 16/Mar/2024 21:07:53 +0100 Neil Anuskiewicz wrote: >> > Unless I’m misunderstanding, a General Purpose Domain is a separate >> domain or at least subdomain: >> >> >> Doesn't have to be a subdomain. It is a domain which has human mail >> users. >> >> > The term "General Purpose Domain" or any variant thereof does not appear > in DMARCbis. > > There is one appearance of the term "general-purpose" at the end of > Section 7.6: > > In particular, this document makes explicit that domains for > general-purpose email SHOULD NOT deploy a DMARC policy of p=reject. > > I propose that rather than twist ourselves into knots trying to define > "general-purpose" or "General Purpose Domain" that we instead add text to > the above-quoted sentence that says "See section 8.6 (Interoperability > Considerations) for further discussion of this topic." and be done with it. > > -- > > Todd Herr | Technical Director, Standards & Ecosystem > Email: todd.h...@valimail.com > 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. > -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC Issue - Section 11.5
Issue 138 has been opened for this. On Sat, Mar 16, 2024 at 5:35 PM Scott Kitterman wrote: > Not sure if this is "significant" or not. > > I don't particularly like the title, but that's been that way for quite > some > time, so for WGLC, meh. > > The particular concern I have is with the text that was added right before > WGLC about multi-valued RFC5322.From fields. It includes the statement: > > > Such an approach might prove useful for a small number of Author > > Domains, but it is likely that applying such logic to messages with a > larger > > number of domains (as defined by each Mail Receiver) will expose the > > Mail Receiver to a form of denial of service attack, and so applying a > > negative disposition decision to the message may be the best course of > > action. > > In particular, the word "likely" seems a bit much. Additionally, I think > beyond the Domain Owner DMARC policy published in a DMARC record, I think > discussions about message disposition are outside the scope of this > document. > How about this instead: > > > Such an approach might prove useful for a small number of Author > > Domains, but it is possible that applying such logic to messages with a > > large number of domains (as defined by each Mail Receiver) will expose > the > > Mail Receiver to a form of denial of service attack. Limiting the > number of > > Author Domains processed will avoid this risk. If not all Author Domains > > are processed, then the DMARC evaluation is incomplete. > > I don't think we need to tell people what to do with such messages. I > think > this is enough. > > Scott K > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] General Purpose Domain
On Sun, Mar 17, 2024 at 7:17 AM Alessandro Vesely wrote: > On Sat 16/Mar/2024 21:07:53 +0100 Neil Anuskiewicz wrote: > > Unless I’m misunderstanding, a General Purpose Domain is a separate > domain or at least subdomain: > > > Doesn't have to be a subdomain. It is a domain which has human mail users. > > The term "General Purpose Domain" or any variant thereof does not appear in DMARCbis. There is one appearance of the term "general-purpose" at the end of Section 7.6: In particular, this document makes explicit that domains for general-purpose email SHOULD NOT deploy a DMARC policy of p=reject. I propose that rather than twist ourselves into knots trying to define "general-purpose" or "General Purpose Domain" that we instead add text to the above-quoted sentence that says "See section 8.6 (Interoperability Considerations) for further discussion of this topic." and be done with it. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC exceptions
On Fri, Mar 15, 2024 at 1:47 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > 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 appropriate scope and characteristics of local policy. > > > I disagree with your premise, and I submit that it is not the role of the IETF, DMARCbis, or any third party to determine either characteristics or appropriate scope for a policy that is local to a Mail Receiver. A Mail Receiver's goal is to make sure that its mailbox holders receive wanted mail while minimizing the amount of unwanted mail that's accepted, and how they work to achieve that goal is solely their purview. DMARC authentication results can and probably do inform their work, but they're just one piece of data for doing so. Their work will also be informed by many other data points, some of which we know (historical mailbox holder engagement with a given mail stream) and some of which we don't know, and they adjust their handling decisions all the time based on whatever signals they deem important. I believe that this paragraph in the Introduction section of DMARCbis concisely describes DMARC to Mail Receivers: A DMARC pass indicates only that the RFC5322.From domain has been authenticated for that message. Authentication does not carry an explicit or implicit value assertion about that message or about the Domain Owner. Furthermore, a mail-receiving organization that performs DMARC verification can choose to honor the Domain Owner's requested message handling for authentication failures, but it is not required to do so; it might choose different actions entirely. I further believe that the description of the 'p' tag and of its possible values of 'none', 'quarantine', and 'reject' in section 5.3, General Record Format, are enough to help the Mail Receiver understand how reliable the Domain Owner believes its authentication practices to be and, along with everything else the Mail Receiver knows about the sending domain, the source of the mail stream, etc., etc., how much weight can be assigned to a failed DMARC authentication result for that domain. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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 > 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 aligns with the Author Domain, and then publish an SPF policy in DNS >> for that domain. The SPF record MUST be constructed at a minimum to ensure >> an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom >> domain. >> >> >> A major consideration, Todd, is receivers will process SPF for SPF >> without DMARC (payload) considerations. IOW, if SPF is a hardfail, we have >> SMTP processors who will not continue to transmit a payload (DATA). >> >> DMARCBis is making a major design presumption receivers will only use SPF >> as a data point for a final DMARC evaluation where a potentially high >> overhead payload was transmitted only to be rejected anyway, >> > > I don't necessarily think your assertion is true here, or at least I'd > submit that DMARCbis and RFC 7489 aren't approaching this subject any > differently. > > Section 10.1 from RFC 7489, titled "Issues Specific to SPF" had two > paragraphs, the second of which reads: > >Some receiver architectures might implement SPF in advance of any >DMARC operations. This means that a "-" prefix on a sender's SPF >mechanism, such as "-all", could cause that rejection to go into >effect early in handling, causing message rejection before any DMARC >processing takes place. Operators choosing to use "-all" should be >aware of this. > > > Yes, I agree. I am only reminding the community SPF can preempt DMARC > with a restrictive hardfail policy. Does DMARCBis integrate the tag to > delay SPF failures? > Perhaps some additional cautionary text for Mail Receivers, either added to the above paragraph or just after it, warning against rejecting solely due to SPF -all unless the SPF record is simply "v=spf1 -all"? Such text would be consistent, for example, with M3AAWG's Email Authentication Best Practices <https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf> document. > > > DMARCbis contains the same two paragraphs with no change to the text, > other than the section is now numbered 8.1. > > >> In the ticket, I propose the following new text: >> >> == >> To configure DKIM for DMARC, the Domain Owner MUST choose a DKIM-Signing >> domain (i.e., the d= domain in the DKIM-Signature header) that aligns with >> the Author Domain. >> == >> >> >> In order to maximize security, the Domain Owner is REQUIRED to choose a >> ….. >> >> Is REQUIRED the same as MUST? I think SHOULD or MUST is fine as long as >> we specify the reason it is required, >> > > I'm not understanding the comment you're making here, as I don't see the > word "REQUIRED" in anything I wrote. > > > For any protocol, there are “Protocol Requirements,” A MUST or SHOULD is > a “Requirement” for proper support, So I just wanted to just note that it > can stated another way. Developers need a Requirements Section that allow > us to code the logic, > > Its getting pretty confusing for implementors. > > > I'm sorry but I'm still not understanding the source of your confusion here. The text we're discussing is pulled from the Domain Owners section, and while it's not explicitly stated, "choosing a DKIM-signing domain" would essentially involve indicating to the sending platform what domain the Domain Owner wants to use in DKIM signing and then publishing a public key in DNS. It is presumed that the sending platform has already built into it the ability to DKIM sign messages based on the Domain Owner's choices. What logic must be coded to support this? -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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: >> >>> >>> 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 a reason. >>> >>> >> The reasons given were: >> >>1. https://www.rfc-editor.org/rfc/rfc5863#section-4.1 >>2. https://datatracker.ietf.org/doc/html/rfc6376#section-7.5 >>3. Neither RFC 7489 nor DMARCbis contain the phrase "CNAME", so if >>it's not explicitly mentioned... >> >> Granted, the first two citations are in regards to DKIM records, not >> DMARC records, but those were the reasons given. >> >> Couldn't hurt to clarify explicitly, I'm for it. Domain owners have been >> using CNAMEs with DMARC TXT RRs pretty much since its inception. >> > I agree that clarifying it can't hurt, obviously, but I was quite > surprised to hear that CNAMEs were being published for DMARC records, as > I'd never seen one. On the other hand, I've seen *lots* of DKIM public keys > published as CNAMEs, which I'm sure just wrecks the person citing DKIM RFCs > as a reason that DMARC records can't be CNAMEs. > > > Domain owner use cases with DMARC CNAMEs boils down to really either of 2 > things: > >- Single point of policy management for orgs with dozens, hundreds, or >thousands of domains to manage DMARC on, and also applicable to RUA/RUF >addresses. >- Delegation to a third-party for management, similar to DKIM CNAMEs >as you noted that are popularly in use by many ESPs for vendor-managed key >rotation. > > Yup, I grok the use cases. I just hadn't thought of them prior to this discussion. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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 theory was that led people to think otherwise? >> >> Seems to me we don't really need this, but maybe there's a reason. >> >> > The reasons given were: > >1. https://www.rfc-editor.org/rfc/rfc5863#section-4.1 >2. https://datatracker.ietf.org/doc/html/rfc6376#section-7.5 >3. Neither RFC 7489 nor DMARCbis contain the phrase "CNAME", so if >it's not explicitly mentioned... > > Granted, the first two citations are in regards to DKIM records, not DMARC > records, but those were the reasons given. > > Couldn't hurt to clarify explicitly, I'm for it. Domain owners have been > using CNAMEs with DMARC TXT RRs pretty much since its inception. > I agree that clarifying it can't hurt, obviously, but I was quite surprised to hear that CNAMEs were being published for DMARC records, as I'd never seen one. On the other hand, I've seen *lots* of DKIM public keys published as CNAMEs, which I'm sure just wrecks the person citing DKIM RFCs as a reason that DMARC records can't be CNAMEs. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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 a reason. > > The reasons given were: 1. https://www.rfc-editor.org/rfc/rfc5863#section-4.1 2. https://datatracker.ietf.org/doc/html/rfc6376#section-7.5 3. Neither RFC 7489 nor DMARCbis contain the phrase "CNAME", so if it's not explicitly mentioned... Granted, the first two citations are in regards to DKIM records, not DMARC records, but those were the reasons given. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[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 ;" Section 3.6.2 of RFC 1034 seems to indicate that it is permissible to publish DMARC records in this fashion, and describes the following scenario using an CNAME record and an A record: For example, suppose a name server was processing a query with for USC- ISIC.ARPA, asking for type A information, and had the following resource records: USC-ISIC.ARPA IN CNAME C.ISI.EDU C.ISI.EDU IN A 10.0.0.52 Both of these RRs would be returned in the response to the type A query, while a type CNAME or * query should return just the CNAME. I recommend adding a paragraph to DMARCbis, section 5.1 DMARC Policy Record at the end of that section that reads: Per RFC 1034 section 3.6.2, a DMARC record MAY be published as a CNAME record, so long as the corresponding canonical name ultimately resolves to a TXT record so as to ensure that queries of type TXT return a DNS RR in the expected format. Issue 136 has been opened for this. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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 aligns with the Author Domain, and then publish an SPF policy in DNS > for that domain. The SPF record MUST be constructed at a minimum to ensure > an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom > domain. > > > A major consideration, Todd, is receivers will process SPF for SPF without > DMARC (payload) considerations. IOW, if SPF is a hardfail, we have SMTP > processors who will not continue to transmit a payload (DATA). > > DMARCBis is making a major design presumption receivers will only use SPF > as a data point for a final DMARC evaluation where a potentially high > overhead payload was transmitted only to be rejected anyway, > I don't necessarily think your assertion is true here, or at least I'd submit that DMARCbis and RFC 7489 aren't approaching this subject any differently. Section 10.1 from RFC 7489, titled "Issues Specific to SPF" had two paragraphs, the second of which reads: Some receiver architectures might implement SPF in advance of any DMARC operations. This means that a "-" prefix on a sender's SPF mechanism, such as "-all", could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place. Operators choosing to use "-all" should be aware of this. DMARCbis contains the same two paragraphs with no change to the text, other than the section is now numbered 8.1. > In the ticket, I propose the following new text: > > == > To configure DKIM for DMARC, the Domain Owner MUST choose a DKIM-Signing > domain (i.e., the d= domain in the DKIM-Signature header) that aligns with > the Author Domain. > == > > > In order to maximize security, the Domain Owner is REQUIRED to choose a > ….. > > Is REQUIRED the same as MUST? I think SHOULD or MUST is fine as long as > we specify the reason it is required, > I'm not understanding the comment you're making here, as I don't see the word "REQUIRED" in anything I wrote. If one wants to configure DKIM for DMARC, one MUST choose a DKIM signing domain that aligns with the Author Domain, mustn't one? Saying SHOULD choose an aligned DKIM domain means that the Domain Owner can choose not to choose an aligned DKIM domain, and that won't be configuring DKIM for DMARC. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[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 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] 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 the > > 'd' and 's' values for the 'fo' tag. They currently begin with > > "Generate a DKIM failure report"/"Generate an SPF failure report", > > respectively, and both should instead begin with "Generate a DMARC > > failure report". > > > I'm glad that's a nit. I feared it was meant. > > Honestly I'm no longer sure what's correct here. The text I'm proposing a change to first appeared in RFC 7489, and both value descriptions linked out to AFRF format RFCs for DKIM and SPF, respectively (6651 and 6652). Both of those RFCs speak of separate reporting addresses for the failure-specific reports. I now think this merits further discussion. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[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 for this matter, and in that issue I floated the possibility of moving A.5 to section 7, Changes from RFC 7489, with some text along the lines of "we deleted the discussion of ADSP from this version, but it's preserved here for historical purposes" Discuss... -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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. DMARCbis, like RFC 7489 before it, contains this sentence in the description of DMARC records: Unknown tags MUST be ignored. Any site implementing the DMARCbis spec will see "pct" as an unknown and ignore it. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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 > reading it correctly, I support the change. > That is the gist of the text I've proposed, yes. [rest snipped for further discussion when issue is opened and reported to list] -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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) MUST be
; encoded
2. Section 5.4, update the ABNF for dmarc-value to be "%x20-3A /
%x3C-7E" (there is currently a vertical bar/pipe where the forward
slash should be)
3. Section 5.3., General Record Format, update the description of the
'd' and 's' values for the 'fo' tag. They currently begin with
"Generate a DKIM failure report"/"Generate an SPF failure report",
respectively, and both should instead begin with "Generate a DMARC
failure report".
Please confirm/discuss further.
On Mon, Mar 11, 2024 at 10:17 PM Neil Anuskiewicz wrote:
>
>
> On Mar 9, 2024, at 7:33 PM, OLIVIER HUREAU <
> olivier.hur...@univ-grenoble-alpes.fr> wrote:
>
>
> >> dmarc-version = "v" equals %s"DMARC1
> > I believe the "%s" should be dropped
>
> 'DMARC1' is case-sensitive in 7489.
> Either we keep the "%s" or we go back to 7489 version : "%x44 %x4d %x41
> %x52 %x43 %x31"
>
> > I think it should be %x20-3A / %x3C-7E
> Agreed.
>
> I would also add comment about the dmarc-fo ABNF :
>
> dmarc-fo = "0" / "1" / "d" / "s" / "d:s" / "s:d"
>
> The FO paragraph (
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html#name-general-record-format)
> explicitly states that there exist 3 kinds of failure reports :
> - DMARC failure report.
> - DKIM failure report.
> - SPF failure report.
>
> However, with the current ABNF, we could only ask for "DMARC failure
> report" or ("DKIM failure report" and/or "SPF failure report")
>
> Shouldn't we have an ANBF rule with all the possible permutations or a
> more generic one such as :
>
> dmarc-fo = dmarc-fo-value *(":" dmarc-fo-value)
> dmarc-fo-value = "0" / "1" / "d" / "s"
>
>
>
> Olivier
>
> --
> *De: *"Tim Wicinski"
> *À: *"IETF DMARC WG"
> *Envoyé: *Dimanche 10 Mars 2024 01:00:33
> *Objet: *[dmarc-ietf] picking nits with the ABNF
>
> Just picking over the ABNF with my checks, some Qs
>
>
> dmarc-version = "v" equals %s"DMARC1
>
>
> I believe the "%s" should be dropped
>
> dmarc-value = %x20-3A | %x3C-7E
>
>
> I think it should be %x20-3A / %x3C-7E
>
> and now just something suggested. The comments for URI read like this
>
> ; "URI" is imported from [RFC3986]; commas
> ; (ASCII 0x2C) and exclamation points
> ; (ASCII 0x21) MUST be encoded
>
> Could they be rewritten for readability
>
> ; "URI" is imported from [RFC3986];
> ; (ASCII 0x2C) commas and
> ; (ASCII 0x21) exclamation points
> ; MUST be encoded
>
> gladly tell me i'm too obsessive
>
>
>
> Yes, since most people are used to the FO tag but would happily embrace
> this upgrade.
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
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 Errata System > > To: giuse...@ohpe.it, superu...@gmail.com, zwi...@yahoo-inc.com > CC: rfc-...@rfc-editor.org, rfc-...@rfc-editor.org, > rfc-edi...@rfc-editor.org > > The following errata report has been held for document update 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 > > -- > Status: Held for Document Update > Type: Technical > > Reported by: Giuseppe Trotta > Date Reported: 2024-03-04 > Held by: Eliot Lear (ISE & Editorial Board) > > 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 > - > The intent of the original text is that indeed step 2 should be repeated > as follows: > (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. > > At the time of this writing, draft-ietf-dmarc-dmarcbis is being developed, > and so that text may clarify this point. As such we will hold this erratum > for update. > > -- > 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 > -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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 subsection from ruf= to rua=. Indeed, the spec > for Verifying External Destinations is Section 3 of the > aggregate-reporting I-D. Perhaps the whole B.2.3 should be moved there > as well. > > There are a number of vendors acting as third-party DMARC report consumers for both aggregate and failure reports, though, so I submit that it is "real-life" to exemplify directing failure reports to third parties. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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 labelled "parent" in both SPF and DKIM subsections. > However, for SPF the identifier is a child of the From: domain, while > for DKIM the From: domain is a child of the identifier. > > I'd either label "child" the DKIM example or parallelize the roles of > the identifiers. > > > Best > Ale > -- > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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: > >> >> Generally they will leave it and mark Obsolete. This should be called >> out in the RFC. >> (I have not looked right now). >> >> tim >> >> >> On Fri, Mar 8, 2024 at 11:42 AM Murray S. Kucherawy >> wrote: >> >>> On Fri, Mar 8, 2024 at 6:49 AM Alessandro Vesely wrote: >>> >>>> since we removed the rf= tag (format of failure reports), do we still >>>> need to tackle the IANA registry? Since we only use one format, it >>>> makes little sense. However, the registry actually exists. Is it >>>> possible to delete or obsolete it, or does it have to stay there as a >>>> relict for ever? >>>> >>> >>> I'm guessing it's possible for us to direct IANA to destroy a registry, >>> or (more likely) leave a tombstone page in its place. I'll ask. >>> >>> -MSK >>> ___ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >> ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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 be: > >From: "u...@example.org via Bug Tracker" >(mailto:supp...@example.com) > > Or even > >From: " via Bug Tracker" >(mailto:supp...@example.com) > > > Best > Ale > -- > > > > > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[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: == Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376]], in order to take full advantage of DMARC, a Domain Owner SHOULD first ensure that SPF and DKIM authentication are properly configured. As a first step, the Domain Owner SHOULD choose a domain to use as the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail, one that aligns with the Author Domain, and then publish an SPF policy in DNS for that domain. The SPF record SHOULD be constructed at a minimum to ensure an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom domain` == 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 ensure that either SPF or DKIM authentication are properly configured, and SHOULD ensure that both are. 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 aligns with the Author Domain, and then publish an SPF policy in DNS for that domain. The SPF record MUST be constructed at a minimum to ensure an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom domain. == In addition, the last paragraph in section 5.5.2, Configure Sending System for DKIM Signing Using an Aligned Domain, reads: == The Domain Owner SHOULD choose a DKIM-Signing domain (i.e., the d= domain in the DKIM-Signature header) that aligns with the Author Domain. == In the ticket, I propose the following new text: == To configure DKIM for DMARC, the Domain Owner MUST choose a DKIM-Signing domain (i.e., the d= domain in the DKIM-Signature header) that aligns with the Author Domain. == Further notes on the threads that gave rise to this ticket: - I do not believe that recommending the use of the ? modifier in an SPF record configured for DMARC is appropriate, since as I understand the ? modifier, the result produced is not "pass", but rather "neutral", which is the same as "none". Therefore, an SPF record using ? would not produce an aligned pass to be used with DMARC. I am willing to be convinced that I'm wrong here. - That said, I think there is room for discussion of too-permissive SPF records and the cross-user forgery discussed in RFC 7208 Section 11.4, and I will open a separate issue for that to expand on section 8.1 -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Problem with multiple policies, different alignment
On Wed, Mar 13, 2024 at 6:24 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > My unsuccessful attempt to implement to the specification has reminded me > of my past concerns. > > Our document gives primacy to the Tree Walk, as if it will be used on > every From domain, SPF domain, and DKIM domain. The Tree Walk algorithm > is explained in detail before any discussion of how it is used, and the > differences between the From walk and the SPF/DKIM walks have been > ignored. I find that this makes the document harder to follow and less > usable. > > The reality is that the Tree Walk is an inefficient and unreliable way of > obtaining an answer, particularly because of the risk of DNS timeouts. As > a result, the Tree Walk should be avoided whenever possible. In fact, the > secondary tree walks for SPF and DKIM can frequently be avoided: > >- When strict alignment is required. >- When the SPF/DKIM domain is not verified. >- When the SPF/DKIM domain matches the From domain. >- When the SPF/DKIM domain is a parent of the From domain. >- When a string comparison shows that the SPF/DKIM domain is not a >child of the organizational domain > > For many messages, these optimizations will mean that no secondary tree > walk will be needed at all. In the event that multiple secondary tree > walks are required, additional efficiencies can be gained by prioritizing > which signature domain is walked first. > > The Tree Walk is an important tool for deprecating the PSL. But the > oversimplification of its discussion has prevented any substantive > consideration of either the differences between the two types of Tree Walk > or the available optimizations to avoid performance problems. > Section 4.8 in DMARCbis includes this text: == Note: There is no need to perform Tree Walk searches for Organizational Domains under any of the following conditions:¶ <#section-4.8-3> - The RFC5322.From domain and the RFC5321.MailFrom domain (if SPF authenticated), and/or the DKIM d= domain (if present and authenticated) are all the same, and that domain has a DMARC record. In this case, this common domain is treated as the Organizational Domain. - No applicable DMARC policy is discovered for the RFC5322.From domain during the Tree Walk for that domain. In this case, the DMARC mechanism does not apply to the message in question. - The record for the RFC5322.From domain indicates strict alignment. In this case, a simple string comparison of the RFC5322.From domain and the RFC5321.MailFrom domain (if SPF authenticated), and/or the DKIM d= domain (if present and authenticated) is all that is required. == Does that text not at least address the first three bullets you've included here? As for your other bullets.. - "When the SPF/DKIM domain is a parent of the From domain." - I'm not sure this is a valid exception in all cases. Consider the domain dept.school.college.edu, which publishes a DMARC policy and has an organizational domain of school.college.edu. The domain college.edu is a parent of that domain, but school.college.edu (an organizational domain) and college.edu do not have the same organizational domain. On the other hand, if college.edu is the organizational domain, then the SPF/DKIM domain will align with the From domain. - "When a string comparison shows that the SPF/DKIM domain is not a child of the organizational domain" - An SPF/DKIM domain does not have to be the child of an organizational domain in order to have the same organizational domain as the From domain; it can be the organizational domain, as I mentioned above. Perhaps this could be written as "When a string comparison shows that the rightmost labels of the SPF/DKIM domain are not identical to the organizational domain, in which case alignment between the two domains is not possible."? -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6
On Fri, Mar 8, 2024 at 4:52 AM Alessandro Vesely wrote: > On 06/03/2024 15:42, Todd Herr wrote: > > On Tue, Mar 5, 2024 at 10:45 PM Barry Leiba > wrote: > > > >> SHOULD NOT was the consensus call, and the correction Todd > >> proposes is just making that sentence consistent with that. > > > Yet, Section 7.6 still has: > > In particular, this document makes explicit that domains for general- > purpose email MUST NOT deploy a DMARC policy of p=reject. > > > Yes, due to an oversight on my part, one that I identified during my Last Call read of DMARCbis, and subsequently opened this thread to transparently confirm that I had indeed overlooked that phrase in 7.6 during previous releases and that I believed that it was an oversight and should be corrected. The chairs have confirmed that it was an oversight on my part, and the language will be changed to SHOULD NOT in rev -31, as per the discussion in this thread and the previous consensus. -- *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)
On Wed, Mar 6, 2024 at 7:02 PM Murray S. Kucherawy wrote: > On Wed, Mar 6, 2024 at 11:42 AM Todd Herr 40valimail@dmarc.ietf.org> 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. > > Thank you. I have opened Issue 129 to cover adding text that discusses errata from https://www.rfc-editor.org/errata_search.php?rfc=7489 that have been addressed in DMARCbis. -- *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 Issue - Clarify When Tree Walk Starts?
On Thu, Mar 7, 2024 at 5:08 AM Alessandro Vesely wrote: > On 06/03/2024 21:00, Todd Herr wrote: > > > > 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, [...] > > > > 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. > > > That's not exact. If the From: domain has more than 5 labels you don't > start with its parent domain. > > My take: > > Policy discovery starts by querying the DMARC record for the > RFC5322.From domain, as in step 1 of the DNS Tree Walk. If a record > is found there, that's the policy record, otherwise continue the > DNS Tree Walk . > > You are of course correct, Ale; thank you for spotting my error. -- *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] DMARCbis WGLC Issue - Clarify When Tree Walk Starts?
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)
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
Re: [dmarc-ietf] DMARCbis WGLC Issue - Section 11.3
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
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
On Tue, Mar 5, 2024 at 1:30 PM Scott Kitterman wrote: > > > On March 5, 2024 2:47:47 PM UTC, Todd Herr 40valimail@dmarc.ietf.org> wrote: > >On Tue, Mar 5, 2024 at 6:12 AM Alessandro Vesely wrote: > > > >> Hi, > >> > >> 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 <https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/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: 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." 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." -- *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] 5.5. Domain Owner Actions
On Tue, Mar 5, 2024 at 10:12 AM Alessandro Vesely wrote: > Hey, > > Section 5.5 misses a subsection about /creating/ reports. We want DMARC > to > be a cooperative tool, don't we? > > I'd insert such a subsection before "5.5.6 Decide Whether to Update DMARC > Policy", as a typical timeline may see the policy updates quite late, > given > the mailing list problem. Report creation can be implemented earlier. > > I still have no feedback about using SHOULD for aggregate an MAY for > failure reports. The content of an inserted 5.5.6 subsection depend on > that, so I submit no tentative text for now. > > I don't see a role for Domain Owners in creating reports. Domain Owners are the ones publishing DMARC policy records and sending mail in the hopes that their policy preferences will be honored by Mail Receivers, and it's Mail Receivers who send reports. Can you please describe the reports you'd expect Domain Owners to create? -- *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] 4.1 DMARC Basics
On Sun, Mar 3, 2024 at 4:41 AM wrote: > Hi, > > the last two paragraphs of section 4.1 also show a neat asymmetry between > rua and ruf. The first sounds like the notification that feedback exists > rather than something a mail receiver should do. The second is good, but > not normative. > > > OLD > DMARC's feedback component involves the collection of information > about received messages claiming to be from the Author Domain for > periodic aggregate reports to the Domain Owner or PSO. The > parameters and format for such reports are discussed in > [I-D.ietf-dmarc-aggregate-reporting] > > A DMARC-enabled Mail Receiver might also generate per-message reports > that contain information related to individual messages that fail > authentication checks. Per-message failure reports are a useful > source of information when debugging deployments (if messages can be > determined to be legitimate even though failing authentication) or in > analyzing attacks. The capability for such services is enabled by > DMARC but defined in other referenced material such as [RFC6591] and > [I-D.ietf-dmarc-failure-reporting] > > > NEW > A DMARC-enabled Mail Receiver SHOULD collect authentication results > and generate aggregate reports that contain information about > received messages claiming to be from the Author Domain for periodic > aggregate reports to the Domain Owner or PSO. The parameters and > format for such reports are discussed in > [I-D.ietf-dmarc-aggregate-reporting] > > A DMARC-enabled Mail Receiver MAY also generate per-message reports > that contain information related to individual messages that fail > authentication checks. Per-message failure reports are a useful > source of information when debugging deployments (if messages can be > determined to be legitimate even though failing authentication) or in > analyzing attacks. The capability for such services is enabled by > DMARC but defined in other referenced material such as [RFC6591] and > [I-D.ietf-dmarc-failure-reporting] > > Issue 127 open to track this. I think there's something here to work with. -- *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] A possible point for SPF advice
On Mon, Mar 4, 2024 at 6:30 AM Alessandro Vesely wrote: > Hi, > > Section 5 has a paragraph that can fit Scott's solution to SPF spoofing. > Here's a possible change: > > OLD > 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 not > to 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 to 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. > > NEW > 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 adjust how > some underlying authentication technologies apply to DMARC evaluation > of its domain(s). To do so, the Domain Owner directly operates on > its participation in those schemes. For example, if the results of > path authorization checks ought not to 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, or it can use the neutral > qualifier to avoid granting "pass" results to external domains (that > is, for example "v=spf1 ?include:example.com -all"). > In a world in which two of the largest mailbox providers (Google and Yahoo) are requiring SPF authentication, DKIM authentication, and DMARC pass for certain classes of mailers to get their mail accepted, I'm not sure that offering advice that will ensure the lack of an SPF pass (and therefore a lack of SPF authentication) is the right move. -- *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
On Tue, Mar 5, 2024 at 6:12 AM Alessandro Vesely wrote: > Hi, > > 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. -- *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] Another point for SPF advice
On Tue, Mar 5, 2024 at 9:30 AM Alessandro Vesely wrote:
> Hi,
>
> in section 5.5.1, Publish an SPF Policy for an Aligned Domain, the last
> sentence says:
>
> The SPF record SHOULD be constructed
> at a minimum to ensure an SPF pass verdict for all known sources of
> mail for the RFC5321.MailFrom domain.
>
> As we learnt, an SPF pass verdict has to be granted to /trusted/ sources
> only. An additional phrase about using the neutral qualifier ("?") for
> public sources might also be added.
>
>
To further this discussion, please define "public sources", compare and
contrast that definition to the definition of "private sources", and then
describe which sources are "trusted" and by whom.
--
*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] DMARCbis WGLC Issue - Description of rua and ruf Tags
Colleagues, I mentioned in a different thread that I had an issue with the description of the rua and ruf tags in Section 5.3., General Record Format, specifically that I thought that they could be more consistent in their wording. Below please find the current text (rev -30) and my proposed replacement text. CURRENT TEXT: = cut here == rua: Addresses to which aggregate feedback is to be sent (comma-separated plain-text list of DMARC URIs; OPTIONAL). [ I-D.ietf-dmarc-aggregate-reporting <#I-D.ietf-dmarc-aggregate-reporting>] discusses considerations that apply when the domain name of a URI differs from that of the domain advertising the policy. See Section 11.6 <#external-report-addresses> for additional considerations. Any valid URI can be specified. A Mail Receiver MUST implement support for a "mailto:"; URI, i.e., the ability to send a DMARC report via electronic mail. If the tag is not provided, Mail Receivers MUST NOT generate aggregate feedback reports for the domain. URIs not supported by Mail Receivers MUST be ignored. The aggregate feedback report format is described in [ I-D.ietf-dmarc-aggregate-reporting <#I-D.ietf-dmarc-aggregate-reporting>]. <#section-5.3-4.14.1> ruf: Addresses to which message-specific failure information is to be reported (comma-separated plain-text list of DMARC URIs; OPTIONAL). If present, the Domain Owner is requesting Mail Receivers to send detailed failure reports about messages that fail the DMARC evaluation in specific ways (see the "fo" tag above). [I-D.ietf-dmarc-aggregate-reporting <#I-D.ietf-dmarc-aggregate-reporting>] discusses considerations that apply when the domain name of a URI differs from that of the domain advertising the policy. A Mail Receiver MUST implement support for a "mailto:"; URI, i.e., the ability to send a DMARC report via electronic mail. If the tag is not provided, Mail Receivers MUST NOT generate failure reports for the domain. See Section 11.6 <#external-report-addresses> for additional considerations. = cut here == PROPOSED REPLACEMENT TEXT: = cut here == rua: Addresses to which aggregate feedback reports are to be sent (comma-separated plain-text list of DMARC URIs; OPTIONAL). If present, the Domain Owner is requesting Mail Receivers to send aggregate feedback reports about results of authentication checks performed on mail using the domain for which the DMARC policy record is published. [ I-D.ietf-dmarc-aggregate-reporting <#I-D.ietf-dmarc-aggregate-reporting>] discusses considerations that apply when the domain name of a URI differs from that of the domain advertising the policy. See Section 11.6 <#external-report-addresses> for additional considerations. Any valid URI can be specified. A Mail Receiver MUST implement support for a "mailto:"; URI, i.e., the ability to send a DMARC report via electronic mail. If the tag is not provided, Mail Receivers MUST NOT generate aggregate feedback reports for the domain. URIs not supported by Mail Receivers MUST be ignored. The aggregate feedback report format is described in [ I-D.ietf-dmarc-aggregate-reporting <#I-D.ietf-dmarc-aggregate-reporting>]. <#section-5.3-4.14.1> ruf: Addresses to which message-specific failure information is to be reported (comma-separated plain-text list of DMARC URIs; OPTIONAL). If present, the Domain Owner is requesting Mail Receivers to send detailed failure reports about messages that fail the DMARC evaluation in specific ways (see the "fo" tag above). [I-D.ietf-dmarc-aggregate-reporting <#I-D.ietf-dmarc-aggregate-reporting>] discusses considerations that apply when the domain name of a URI differs from that of the domain advertising the policy. See Section 11.6 <#external-report-addresses> for additional considerations. A Mail Receiver MUST implement support for a "mailto:"; URI, i.e., the ability to send a DMARC report via electronic mail. If the tag is not provided, Mail Receivers MUST NOT generate failure reports for the domain. URIs not supported by Mail Receivers MUST be ignored. The format for message-specific failure reporting is described in [ I-D.ietf-dmarc-failure-reporting <#I-D.ietf-dmarc-failure-reporting>]. = cut here == Discuss at your convenience, please... -- *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 tran
Re: [dmarc-ietf] DMARCbis WGLC Issue - Section 11.3
On Thu, Feb 29, 2024 at 10:12 PM John Levine wrote:
> It appears that Todd Herr said:
> >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.
>
> That sounds correct. If you get a timeout or a server failure, I wouldn't
> assume that processing continues.
>
Right, and given Yahoo and Google's "No delivery without DMARC policy"
edicts, I wouldn't expect them to fail open in this regard.
--
*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] Working Group Last Call on draft-ietf-dmarc-dmarcbis-30
On Thu, Feb 29, 2024 at 10:10 AM Todd Herr wrote:
> On Thu, Feb 29, 2024 at 9:58 AM OLIVIER HUREAU <
> olivier.hur...@univ-grenoble-alpes.fr> wrote:
>
>> Would you prefer one comment/issue or in batch?
>>
>
> I would prefer that Barry's request be honored from his original post in
> this thread, to wit:
>
> If you have significant issues to raise that have not already been
> discussed and closed, please post each of those as a separate thread.
> Minor issues and editorial comments can just be posted here, to this
> thread, and we can split them off if necessary.
>
>
> As I wrote:
>
> I'll be tracking minor issues and editorial comments in Github Issue 121,
>> which I've cleverly titled "WGLC Minor Issues and Editorial Comments".
>>
>
> so I can pull the minor issues and comments from this thread into that
> Github Issue.
>
Just completed a full reading of the DMARCbis document, and here are the
minor nits I've collected in Github Issue 121:
- Kurt Andersen's name is spelled incorrectly (Anderson) in the section
titled "Acknowledgements - RFC 7489"
- Introduction section: Move the word 'in' to outside the quotes in the
phrases: "in strict alignment" and "in relaxed alignment"
- 2.1 High-Level Goals: Perhaps flip-flop the first two bullet points
- 2.2 Anti-Phishing: Change "" to "display-name" and make
it link to RFC 5322 Section 3.4
- 2.3 Scalability: Change first sentence to read "Scalability is a
significant issue for systems that need to operate in *an environment* as
widely deployed as current SMTP email.
- 3.2.4 Enforcement: Change "mail using the domain name that is
unauthenticated" to "unauthenticated mail using the domain name"
- 4.7 DMARC Policy Discovery: In the following paragraph:
"Handling of DNS errors when querying for the DMARC policy record is left
to the discretion of the Mail Receiver. For example, to ensure minimal
disruption of mail flow, transient errors could result in delivery of the
message ("fail open"), or they could result in the message being
temporarily rejected (i.e., an SMTP 4yx reply), which invites the sending
MTA to try again after the condition has possibly cleared, allowing a
definite DMARC conclusion to be reached ("fail closed")."
should the word 'or' be inserted before the last clause 'allowing a
definite DMARC conclusion to be reached ("fail closed")'?
- 5.3 General Record Format - The definitions of the rua and ruf tags
are a bit messy; they should be worded essentially identically, i.e.,
Here's what the tag means, receivers must support mailto:,
$OTHER_DOCUMENT discusses third party receiver considerations and the
format of these reports. (I may break this out into its own ticket/issue
with proposed text.)
- 5.3 General Record Format - Add link to Appendix A.7 in description of
the 't' tag.
- 5.7.1 Extract Author Domain - Change MAY to may
- 7.6 Expansion of Domain Owner Actions Section - Change "domain owner"
to "Domain Owner"
--
*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] DMARCbis WGLC Issue - Section 11.3
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.
--
*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
I believe this to be the thread of reference on the topic - https://mailarchive.ietf.org/arch/msg/dmarc/ink9cG3bono8O2Vif_ibiexad0A/ That's the thread I used to guide the updates to 8.6 in rev -29, anyway. On Thu, Feb 29, 2024 at 2:53 PM Seth Blank wrote: > I thought we landed on SHOULD NOT, there was strong resistance to MUST NOT > > On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman > wrote: > >> Okay. I think 8.6 is the one in error. You see how this is going to go, >> right? >> >> Scott K >> >> On February 29, 2024 7:45:15 PM UTC, Todd Herr > 40valimail@dmarc.ietf.org> wrote: >> >It is not my intent here to relitigate any issues. >> > >> >Rather, I believe that the text in 7.6 is wrong, likely due to an >> oversight >> >on my part when the new text in 8.6 was published, and I just want to >> >confirm that 7.6 is indeed wrong. >> > >> >On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman >> >wrote: >> > >> >> In what way is this a new issue that has not already been argued to >> death >> >> in the WG? I think for WGLC, we've already done this. We will, no >> doubt >> >> get to have this conversation during the IETF last call, but for the >> >> working group, this strikes me as exactly the type of relitigation of >> >> issues we've been counseled to avoid. >> >> >> >> Scott K >> >> >> >> On February 29, 2024 6:54:57 PM UTC, Todd Herr > >> 40valimail@dmarc.ietf.org> wrote: >> >> >Colleagues, >> >> > >> >> >I've been reading DMARCbic rev -30 today with a plan to collect the >> first >> >> >set of minor edits and I came across a sentence that I believe goes >> beyond >> >> >minor, so wanted to get a sanity check. >> >> > >> >> >Section 7.6, Domain Owner Actions, ends with the following sentence: >> >> > >> >> >In particular, this document makes explicit that domains for >> >> >general-purpose email MUST NOT deploy a DMARC policy of p=reject. >> >> > >> >> > >> >> >I don't believe this to be true, however. Rather, Section 8.6, >> >> >Interoperability Considerations, says SHOULD NOT on the topic (e.g., >> "It >> >> is >> >> >therefore critical that domains that host users who might post >> messages to >> >> >mailing lists SHOULD NOT publish p=reject") >> >> > >> >> >Section 7.6 therefore should be updated to read "domains for >> >> >general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", >> yes? >> >> > >> >> >> >> ___ >> >> dmarc mailing list >> >> dmarc@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dmarc >> >> >> > >> > >> >> ___ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > -- > > *Seth Blank * | Chief Technology Officer > *e:* s...@valimail.com > *p:* > > 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 > -- *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
It is not my intent here to relitigate any issues. Rather, I believe that the text in 7.6 is wrong, likely due to an oversight on my part when the new text in 8.6 was published, and I just want to confirm that 7.6 is indeed wrong. On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman wrote: > In what way is this a new issue that has not already been argued to death > in the WG? I think for WGLC, we've already done this. We will, no doubt > get to have this conversation during the IETF last call, but for the > working group, this strikes me as exactly the type of relitigation of > issues we've been counseled to avoid. > > Scott K > > On February 29, 2024 6:54:57 PM UTC, Todd Herr 40valimail@dmarc.ietf.org> wrote: > >Colleagues, > > > >I've been reading DMARCbic rev -30 today with a plan to collect the first > >set of minor edits and I came across a sentence that I believe goes beyond > >minor, so wanted to get a sanity check. > > > >Section 7.6, Domain Owner Actions, ends with the following sentence: > > > >In particular, this document makes explicit that domains for > >general-purpose email MUST NOT deploy a DMARC policy of p=reject. > > > > > >I don't believe this to be true, however. Rather, Section 8.6, > >Interoperability Considerations, says SHOULD NOT on the topic (e.g., "It > is > >therefore critical that domains that host users who might post messages to > >mailing lists SHOULD NOT publish p=reject") > > > >Section 7.6 therefore should be updated to read "domains for > >general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", yes? > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *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] DMARCbis WGLC Significant(ish) Issue - Section 7.6
Colleagues, I've been reading DMARCbic rev -30 today with a plan to collect the first set of minor edits and I came across a sentence that I believe goes beyond minor, so wanted to get a sanity check. Section 7.6, Domain Owner Actions, ends with the following sentence: In particular, this document makes explicit that domains for general-purpose email MUST NOT deploy a DMARC policy of p=reject. I don't believe this to be true, however. Rather, Section 8.6, Interoperability Considerations, says SHOULD NOT on the topic (e.g., "It is therefore critical that domains that host users who might post messages to mailing lists SHOULD NOT publish p=reject") Section 7.6 therefore should be updated to read "domains for general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", yes? -- *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] Working Group Last Call on draft-ietf-dmarc-dmarcbis-30
On Thu, Feb 29, 2024 at 9:58 AM OLIVIER HUREAU < olivier.hur...@univ-grenoble-alpes.fr> wrote: > Would you prefer one comment/issue or in batch? > I would prefer that Barry's request be honored from his original post in this thread, to wit: If you have significant issues to raise that have not already been discussed and closed, please post each of those as a separate thread. Minor issues and editorial comments can just be posted here, to this thread, and we can split them off if necessary. As I wrote: I'll be tracking minor issues and editorial comments in Github Issue 121, > which I've cleverly titled "WGLC Minor Issues and Editorial Comments". > so I can pull the minor issues and comments from this thread into that Github Issue. -- *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] Working Group Last Call on draft-ietf-dmarc-dmarcbis-30
On Wed, Feb 28, 2024 at 7:37 PM Barry Leiba wrote: > The editors and chairs think version -30 resolves the open issues and is > ready for a final look, so this message starts a working group last call > for the DMARCbis spec. Because of the upcoming IETF 119 meeting, we’ll let > this go until the end of March, so there’s lots of time to review. > > Please post to the DMARC mailing list by 31 March, giving your last call > comments (which should include “I read it and I think it’s ready” as > well). If you have significant issues to raise that have not already been > discussed and closed, please post each of those as a separate thread. > Minor issues and editorial comments can just be posted here, to this > thread, and we can split them off if necessary. > > Please do keep in mind that we have discussed this at great length and > over a long time period. Therefore, please do NOT ask to re-open settled > issues because you still disagree with the result. Significant issues > raised at this point need to be accompanied by a clear, understandable > explanation of why this is a NEW argument. > > I'll be tracking minor issues and editorial comments in Github Issue 121, which I've cleverly titled "WGLC Minor Issues and Editorial Comments". I've already found one: Kurt Andersen's last name is misspelled in "Acknowledgements - RFC 7489". https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/121 -- *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] Inconsistencies in DMARC Aggregate Report XML Schema
On Wed, Feb 28, 2024 at 6:27 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I interpret your data differently. These domains collected data until it > was clear that they could safely move to enforcement. Thereafter, they > saw no need to study reports, at least until their configuration changes. > Daily reporting is perceived as a waste of system and staff resources. > > I suggested an errors-only reporting option, which would allow for error > monitoring without the wasted resources, but it was discarded by the group. > > Not all DMARC passes are intentional passes. The SPF upgrade attacks that we've witnessed over the past year or so and too-permissive SPF records in general are but two examples of where DMARC passes can occur for mail that was not authorized by the Domain Owner. A reporting model that only reports failures would not reveal these flows to the Domain Owner. Please note that I am explicitly NOT arguing for a DMARC mechanism that does not rely on SPF; in fact I oppose such a thing at this time. Rather, I submit that it behooves Domain Owners to routinely clean and manage their SPF records to mitigate against risk of these sorts of attacks, and DMARC aggregate reports are a tool that can be used to do so. -- *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] I-D Action: draft-ietf-dmarc-dmarcbis-30.txt
Summary of changes from rev -29... 1. Removed mention of "XML" from Section 5.5.3, Setup a Mailbox to Receive Aggregate Reports. This is future-proofing against any format changes that might be published in a later version of the aggregate reports document. Reports are now just described as meant to be machine-parsed. 2. Added mention in section 7.4 that the ability to specify a maximum report size request had been removed from this version of DMARC. 3. Added language to 5.7.1 and 11.5 to discuss a way to handle multi-valued From fields. 5.7.1 allows that a Receiver may choose to go forward and do DMARC processing, and 11.5 includes clawing back some of the text on the subject that was in RFC 7489. On Wed, Feb 28, 2024 at 6:04 PM wrote: > Internet-Draft draft-ietf-dmarc-dmarcbis-30.txt is now available. It is a > work > item of the Domain-based Message Authentication, Reporting & Conformance > (DMARC) WG of the IETF. > >Title: Domain-based Message Authentication, Reporting, and > Conformance (DMARC) >Authors: Todd M. Herr > John Levine >Name:draft-ietf-dmarc-dmarcbis-30.txt >Pages: 72 >Dates: 2024-02-28 > > 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 the use of the domain >name. Mail receiving organizations can use this information when >evaluating handling choices for incoming mail. > >This document obsoletes RFCs 7489 and 9091. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-dmarcbis-30 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > > -- *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] Inconsistencies in DMARC Aggregate Report XML Schema
On Wed, Feb 28, 2024 at 10:50 AM Brotman, Alex wrote: > Olivier, > > > > Yes, we’re firmly attached to XML for this iteration. With the splitting > of the documents, perhaps this could change in the future without changing > the functionality of DMARC itself. > > > > Agreed on 5.5.3. > I also agree on 5.5.3, and DMARCbis rev-30 will contain no occurrences of the three letter sequence "XML". -- *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] dmarc-dmarcbis: add "req=dkim"
On Thu, Feb 8, 2024 at 5:32 AM Jeroen Massar wrote: > [multiple responses aggregated] > > > On 6 Feb 2024, at 22:22, John R. Levine wrote: > > > >>> Unless something important has changed since the last time we took up > >>> and rejected this idea, I don't think we need to discuss it further. > >> > >> Is the reasoning documented? I have checked the list archives, but > there is a LOT of list archives... > > > > The main reason is that it's much too late in the process for such a > large change, and a lesser reason is that it's not clear how it would > interact with the DKIM replay work that some people claim is going to > happen real soon now. > > > >> For gmail.com <http://gmail.com/> as a very big example SPF passes due > to ~all and the evaluation of DKIM can be ignored ... > > > > Uh, no. ~all is a soft fail. > > Together with DMARC p=none as DKIM signature-presence is ignored and thus > any email can pass. > DMARC p=none does not mean "any email can pass". DMARC p=none means "If this message fails DMARC authentication, please do not include that failure as part of the disposition decision". The message you're describing would fail DMARC, not pass, because SPF would fail and the message would be unsigned. What a receiver does with that message, or any message, is up to the discretion of the receiver, and DMARC does not change that, regardless of the policy setting for the claimed sending domain or the DMARC validation results. Sites participating in DMARC are not required to honor the policy statement published by the domain owner. -- *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] dmarc-dmarcbis: add "req=dkim"
On Tue, Feb 6, 2024 at 3:26 PM Jeroen Massar wrote: > > > > On 6 Feb 2024, at 20:52, John Levine wrote: > > > > It appears that Jeroen Massar said: > >> Hi Folks, > >> > >> As DMARCbis is being updated, I would like to suggest a new tag > `required` shorted to `req`. > >> > >> ``` > >> `req=dkim`: requires DKIM, messages not properly signed are then to be > rejected/quarantined based on 'p' policy. > >> > >> The tag should allow future expansion by requiring multiple mechanisms > to be required by specifying > >> multiple mechanisms separate, e.g. with `req=dkim,spf`. ... > > > > Unless something important has changed since the last time we took up > > and rejected this idea, I don't think we need to discuss it further. > > Is the reasoning documented? I have checked the list archives, but there > is a LOT of list archives... > This thread seems to show us landing on having such a tag - https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/ But then this subsequent thread appears to have landed on not having the tag after all - https://mailarchive.ietf.org/arch/msg/dmarc/lplcAiYMqCh_Grp7lwfbDqlVicA/ > > As at the moment, as per the example I gave in the email, DKIM is futile > to have if SPF passes. > Your example shows an SPF result of "softfail", which I do not understand to be a "pass". Why do you contend that it is a pass? -- *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] DMARC with multi-valued RFC5322.From
On Thu, Jan 18, 2024 at 9:28 PM Hector Santos wrote:
> Hi,
>
> As a long time implementer and integrator of IETF protocols, my mail
> engineering view ….
>
> The thing is RFC 822, 2822 and 5322 allows for a single 5322.From header
> to have multiple addresses:
>
> from = "From:" mailbox-list CRLF
> mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
>
True, but in such cases, it requires that there be a Sender: header with
exactly one mailbox as a value -
https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.2
[snip]
>
>
> However, if I have been following this thread, DMARCBis was updated to
> ignore these multi-from messages for DMARC purposes because they
> (erroneously) presumed they should be rejected, i.e. never make it to a
> signer or verifier.
>
> I am not sure that is correct.
>
Perhaps the way forward for DMARC is to look for a Sender header when there
is more than one RFC5322.From domain and use that for DMARC processing,
with the stipulation that messages that don't contain such a Sender header
are invalid and should be rejected?
--
*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] DMARC with multi-valued RFC5322.From
On Thu, Jan 11, 2024 at 11:51 AM Damien Alexandre wrote: > Hello, > > A question I have reading the RFC7489 and more precisely the part «6.6.1 > Extract Author Domain». > https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.1 > > > The RFC first states: > > "Messages bearing a single RFC5322.From field containing multiple > addresses (and, thus, multiple domain names to be evaluated) are > typically rejected because the sorts of mail normally protected by > DMARC do not use this format;” > > And a few lines below: > > "The case of a syntactically valid multi-valued RFC5322.From field > presents a particular challenge. The process in this case is to > apply the DMARC check using each of those domains found in the > RFC5322.From field as the Author Domain and apply the most strict > policy selected among the checks that fail.” > > I find the two propositions quite contradictory and not sure which one > should be applied. > > DMARCbis has rewritten these sections and has text that you may find helpful. https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#name-extract-author-domain 5.7.1. <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#section-5.7.1>Extract Author Domain <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#name-extract-author-domain> The domain in the RFC5322.From header field is extracted as the domain to be evaluated by DMARC. If the domain is a U-label, the domain name MUST be converted to an A-label, as described in Section 2.3 of [RFC5890 <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#RFC5890>], for further processing.¶ <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#section-5.7.1-1> If zero or more than one domain is extracted, then DMARC processing is not possible and the process terminates. See Section 11.5 <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#denial-of-dmarc-attacks> for further discussion. https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#name-denial-of-dmarc-processing- 11.5. <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#section-11.5>Denial of DMARC Processing Attacks <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#name-denial-of-dmarc-processing-> The declaration in Section 5.7.1 <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#extract-author-domain> and elsewhere in this document that messages that do not contain precisely one RFC5322.From domain are outside the scope of this document exposes an attack vector that must be taken into consideration. Because such messages are outside the scope of this document, an attacker can craft messages with multiple RFC5322.From domains, including the spoofed domain, in an effort to bypass DMARC validation and get the fraudulent message to be displayed by the victim's MUA with the spoofed domain successfully shown to the victim. In those cases where such messages are not rejected due to other reasons (for example, many such messages would violate RFC5322's requirement that there be precisely one From: header), care must be taken by the receiving MTA to recognize such messages as the threats they might be and handle them appropriately. <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#section-11.5-1> -- *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] I-D Action: draft-ietf-dmarc-dmarcbis-29.txt
Revision 28 was due to expire this weekend, so I tweaked the language a bit in section 8.6 in response to the thread Francesca started here - https://mailarchive.ietf.org/arch/msg/dmarc/ink9cG3bono8O2Vif_ibiexad0A/ I expect rev 30 will have a few more changes. On Tue, Jan 2, 2024 at 3:09 PM wrote: > Internet-Draft draft-ietf-dmarc-dmarcbis-29.txt is now available. It is a > work > item of the Domain-based Message Authentication, Reporting & Conformance > (DMARC) WG of the IETF. > >Title: Domain-based Message Authentication, Reporting, and > Conformance (DMARC) >Authors: Todd M. Herr > John Levine >Name:draft-ietf-dmarc-dmarcbis-29.txt >Pages: 72 >Dates: 2024-01-02 > > 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 the use of the domain >name. Mail receiving organizations can use this information when >evaluating handling choices for incoming mail. > >This document obsoletes RFCs 7489 and 9091. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-dmarcbis-29 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *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] Codifying "Apex Domain"?
Colleagues, I note that lately in various email fora that the term "apex domain" has found some favor, said term being used interchangeably with "organizational domain", and having the same contextual meaning as "organizational domain". DMARCbis does not contain the word "apex", nor did RFC 7489 before it. My question here is, should DMARCbis at least mention the term "apex domain", perhaps in section 3.2.9, Organizational Domain. The entirety of that section currently reads: The Organizational Domain for any domain is determined by applying the algorithm found in Section 4.8 <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-28.html#organizational-domain-discovery> . Does it make sense to change that to The Organizational Domain for any domain is determined by applying the algorithm found in Section 4.8 <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-28.html#organizational-domain-discovery>. The Organizational Domain is also sometimes referred to as the Apex Domain. Discuss... -- *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] Jumping the Gun
Someone posting at Security Boulevard has decreed that DMARCbis (at least the t= tag parts of it) are now codified: https://securityboulevard.com/2023/10/dmarc-t-tag-replaces-pct-in-dmarcbis/ This person did a fantastic job of cutting and pasting from DMARCbis to "create" their "content". -- *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] DMARCbis rev 29 (was: Re: DMARCbis way forward: Do we need our session at IETF 118)
On Tue, Oct 24, 2023 at 2:15 PM Barry Leiba wrote: > Now that we have a consensus call on the main issue that has remained open: > > 1. Do we need to retain our session at IETF 118 and discuss this (or > something else) further? > > ...or... > > 2. Do we have what we need to finish up the DMARCbis document, and > should the chairs cancel the session at 118? > > Oh, and... > > 3. Is there something else (such as the reporting documents) that we > should use the time at 118 to discuss? Or can we continue with those > on the mailing list for now? My sense is that aggregate reporting, at > least, is just about ready to go and doesn't need the face-to-face > time. > > I think canceling the session at 118 is the way to go. I further think that the best way to produce the next rev of DMARCbis is for the chairs and the editors (and perhaps the ADs) to huddle together and create/update issues in the Github repository for the sections of text for which changes have been proposed. At a minimum, the outcome of this meeting would be several bullet points all following this pattern: - Create/update GitHub issue with $TITLE using text from $MAILING_LIST_THREAD Todd, as editor whose mail client isn't one that lends itself well to piecing together multiple threads into a coherent list... -- *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] Why Relaxed Alignment?
On Tue, Oct 17, 2023 at 9:51 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Why do we need to support relaxed alignment at all? > > A common use case for relaxed alignment is when an organization (e.g., WeSellStuff) employs a third party Email Service Provider (e.g., WeSendEmail) to send mail on the organization's behalf. In that case, we might have the following: Return-Path domain: bounces.wesellstuff.com DKIM signing domain: wesendemail.wesellstuff.com RFC5322.From domain: marketing.wesellstuff.com The above configuration allows for WeSendEmail to manage the SPF record for bounces.wesellstuff.com and for an MX record for bounces.wesellstuff.com to be pointed at WeSendEmail, so that they can handle bounce processing and other Delivery Status Notifications. It also allows for WeSendEmail to DKIM sign on behalf of WeSellStuff using a dedicated subdomain that is delegated to WeSendEmail, which can publish the public key in DNS and generate the private key and keep it private to use for signing mail it sends. Meanwhile, WeSellStuff only has to delegate responsibility for those parts of the DNS that are specific to WeSendEmail's sending to WeSendEmail. -- *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] Tree Walk impact
On Tue, Oct 10, 2023 at 6:14 AM Alessandro Vesely wrote: > On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote: > > Both approaches have problems. Stop-at-last enables the walk to exit > the > > current organization and stop on a private registry, for both alignment > > evaluation and for aggregate report transmission. This is not a minor > > problem, even if it is arguably infrequent. > > > The illustrative example in the draft says: > > _dmarc.a.b.c.d.e.mail.example.com > _dmarc.e.mail.example.com > _dmarc.mail.example.com > _dmarc.example.com > _dmarc.com > > That is, no stop at all. In this respect, a psd=n at example.com would > save a > lookup. However, it is not something that we can recommend, after we > chose the > obscure tag name. > > I'm not sure I understand what you're saying... The illustrative example cited is intended to illustrate a full tree walk that follows the steps for a full tree walk that are spelled out in the numbered list just prior to the illustrative example. That numbered list includes conditional stops (i.e., if one record is found with the specified condition, stop) in steps 2 and 7. -- *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] Aggregate Report Draft
ity that low-traffic reports might allow mapping of record elements to individuals, while the tone of 6.3 says that there is no PII, full stop. Might make sense to only address the topic in one section, rather than two. Section 6.4, Feedback Leakage. The paragraph on Multi-organizational PSDs that require DMARC starts with the word "Reports" stretched over two lines, but not hyphenated. Section 10, Normative References, contains no mention of RFC 7489 and/or DMARCbis, which seems odd. -- *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] SMTP Result Codes was -Re: Another p=reject text proposal
On Wed, Jul 12, 2023 at 7:30 AM Scott Kitterman wrote: > On Wednesday, July 12, 2023 7:04:38 AM EDT Alessandro Vesely wrote: > > On Wed 12/Jul/2023 12:54:38 +0200 Scott Kitterman wrote: > > > On Wednesday, July 12, 2023 3:29:34 AM EDT Baptiste Carvello wrote: > > > ... > > > > > >> Why? Because it's brittle and will only bring them more headaches? At > > >> the very least, DMARC would need to use its own 5xy reply code to > avoid > > >> the need for parsing the reply text… > > > > > > This is a very good point. The IANA Simple Mail Transfer Protocol > (SMTP) > > > Enhanced Status Codes Registry [1] has codes for SPF and DKIM (RFC > 7372) > > > and ARC (RFC 8617), but not DMARC. Adding one is not currently in the > > > DMARCbis draft, but I think it should be. > > > > +1; still, having the word "DMARC" in the text greatly simplifies parsing > > logs. > > > > > > I noted that Baptiste wrote 5xx, not 5.x.x. 5xx has to be 550 methinks. > > I agree re 550. Also, if I were writing the reject message that goes > after > the code, I would include DMARC in it. I suspect most will for human > readability, but programatically, I'd use the codes if present. > Google uses 5.7.26 for the purpose (and for SPF and DKIM rejects): https://support.google.com/a/answer/3726730?sjid=16541570162287939258-NA Their use of 5.7.26 seems in keeping with IANA - Multiple authentication checks failed - since in order to fail DMARC, both SPF and DKIM must fail. https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml -- *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] Another p=reject text proposal
On Thu, Jul 6, 2023 at 3:00 PM Barry Leiba wrote: > That's fine, as long as we're all understanding that it's still just a > proposal and we'll be discussing it at IETF 117 and on the mailing list. > Absolutely. I just wanted to have a fresh draft in place before the cut off date, and today was as good a time for that as any. -- *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] Another p=reject text proposal
I'll prepare a new rev incorporating this proposed text (and some other unrelated stuff that's been lying fallow for a few months) and release it today. On Thu, Jul 6, 2023 at 12:02 PM John Levine wrote: > It appears that Barry Leiba said: > >This makes it explicitly clear that any MUST/SHOULD stuff with regard > >to using and honoring p=reject is an issue of interoperating with > >existing Internet email features. I can accept that mechanism also, > >and so, below is my attempt at writing that proposal up. > > This seems about as good as we're going to get. > > I agree that advice about From: munging and anything else about how > forwarders might rewrite messages to circumvent DMARC is wildly out of > scope. We currently don't mention ARC at all. Dunno if it's worth > a non-normative pointer somewhere. > > R's, > John > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *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] Idle Musings - Why Is It DMARC and not DMARD?
Genuine curiosity question here for those who were around at the beginning... Why is the mechanism called "Domain-based Message Authentication, Reporting, and Conformance" and not "Domain-based Message Authentication, Reporting, and Disposition"? Perhaps a better question, why is "conformance" in the name of the mechanism? I ask because I'm writing up some stuff for internal use, and I got curious as to how conformance is defined or explained in RFC 7489, and well, it's not. The word appears five times in RFC 7489, and each occurrence is in the context of spelling out the full name of the mechanism. I am not looking to change the name of the mechanism; I'm just genuinely curious how the name was arrived at. -- *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] SPF/DKIM/DMARC statistics from Valimail
Colleagues, We looked at data covering a time period of several months and more than a quarter of a trillion DMARC pass results to get a sense for the impact of what a change to DKIM-only might mean for DMARC. Here's what we found. - 3.65% of all DMARC passes recorded had only an aligned SPF pass - 1.35% of all DMARC passes recorded had only an aligned SPF pass and no DKIM signature - 2.28% of all DMARC passes recorded with p=quarantine or p=reject had only an aligned SPF pass - 0.89% of all DMARC passes recorded with p=quarantine or p=reject had only an aligned SPF pass and no DKIM signature Relatively small percentages, I'll grant you, but rather a large sample size. As for domains, looking across many tens of thousands of domains... - For 60% of all domains with DMARC pass verdicts, at least some of those passes had only an aligned SPF pass - For 32.7% of all domains with DMARC pass verdicts, at least some of those passes had only an aligned SPF pass and the prevailing DMARC policy was either quarantine or reject We also found that of the mailing services used by our customers that we refer to as "configurable" (meaning that they support one or both of an aligned SPF and aligned DKIM configuration), 44.2% of those configurable services currently only support aligned SPF. We also found that among our customers who use these services that only support aligned SPF, the average number of such services used is three. When I look at these numbers (and others that have been presented on this list) I see more evidence of what Mr. Kitterman termed "poor deployments of the protocol(s)", and I believe those problems should be fixed. I just don't think that changing the DMARC protocol to force the fix is the right way to go here. -- *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] easier DKIM, DMARC2 & SPF Dependency Removal
On Thu, Jun 22, 2023 at 9:18 AM Sebastiaan de Vos wrote: > In that case, if I understand correctly, Marty is sending his E-mail > untested and unmonitored. Is that not Marty's problem, really? Where are we > heading if we try to fix that problem? > You seem to be ascribing malice to Marty here where I intended no such thing. Marty has the right (as conveyed by their employer) to send mail using his employer's domain, and Marty wants to do the right thing and have that email sent with DKIM signatures that use the domain in the d= tag, thereby allowing the domain to claim responsibility for the message. Marty also has the right to engage a third party to send the mail (again, as conveyed by their employer), mail that Marty and others at Marty's company will create. The third party here is most commonly referred to, in my experience, as an Email Service Provider (ESP), but this is just one use case. The ESP knows how to DKIM sign messages, and can even do so using the domain of Marty's employer, so long as Marty is able to get the public key published in DNS. It has been my experience that as the size of an organization grows, the ability of Marty to get DNS records published and published correctly becomes more challenging. This is not a problem for the DMARC Working Group to solve, of course; I do think it's a problem for the larger community to solve, and as I posted up-thread, Domain Connect is one attempt to do just that. However, I do think it's a problem that we must be aware of as we consider whether or not to make a DKIM-aligned pass a requirement for a DMARC pass, as opposed to its current state of optional, where it's needed only when an SPF-aligned pass is not present. When we look at the numbers others have posted on the topic, and we see a perhaps higher than expected percentage of DMARC passes that relied on SPF only (or at least a higher than expected rate of DKIM failures) I'd posit that many of those DKIM failures are due to the challenges that Marty and people like them face with getting the key published. -- *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] easier DKIM, DMARC2 & SPF Dependency Removal
On Wed, Jun 21, 2023 at 4:22 AM Alessandro Vesely wrote: > On Tue 20/Jun/2023 15:40:11 +0200 Todd Herr wrote: > > > > I can't speak for Patrick, but I don't think he's necessarily thinking > of > > different encryption algorithms here. > > > > Not all who wish to have their email DKIM signed have the luxury that > you > > have John of full control of the DKIM signing process. I'm specifically > > thinking of the entity (call them Marty Marketer) who has the authority > to > > employ a third party to send authenticated mail on behalf of a domain, > mail > > that the third party can and will DKIM sign using the entity's domain. > > Sadly, Marty does not have the authority to update DNS for that domain > in > > order to publish a DKIM public key. This leads to challenges as the > third > > party presents to Marty a public key to publish, and Marty tries to > figure > > out to whom to pass along this information and in what format. This > leads > > to screen caps, or cutting and pasting errors, misdirected mail chains, > > etc., etc. > > > > Is this the way it should be? Probably not, but it's a reality for many, > > and it's a problem we don't as an industry have an answer for yet. If we > > did, there wouldn't be people in the other thread reporting such a high > > percentage of DKIM failures due to malformed/missing keys. > > > > Now, of course we could argue that Marty shouldn't be left to their own > > devices to engage third party senders, and that should solely be the > > province of the IT staff that manages DNS, but I fear that the energy > > required to type and distribute such words would be wasted. > > > Creating more and more publishing mechanisms could reproduce the situation > of > SPF, whereby customers of the same third party can easily impersonate one > another. > > DKIM signatures have to be created by MSAs upon user authentication. MSAs > which use smarthosts, IMHO, had better sign just the header fields they > control > rather than delegate signing. Doesn't Marty have any option on that? > > > I'm afraid I've done a poor job of making my point, as it seems that you haven't understood what I was trying to say. Let me try again. The scenario I'm describing here isn't referring to the actual DKIM signing of any given message. Rather, I'm talking about the publication of the DKIM public key in DNS to support the validation of signed mail. In this scenario, Marty has hired a third party email service provider (e.g., WeSendMail) to handle a class of bulk sending on behalf of Marty's organization (e.g., WeSellStuff.com). Marty wants WeSendMail to DKIM sign that mail using d=wesellstuff.com, and WeSendMail can do that, so Marty clicks a button or whatever in the WeSendMail UI to make that happen. The UI pops up a screen that says "Please publish this TXT record in your DNS", where the name is WSMWSSSelector._domainkey.wesellstuff.com and the value is the DKIM public key. Marty doesn't control DNS for wesellstuff.com . Maybe Marty knows who does control DNS, and Marty is good at cutting and pasting, and Marty can successfully communicate the request to the DNS people for wesellstuff.com. Maybe Marty has no clue who to engage, or maybe Marty misses a character in the cutting and pasting, or maybe Marty just does a screen capture and the DNS folks mess up something when transcribing the contents of the picture, or... Might something like Domain Connect (https://www.domainconnect.org/) solve this? Sure, it could, and its website even describes a scenario identical to what I'm trying to describe here. However, Domain Connect seems to be a bit hand-wavy on the concept of authorization when it comes to making changes to DNS zones, and in this scenario, Marty doesn't have those credentials. -- *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] easier DKIM, DMARC2 & SPF Dependency Removal
On Mon, Jun 19, 2023 at 8:25 PM John R Levine wrote: > On Mon, 19 Jun 2023, Patrick Ben Koetter wrote: > > I suggest that we do not only drop SPF, but also come up with better ways > > (simplification, tools, exchange formats) to implement DKIM in order to > allow > > for a smooth transition. > > I'm scratching my head here. On my system I publish and rotate DKIM keys > completely automatically. The only manual config is to edit the list of > domains when I add or remove one from my mail server. It's not totally > trivial but it's not that hard. > > I suppose we could encourage people to implement ed25519 signatures since > the keys are small and more likely to fit in a single TXT record string > for provisioning crudware that doesn't handle multiple strings, but beyond > that, what do you have in mind? > > I can't speak for Patrick, but I don't think he's necessarily thinking of different encryption algorithms here. Not all who wish to have their email DKIM signed have the luxury that you have John of full control of the DKIM signing process. I'm specifically thinking of the entity (call them Marty Marketer) who has the authority to employ a third party to send authenticated mail on behalf of a domain, mail that the third party can and will DKIM sign using the entity's domain. Sadly, Marty does not have the authority to update DNS for that domain in order to publish a DKIM public key. This leads to challenges as the third party presents to Marty a public key to publish, and Marty tries to figure out to whom to pass along this information and in what format. This leads to screen caps, or cutting and pasting errors, misdirected mail chains, etc., etc. Is this the way it should be? Probably not, but it's a reality for many, and it's a problem we don't as an industry have an answer for yet. If we did, there wouldn't be people in the other thread reporting such a high percentage of DKIM failures due to malformed/missing keys. Now, of course we could argue that Marty shouldn't be left to their own devices to engage third party senders, and that should solely be the province of the IT staff that manages DNS, but I fear that the energy required to type and distribute such words would be wasted. -- *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] Tree Walk Damage
On Wed, May 3, 2023 at 11:51 AM Barry Leiba wrote: > And now following this up as chair: > > I believe this topic has been discussed at length before and is well > settled: the working group's rough consensus on the tree walk is > clear. Todd, please close issue 113 as settled, with no document > change needed. > Done. -- *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
