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. Seth > Scott K > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols [email protected] +1-415-894-2724 <415-894-2724>
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
