On Tuesday, May 30, 2017 01:34:50 PM Seth Blank wrote: > On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman <[email protected]> > > wrote: > > 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 don't want the AR payload to be about trace information; I want to make > sure it encapsulates the proper authentication results and statuses. So > that a DMARC report after an ARC message has been processed has the > appropriate information that's valuable to a report consumer. > > - At p=none this means understanding the originating sender and if any > originating authentication mechanisms were broken. This means passing > through an smtp.client_id and the header.b's. > > - At p=quarantine|reject, for a failing message that passes arc, I think > the status quo works (although having header.b here to understand which > keys signed the message when could be useful). > > - At p=quarantine|reject, for a failing message that fails arc, it's useful > to know where/why the message failed. Again, header.b's shine light on this > and can make the DMARC report useful for determining/fixing a broken > originating sender or intermediary. > > Passing this information through (and to me it's not trace if it's there > for a user to interact with in a DMARC report - although there's definitely > additional trace value, that's not the primary purpose here) is extremely > valuable for the report consumer. > > My concern is putting it anywhere other than the AR/AAR could creative > feature/spec creep, and waiting to see what happens and writing a spec for > stamping later just leaves room open for complaints that, even after ARC, > DMARC is still broken with respect to reporting on mailing list and > forwarders. > > > 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'm not certain I'm sold either. Especially because many implementations > won't even have access to the IP. For instance, Mailman3 does not have > access to the source_ip of the smtp connection (that data doesn't come over > LMTP), so no mailman software would ever be able to stamp this. > > I think the source_ip is valuable to provide, especially for a final > consumer of a report, but 1) it's not always available, 2) it doesn't seem > perfect to put into an AR header. > > Thoughts? > > > 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. > > I think stamping header.b has real value as outlined above. > > I think smtp.client_id also has value, but definitely see the arguments > from both sides.
So header.b only gives an explicit way to link an (A)AR header field with a signature, so there's no need to guess what's related within the message. Now that I've read your rationale and gone and read RFC 6008 again, I agree that makes sense to include in AAR. It might even be a good idea to make it mandatory since there is (for the purposes of IETF standardization) no installed base to worry about. Source IP, I still this is only for trace purposes and should be out of scope (I have a hard time justifying why it would be out of scope for SPF (which is what the working group and later IETF consensus was) and in scope here. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
