Rather than approaching the topic based on the degree of completeness that has been achieved, I prefer to approach it from the perspective of functional components that should be implemented jointly. I propose six function groups. The grouping and the justification for that grouping appear below.
Doug Foster Sender: Capabilities required prior to publishing a DMARC policy - Sender should assume that some recipients may uplift from p=none to p=quarantine or uplift p<100 to p=100. To minimize the risk of blocked messages, known mail sources should be configured with DKIM signatures before a DMARC policy is published. - Sender should assume that, on initial implementation, the domain will have some legitimate but not-verifiable messages. Therefore an rua=address destination must be configured in the policy to become aware of those problems. Recipients which detect a DMARC policy without any rua=address can assume that the sender is not serious and the policy is not trustworthy. - Sender should have a process in place for reviewing DMARC reports to detect and correct errors that cause DMARC verification failures. Sender / Mediator: Capabilities required for a DMARC-aware outbound gateway - Sender / Mediator should be aware that transmitting messages which fail DMARC verification could lead to reputation problems, ranging from individual messages being rejected to the source domain's servers being blacklisted. - Therefore, outbound traffic should be handled as follows:- Determine whether each message's source domain has a DMARC-enforcing policy. - If required, implement one of these compliance measures:- Ensure that a valid DKIM signature is present, based on a known-good configuration flow or based on a test verification.- Add a valid DKIM signature if one is not present and a DKIM key is available.- Rewrite the From address to the local domain, and preferably add a DKIM signature for the local domain, so that the message will pass DMARC when it is received.- Reject the message as undeliverable. Recipient: Capabilities required for a DMARC-aware incoming gateway. - Recipient should assume that some legitimate senders will have configuration errors, even if sender policy asks for enforcement. Any DMARC-enforcing implementation should have an exception mechanism for overriding p=quarantine or p=reject for specific MailFrom + From combinations. - Recipient should consider that whitelisting a trusted sender is only safe if spoofing risk has been ruled out. DMARC-verified combinations of Mail>From + From provides the recipient with the spoof-safe information needed to support whitelisting when whitelisting is desired. Any DMARC-enforcing implementation should allow DMARC verification status to be included in a whitelisting policy rule. Recipient: Capabilities required for an incoming gateway with DMARC "rua" reporting - Incoming gateway must accurately test incoming messages for DMARC policy compliance - Incoming messages and their DMARC status must be logged into a database that supports reporting. - An automated process must be in place to parse the database to generate the DMARC "rua" reports on the required schedule. - An automated submission process must be in place to transmit the generated "rua" reports when they are generated. Recipient: Capabilities required for an incoming gateway with DMARC "ruf" reporting - Incoming gateway must integrate DMARC-policy checking with message threat assessment. - Incoming gateway must provide configuration mechanism to specify whether or not a specific ruf-requesting domain should actually be given such notices. The reporting policy will depend on the recipient's perception of the source's good administrative intentions. - Incoming gateway must provide configuration mechanisms to specify which types of undesired messages will trigger an "ruf" report. - Incoming gateway must be able to generate and transmit an "ruf" report in a timely manner after a problem message has been received. - Incoming gateway must provide throttle controls to avoid backscatter from excessive "ruf" reporting. This must include, but need not be limited to, any throttling rules provided in the DMARC specification. Sender: Capabilities required for receiving "ruf" reports - Sender must provide an "ruf" destination mailbox. - "ruf" mailbox must be integrated into a security monitoring and alarming environment, so that corrective action begins in a timely manner after an alarm is received. - "ruf" mailbox management must be prepared to cope with high message rates because an infected account might generate a high rate of objectionable messages, which may in turn generate a high rate of "ruf" reports. ---------------------------------------- From: seth=40valimail....@dmarc.ietf.org Sent: 9/23/20 5:50 PM To: IETF DMARC WG <dmarc@ietf.org> Subject: [dmarc-ietf] DMARC bis: revisiting ticket 66 As Chairs, we'd like to push for more discussion of this topic. I've heard some discussion that this distinction belongs in a BCP, not the base spec, but regardless of where text lands (and it certainly shouldn't be normative language) the Chairs strongly believe that having rough consensus on clear definitions is key to progressing the bis effort effectively. We strongly agree with Dave Crocker's position here: https://mailarchive.ietf.org/arch/msg/dmarc/XXE3r5FUozl6LVohv8rTkn5QG4E/ Original thread: https://mailarchive.ietf.org/arch/msg/dmarc/8f3AMoQ_7e3i7zEFTTtK-KnDgzI/ Follow up thread from Todd Herr: https://mailarchive.ietf.org/arch/msg/dmarc/zHti6fc5Rs4SmfMB3jVK_DQnemA/ To repaste the original context for this conversation: Many different entities participate in DMARC, and to each, there is a different definition of what is needed to "implement" or participate in DMARC. Should the spec be clear about the different participants, and what it means for each to participate partially and completely? As a straw man to start conversation (assume this is all wrong): The domain owner:- partially participating: valid record?- complete participation: no part of the domain hierarchy can be spoofed by an unauthenticated sender? The receiver/MTA:- partially participating: validates DMARC?- complete participation: validates DMARC and ARC, and sends aggregate reports? The intermediary (is this different than a receiver?):- partially: validates DMARC?- complete participation: validates DMARC and validates and seals ARC? Seth -- Seth Blank | VP, Standards and New Technologies e: s...@valimail.com p: 415.273.8818 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
