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 _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
