On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote: > 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.
When msk initially defined the Authentication Results header field, I was a strong proponent of including trace elements, but was in the rough as it comes to the consensus. In retrospect, I think he was correct. AAR can't truly be a trace header (you'd have to include the entire unmodified message with the original DKIM signature to make the DMARC inputs traceable). I'm not sure it's worth doing it half-way. I'm particularly not convinced about source_ip. DMARC reports are organized by 5322.From and when I'm reviewing reports what I care about is where the reporting receiver got it from. That's already covered. I don't see anything that might support trace uses that has to be in the initial specification. It can be added later if there's a need. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
