DKIM2 is meant to support forwarding and DMARC from the start. One area where we haven't looked deeply is at the interaction between forwarding and DMARC with DKIM2. We have been generally assuming that DKIM2 will expand passing scenarios for cases where DKIM and SPF would fail hence fail DMARC. But DMARC is also a way to express what senders think about failing messages, and forwarders will likely also want a say in what happens to a message that fails validation. Another area we should clarify is application of DMARC policies to DKIM2 messages including those that are forwarded. Lastly there is a set of proposed anti-abuse detection mechanisms in DKIM2, and this suggests using DMARC to define how to enforce as DMARC. This builds upon earlier discussions with Allen Robinson , Richard Clayton and Bron Gondwona.
Forwarder Intent DKIM2 requires From header alignment at the origination of the message. It also requires the forwarders in distinct SMTP ADministrative Management Domains (ADMDs) to DKIM2 sign the message and the signing domain must be in alignment with the previous signature's "rf=" address. This lets us say that the forwarder domain identity is well identified in the DMARC sense, and may be useful as an input to reputation systems. If DKIM2 signature validation fails or the RCPT TO recipient check fails, we propose that the forwarder domain be able to publish a policy that specifies the forwarder's intent on what enforcement to apply. By default the receiver uses the same DMARC "p=" policy that's based on the origination "From" header. However the forwarder can specify a distinct forwarder policy with the tag "fp=" that uses the same policy values as "p=". This may be helpful when a domain wants to specify a less strict forwarding policy than for those that it originated. Upon DMARC DKIM2 validation failure, a receiver determines which policies to apply. The receiver gathers the originator DMARC policy and any forwarder policies. It applies the strictest policy found subject to local policy. This also calls for DMARC reporting to be generated for forwarders. By default the "rua=" and "ruf=" tags specify where the forwarder reports may go. However forwarders may specify a different location "frua=" and "fruf=" to distinguish forwarding traffic from origination traffic in the reports. Application of DMARC Policies to DKIM2 messages Above we specified that a message's DKIM2 passing From header aligned domain is considered the originator domain. Message algebra introduces ambiguity to this in that the From header and body may have been rewritten by a forwarder, and DKIM2 message algebra provides a mechanism to reverse those forwarder transforms. This calls for any version of the message that passes DKIM2 validation with an aligned From header to be considered an originator for the process of applying a DMARC policy typically for reporting in the passing case. If there are more than one From header seen in the version of the message, and the latest version passes, that version is considered the message "owner" and DMARC validation is considered to pass. Earlier versions need not pass for DMARC to pass. If none pass, then it treats all failing From domains as the originator for the purpose of finding which DMARC policy to apply. The receiver picks the strictest policy for DMARC enforcement subject to local policy. If a reject or quarantine policy is to be applied to a message, the message MUST NOT be forwarded. With quarantine policy for forwarded messages, it is recommended to elevate that to reject so that the sender has feedback. Forwarder DKIM2 Anti-abuse Mechanisms The header draft proposes two anti-abuse mechanisms: "m=" never exploded in section 1 <https://datatracker.ietf.org/doc/html/draft-gondwana-dkim2-header-00#name-the-dkim2-header> and "nomodify" i.e. never modified policies in section 1.4 <https://datatracker.ietf.org/doc/html/draft-gondwana-dkim2-header-00#name-registry-of-values-for-m> that an originator can express in the DKIM2 signature to forwarders to support and can be enforced by receivers to help protect the mail against abuse. Many commercial or transactional senders may wish to declare that their traffic must not be duplicated i.e. "exploded" in mailing list expansion. Forwarders may wish to propagate the "m=" policy of the originator to indicate support for the never explode policy. Expansion is fairly localized in the mail handling stack, meaning feasible to implement. Receivers can then check if there are duplicates and enforce if duplicates are found. Enforcements SHOULD follow the sender's or forwarders' DMARC policy subject to local policy as mentioned above. The never modify policy is potentially harder to implement, and the gain smaller or non-existent IMO. The problem I see is that there are many places in the mail handling stack that modify the message in large and small ways such as re-encode the MIME part or adding a trace header which is potentially problematic for normal delivery processing. I also don't see how this helps senders as DKIM2 already provides strong mechanisms for detecting tampering by forwarders. -Wei
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
