Issue 182 has been created for this thread - https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/182
On Thu, Feb 6, 2025 at 4:56 PM John R. Levine <[email protected]> wrote: > > 296 Domain Owners can use these reports, especially the aggregate > > 297 reports, not only to identify sources of mail attempting to > > 298 fraudulently use their domain, but also (and perhaps more > > 299 importantly) to flag and fix gaps in their own authentication > > 300 practices. However, as with honoring the Domain Owner's > stated mail > > ``` > > How common is it to receive information in these reports that is > impossible to > > fix? In other words, are these reports generating alert fatigue more > often than > > they are helping identify real threats? There is also the question of the > > cost(cpu/memory/traffic/sustainability) of sending the reports. > > Fairly common, but DMARC reports are all sent and processed automatically. > My tiny system has received over 600,000 reports over the years and the > load has been negligible. There are many services that will receive and > process your reports for you if you don't want to do it yourself. > > > 816 Author Domain. Neither approach is recommended, however. > > ``` > > I assume: > > > > It is RECOMMENDED to enable both DKIM and SPF. > > Yes. > > > ### MUST NOT change p=none > > ``` > > 1514 Identifiers being unaligned or missing entirely. For such > legitimate > > 1515 uses, these shortcomings MUST be addressed prior to any > attempt by > > 1516 the Domain Owner to publish a Domain Owner Assessment Policy > > 1517 (#domain-owner-policy) of Enforcement (#enforcement) for the > Author > > 1518 Domain. > > ``` > > > > How does this MUST achieve interoperability? > > If you publish p=none, people will accept your mail even if it's > unaligned. If you publish anything else they will reject it. Cue long > rant about mailing lists. > > > 1712 Per-message failure reports can be a useful source of > information for > > 1713 a Domain Owner, either for debugging deployments or in > analyzing > > 1714 attacks, and so Mail Receivers MAY choose to send them. > Experience > > 1715 has shown, however, that Mail Receivers rightly concerned > about > > 1716 protecting user privacy have either chosen to heavily redact > the > > 1717 information in such reports (which can hinder their > usefulness) or > > 1718 not send them at all. See [I-D.ietf-dmarc-failure-reporting] > for > > 1719 further information. > > ``` > > > > This MAY reads to me as a SHOULD NOT, given the privacy risk can the > guidance > > be strengthened? > > it really depends on the system. In practica hardly anyone sends faiure > reports so it's not worth a lot of effort to tweak. > > > 1735 Mail Receivers MAY choose to accept email that fails the DMARC > > 1736 validation check even if the published Domain Owner > Assessment Policy > > 1737 is "reject". In particular, because of the considerations > discussed > > 1738 in [RFC7960] and in Section 7.4 of this document, it is > important > > 1739 that Mail Receivers SHOULD NOT reject messages solely because > of a > > 1740 published policy of "reject", but that they apply other > knowledge and > > 1741 analysis to avoid situations such as rejection of legitimate > messages > > 1742 sent in ways that DMARC cannot describe, harm to the > operation of > > 1743 mailing lists, and similar. > > ``` > > The guidance here regarding reject feels like a weak point in the > document. > > In context, this reads as "reject" is NOT RECOMMENDED, and if present > MAY be > > ignored. It is RECOMMENDED to ignore it, when "other knowledge" enables > > legitimate messages to be distinguished? > > That means mailing lists. > > > ``` > > 1857 If a Mail Receiver elects to defer delivery due to the > inability to > > 1858 retrieve or apply DMARC policy, this is best done with a 4xy > SMTP > > 1859 reply code. > > ``` > > Should this guidance be normative? > > Never seen it heppen in practice. > > > 2399 11.7. Secure Protocols > > > > 2401 This document encourages the use of secure transport > mechanisms to > > 2402 prevent the loss of private data to third parties that may be > able to > > 2403 monitor such transmissions. Unencrypted mechanisms should be > > 2404 avoided. > > > > 2406 In particular, a message that was originally encrypted or > otherwise > > 2407 secured might appear in a report that is not sent securely, > which > > 2408 could reveal private information. > > ``` > > Is it possible to strengthen the guidance here (MUST / SHOULD)? > > Honestly, I would delete this entire section since so few people send > failure reports. I think it is entirely hypothetical. > > Regards, > John Levine, [email protected], Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > -- Todd Herr Some Guy in VA LLC [email protected] 703-220-4153 Book Time With Me: https://calendar.app.google/tGDuDzbThBdTp3Wx8
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
