The current spec defines an arc authres method (https://tools.ietf.org/html/ draft-ietf-dmarc-arc-protocol-03#section-8.1).
We believe there should also be registered ptypes and properties, that should be stamped (but are not required, as they won't always be available). As long as AR stamping happens at the end of chain validation, when an ARC set gets created this stamp will be included in the AAR, and AAR construction can be clean with no additional language or requirements necessary in the spec. What follows below is not sacred, we're just trying to start the conversation. Based upon previous threads (specifically, Brandon's reporting local_policy thread from May 4th PST) surrounding the AAR and data the WG thought would be valuable for final receivers and DMARC reports, it looks like stamping header.b for each dkim signature on the message and smtp.client-id for the ip address of the originating mail server (if available) would provide nearly everything asked for with minimal implementation overhead (and no change to spec except for the IANA registration, and an addition for RECOMMENDED stamping if warranted). To dig in to the reasoning behind these two properties: 1) header.b At the end of an ARC chain, there might be many DKIM signatures on the message, nearly all of which could be broken on receipt. Additionally, since there have been multiple hops, it is possible to have several broken DKIM signatures with the same header.d value that are representative of different services at different hops. If each hop stamps the https://tools.ietf.org/html/rfc6008 header.b of every dkim key on the message, then it becomes super clear which keys were added when, and which dkim pass/fail statuses correspond to which keys so it can be determined when any individual signature broke. This is extremely useful as a reporter to help identify broken services at any stage of DMARC enforcement, and is probably useful for final receivers reviewing the chain to determine final message disposition; without this information all the DKIM-Signatures on a message that do not validate and share the same header.d are indistinguishable. This stamp removes this ambiguity and adds reporting and trace value. 2) smtp.client-id The goal here is to track the originating source_ip for DMARC categorization and reporting. Otherwise, all ARC messages will have a DMARC report source_ip of the last forwarder, not the originating service. This will be exceptionally confusing to consumers of DMARC reports. We know that including an IP address in Authentication-Results has been persona-non-grata in the past, as authentication results are supposed to encapsulate the results of an authentication check, not information that could be used to re-run the authentication downstream. However, we believe that the client-id is vital trace information for ARC and DMARC, is useful for categorizing senders within a DMARC report, and is valuable at p=none, p=quarantine, and p=reject, and as such makes sense within and contained to the ARC stamp. Ultimately, if this stamp is wrong for the AR, the client-id could be added directly in the AAR. The AR stamp is cleaner because it leaves the AAR generation and spec untouched. We know there will be disagreement about what to stamp, and welcome discussion on what's best to track within an AR header as arc status. I'm happy to suggest language once there's rough consensus in the group. Seth -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols s...@valimail.com +1-415-894-2724 <415-894-2724>
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
