4

I'm trying to wrap my head around the ARC policy and from my understanding, an email arriving with an ARC headers means that the previous Authentication-Results headers have been validated by the sender. Or, from Wikipedia:

Authenticated Received Chain (ARC) is an email authentication system designed to allow an intermediate mail server like a mailing list or forwarding service to sign an email's original authentication results. This allows a receiving service to validate an email when the email's SPF and DKIM records are rendered invalid by an intermediate server's processing.

So for instance, as an intermediate, I receive an email from someone, that is signed with DKIM. I validate the SPF, DKIM and DMARC, set the AR headers accordingly, and wrap these with ARC (AAR/AS/AMS). Then, I change the subject to add "[FWD] - {subject}", and send it from MY server, with a return path being the one I got from the client, one that I DON'T have the SPF policy to send.

The receiving party, if it handles ARC, will see that the message was signed and that the original SPF/DKIM/DMARC was respected, and my return path, which is now wrong (because my server IP has not the right to send an email from the sender's domain) is still accepted because of the ARC. The DKIM failing now because of the subject change is also accepted, because of the ARC.

If I'm right about my understanding, so far, this is good.

BUT

How can the receiving party define that I am legit?

Based on this specification, I can fully craft a fake email, saying that initially, SPF/DKIM/DMARC was respected and wrap the whole with ARC. Then I can send this email by using a (fake) return path, and make-believe that the email is valid regardless of its failure because I have signed with ARC.

I don't think (I don't HOPE) that there is a list of "allowed" registrars that can be trusted when using ARC and, as an intermediate, I need to register here, because of this break the very fabric of the Internet. (yup).

So my question is the following:

How can a receiving party consider that the sender, that signed an email with ARC, is legit and can be trusted - or not?

Sorry for the long message, here's a potato:

Cyril N.
  • 38,875
  • 36
  • 142
  • 243

2 Answers2

3

How can a receiving party consider that the sender, that signed an email with ARC, is legit and can be trusted - or not?

You're right, they can't. ARC is about extending trust, so an ARC seal cannot on its own be used as a proof of DKIM passing on the previous relay. It's better than nothing, and it helps tremendously for trusted relays like those run by Google, but it doesn't really help for an unknown relay like some random mailing list server.

Unless you're involved in generating and maintaining reputation lists (which means you're probably involved in the anti-spam business), you can't automate this since ARC seals can be forged. However, you can use it as a tool in manual investigations. Theoretically, you can also extend trust to big services like Google and Yahoo.

Adam Katz
  • 14,455
  • 5
  • 68
  • 83
  • 2
    "extending trust" bothers me - a lot - because it means having a list of allowed parties that breaks the core of Internet. There shouldn't be a favorite. As far as I understand, ARC doesn't help to resolve the trust issue, it just adds more complexity and hopes to rely on trusted services (aka big players). – Cyril N. Feb 12 '20 at 10:28
  • 1
    Yes, this _should_ bother you. There is unfortunately no better solution since a relay in the middle can change pretty much anything from the original message. If this were more about preserving cryptographic signatures, it would still be vulnerable to a replay attack (and yes, DKIM sigs contain the timestamp). _ARC **does** help resolve the trust issue_, just not _well_. You're absolutely right, automating it only works for the big players, but it can still help for endemic DMARC-failing issues (which can be manually whitelisted) and for forensic analysis. – Adam Katz Feb 12 '20 at 16:08
  • 2
    Ok so all in all, this, plus the fact that ARC must be implemented at all the receivers to be able to forward an email with invalid SPF/DKIM (as long as they were validated by ARC on the n-1 level), plus the fact that it only means its useful for big players means there is no real interest for this. At least that's the conclusion so far until someone proves me of the contrary. Thank you :) – Cyril N. Feb 13 '20 at 11:02
0

I have been pondering the same question, and it seems there is a second element to this in Trusted ARC Domains that some mail providers are now enabling (Microsoft 365).

With these you define the domains that can ARC sign messages that you trust so that any intermediate services you use that can modify your messages or cause SPF to fail can be allowed despite DMARC failing.

This helps it make sense, because you are only trusting intermediates you are aware of and not just anyone that can ARC sign.

D C
  • 1
  • 1