I can speak from first-hand study of ARC: 1) When present, it is very useful for analyzing complex flows. When it is not present, I fallback to Results-SPF and Authentication-Results fields. 2) ARC Sets are inserted by some message originators. In general ARC Sets are used differently by different implementers. 3) Therefore, ARC has to be interpreted on a case-by-case basis.
Outlook.Com is the source of the highest volume of ARC data, so it is the most important case study, and the source of several anomalies. Documentation - General: - Authentication-Results and Results-SPF are inserted upon initial entry to the Outlook.com environment, and are not purged. - ARC Sets are consistently written immediately prior to any exit from the Outlook.Com environment. - The Recipient domain in an ARC Set is based on the message state when the ARC set is created, after any forwarding, not based on the message state when the Authentication Results were collected before any forwarding. I wish it was the original recipient instead. - Messages can flow in and out of Outlook.Com, so the documentation is very thorough. Documentation - Initial entry into the Outlook.com environment: Outlook.Com has two very different use cases, which produce very different documention. Case 1: (Interpreted to be a login connection with Outlook.Com acting as the Mail Store Server.) - The first Received field reports a loopback connection from an Outlook.com server to itself over an IPv6 private IP using MAPI - The ARC-Authentication-Results record inappropriately indicates spf=pass, dkim=pass, and dmarc=pass, with no parameters to any of these results, even though no DKIM signature is present in the message. A DKIM signature is usually added later, but not always. Case 2: (Interpreted to be a connection without login credentials with Outlook.Com is acting as an Email Service Provider for messages originated by the remote server.) - A Received field, often the first, indicates a connection from a remote server to Outlook.Com over unauthenticated SMTP. - The ARC-Authentication-Results reports correct results for SPF, DKIM, and DMARC, including accurate parameters. Failure results are documented but do not inhibit the message from being processed. Additional issues with Case 2: - Failure results do not inhibit Outlook.Com from adding a client's DKIM signature to the message, even if the client appears to have been impersonated. - When Outlook.Com relays messages to a client's chosen outbound gateway service, at least some services pay no attention to the failed ARC-Authentication-Results, allowing the message to proceed. - One well-known outbound gateway service adds a client's signature, but makes other changes that break prior signatures. The message is returned to Outlook.Com for delivery, at which point Outlook.Com notices and documents that the ARC chain is no longer valid. This means that ARC will not work for mailing list traffic generated by clients of that service. Generalizations for my interpretation of ARC: - For SPF, I only use ARC data when it contains a Source IP and a Mail From domain, and the Source IP can be matched to a Received field. As a result, the factually unsupported ARC data in Case 1 is ignored, and the accurate ARC data in Case 2 is used. IPREV results sometimes provide an alternative way to obtain a Source IP and link the ARC Set to a Received field. - For DKIM, I only use ARC data that asserts a DKIM result which includes a DKIM domain, a DKIM signature can be found for that domain, and the signature is in the Trace data below the ARC Set which references it. The factually unsupported ARC data in Case 1 is ignored because the DKIM signature, if any, appears above the initial ARC Set, not below it. - When sufficient prior-state data is available, I can perform my own SPF check on the pre-forwarding state of a message. - ARC gives visibility to the existence of credentialing upgrade attacks, at least for Outlook.Com. Since outbound gateway services often add DKIM Signatures, and are included in the client's SPF record, the connection between client and vendor becomes critical to my risk assessment. If that connection is not authenticated by some method, I could become the target of a fully-authenticated but fraudulent impersonation of that client. I am pursuing various strategies to know whether each of the major outbound gateway services have secure connections or not. Doug Foster On Thu, Oct 24, 2024 at 12:59 AM Steven M Jones <[email protected]> wrote: > On 10/23/24 4:35 PM, Murray S. Kucherawy wrote: > > On Wed, Oct 23, 2024 at 11:55 AM Jim Fenton <[email protected]> > wrote: > >> It hardly seems like the agreement was tacit when it’s quite explicit in >> the WG charter. >> > > The charter is explicit (twice, by my count) that addressing the problems > with indirect mail flows is in scope for the working group. What it > doesn't make clear (hence "tacit") is the understanding, at least at the > time of chartering, that it's not only in scope, it's required. > > "Tacit" is tricky, and we tend to avoid that when writing documents for a > reason. > > The way I read Track 1 of the charter, the WG was to "reduc[e] or > eliminat[e]" effects on indirect mail flows, but it doesn't state that the > DMARCbis spec itself has to be what does it. And I don't see where in Track > 2, "Reviewing and improving the base DMARC spec," that it says DMARCbis > revisions themselves must remediate impacts on indirect mail flows. > > But then those "tacit expectations" come back to haunt us. However... > > ARC was published, and support has been baked into Mailman and Sympa for a > good while now. I think the stumbling block in citing it in a response to > this point, is that RFC8617 is Experimental. Given the timing now, leaving > ARC in Experimental status - and not actually running it as an experiment - > may have left us between a rock and a hard place. This is reflected in > comments from Ale V and John L on the GitHub thread. > > The problem with DKIM2 (another point from the GitHub thread) is that it > would be a forward reference. I know a great deal of thought has gone into > the "design outline," but I don't think there's a specification so that's > at least one step behind ARC in terms of this thread, and I imagine it > doesn't have experimental data either. > > > DMARCbis appears to address this via the text of Section 7.4, which in > essence tells senders to ... The completion of WGLC with no further > discussion suggests that the WG believes that this is satisfactory. That's > fine if so, but I claim it falls short of what I imagine was anticipated, > that being a protocol solution, and I'm suggesting we should say something > in the document that reconciles or explains this. > > There is a problem inherent in trying to address implicit, undocumented > expectations that weren't written into the charter. I don't say that to be > a jerk but to ask, How are we supposed to know where the bar is if it was > never written down? You can talk yourself into or out of anything depending > on what you imagine those expectations were, or have become since. > > And whatever deficiencies people see in ARC, it is a protocol-based > response. > > > To reiterate something I said earlier: I'm not obstructing the progress of > the document even though I disagree with a couple of the decisions made, > but I think those decisions -- especially this one -- need to be explained > or face scrutiny and delay during Last Call and/or IESG Evaluation. > > Anticipating objections so we can address them in advance is not > obstructive, but constructive. Thank you for taking the time to carefully > consider the situation and kick us in the collective behind. > > > --S. > > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
