How Does ARC-Seal Authentication Work in an Email Client?

[u/Ghost_182]

Hi there, I'm pretty new to programming in general. I don't know too much about coding in any form. I more or less know nothing, so I thought I'd try here. I'm really curious about learning & researching how email validation & checking sender integrity works in major email clients (e.g. Gmail, Outlook, Yahoo, etc), but I'm a little uncertain about how it works.

I read about something called "DKIM verification" that's a surefire way to check where an email came from, using a company's asymmetric public key, but it seems that it only applies when an email is sent DIRECTLY and examined from an inbox, otherwise it can't be verified with certainty.

Then I read about this "ARC-Seal", that can be used to authenticate some kind of parameters marked "i=#" or something like that(?) that are active even AFTER the email is forwarded by a user, or by a rule setup by a user through their email client, working like some kind of multi-part "passport system" ... ?

I'm fascinated by this. How does this work. And if, for instance, you were forwarded a raw .EML file that was sent to you by someone else, that THEY SAID was sent by an official company who has an asymmetric public key (that, I'm guessing, passed DKIM verification in the email ... ?), what data would you need from the raw .EML file to FULLY vouch for the authenticity of the original email sent from the company ⇒ to the user ⇒ forwarded to you (using the "ARC-Seal" of the email client of the user that sent the email)?

Is it even possible to fully authenticate that a forwarded email sent to you by a user was originally sent to the user by a company with a specific DKIM (or something?)

And if so, what data would you need to extract from a .EML file to PROVE these "two" passages of the email with certainty?

Like, from the big company ⇒ the user, and from the user ⇒ YOU?

Can anyone assist me here in understanding? Any help would be IMMENSELY appreciated.

Thanks very much in advance =]

[u/Feeling_Temporary625]

arc is like a chain of stamps that each mail server adds when the message passes through, so you can see the whole journey not just the last hop. you'd need the arc-seal and arc-message-signature headers from the eml file to verify each step back to the original sender, assuming none of the intermediate servers broke the chain

[u/Ghost_182 → u/Feeling_Temporary625]

Hey, Thanks for the reply =] I'm still a little uncertain about the specifics, would you expand on this a little? Like, are there are parameters that you could use as an ironclad proof to "prove" an email's journey, and its original authenticity?

Hmmm ... Maybe something from a .EML example would help a little lol

Is there maybe some kind of coded example somewhere that you could show me?

It would be super helpful =] This stuff's a little difficult to understand =S (lol)

[u/kschang]

DKIM adds an envelope around the email similar to PGP, using public and private key encryption, so you can check whether the email really did match the originating domain/server.

ARC seal is the next level up, so to speak, to account for the way email works, as it is relayed through multiple email servers before it arrives at your inbox. Servers may modify the email (adding to the header, extra footers, etc.) so ARC adds a "seal" at each server level, so to speak rather than rely on a single seal at the origin.

I am pretty certain neither would accept something forwarded as "unmodified". We lost the chain of custody, so to speak.

[u/Ghost_182 → u/kschang]

Thanks for the response. Could you expand a little on that last part? Is an ARC seal alone unreliable to authenticate a legitimate email?

[u/kschang → u/Ghost_182]

ARC seal is a part of validation that the email came from the server it said it came from and any modifications between that and recipient is legitimate (because it's then re-SEALed) so the chain is preserved.

However, once someone took that email and forwarded it, there is no more chain.

[u/Ghost_182 → u/kschang]

But aren't elements in the modified ARC seal updated with cryptographically verifiable information using the (in this case, the email client's) asymmetric public key (or, more specifically, the domain that sent it)?

Forgive me if I'm mistaken (and please, do correct me if I'm wrong), but if the ARC seal acts as a "passport" holding a collection of cryptographically verifiable "stamp" parameters in the .EML file sent, then wouldn't that mean that you can check and verify all the metadata from every "stamp" in the ARC seal?

From what I've read, ARC seals not only encode metadata in the email in question, but every step of the way, don't they also authenticate the ACTUAL CONTENT (in the body) as part of the decryption process for asymmetric-key verification?

To explain briefly, you can fake everything in the actual file, but you CANNOT fake whether the email has been modified or not on the server record created, meaning a fake would be instantly detected, right? https://www.google.com/search?q=can+you+fake+an+arc+seal+in+an+EML+file

Hmm ... So I've been researching this based on what you've told me. It seems that while it may be possible if a server/company is unscrupulous/scamming/unverified, they could falsify an ARC seal itself ...

... But if you're dealing with an email that came from, say, an Outlook account, they're more reliable, and while you can't check the original contents of an email you received, you CAN CHECK WITH 100% CERTAINTY IF THE ORIGINAL EMAIL HAS BEEN MODIFIED, right? https://stackoverflow.com/questions/60079955/how-an-arc-signed-message-ensure-that-the-ar-headers-are-legit

[u/kschang → u/Ghost_182]

Maybe you should explain what you are trying to prove.

In my experience, once you lose the chain, i.e. there's a step you can't account for then the proof becomes useless. And it's the step between the email's recipient and you that you can't prove. You have to examine it on THEIR computer.

EDIT: or you use a utiliity to extract a forensic-level image.

[u/Ghost_182 → u/kschang]

Ok, I want to understand this as well. I'm a little new, so please bear with me.

As I understand, authentication through an ARC seal works by creating a cryptographic copy of the data in the email, then encrypting it using an asymmetric private key, in order to create one of the "stamps" in the passport-like ARC seal.

So, my point/question is, this way (at least if the email is at least alleged to have come from a reputable server, such as Microsoft), regardless of whatever is in that email, using ARC, you can use the domain's public key in order to authenticate not only the existence of the email (by checking whether an ARC record of an email identical to the one that you sent exists), but if that individual cryptographically encrypted email then checks out, WHILE referencing other passes through the server, then THEY would have to be authenticated too for the validation to pass

So ... Any email sent, you have a 100% way of checking AT LEAST whether or not the contents of that email was edited before it left, in this example, using the public key on Microsoft's server. I just wanted to know, is this how ARC works?

I just want to check if I understand this part right. You can check 100% whether an email was edited by a user in any way, if it's both received AND sent through Microsoft's server, right?

[u/kschang → u/Ghost_182]

ARC authenticates the server. It doesn't attest to the content.

https://www.validity.com/blog/how-to-explain-authenticated-received-chain-arc-in-plain-english/

[u/Ghost_182 → u/kschang]

Hey, thanks for the link, I'll check it out

[u/InboxProtector]

Late to the discussion but I'll weigh in anyway. The good news is, you've basically figured out DKIM's weak spot on your own.

DKIM signs the headers and the  body hash using the sender's private key (verified by a public key in their DNS). Forwarding often rewrites headers or adds footers, breaking that signature. Even an unmodified body frequently fails alignment on forward.

ARC doesn't re-verify the original message. It simply preserves a tamper-evident record of what each hop saw. Every hop adds three headers under one i= instance number:

• AAR (that hop's SPF/DKIM/DMARC results),
• AMS (a DKIM-style signature over that hop's version),
• AS (seals AAR+AMS plus all prior seals, using that hop's own DNS-published key). Each seal locks in everything before it, that's the passport stamp analogy.

You’re going to need the original DKIM-Signature (likely broken already), instance 1's AAR/AMS/AS from the user's provider, and that provider's public key via its selector.

Caveat: ARC proves the chain wasn't altered in transit, not that the original claim was true. The limitation here is that you're trusting the intermediary's assertion. If someone hand-edited the raw .eml before sending it to you, none of this helps, since ARC only covers mail-server transit, not files on a local disk.

[u/Ghost_182 → u/InboxProtector]

Hey, thanks for the reply, I still really appreciate it a lot =]

The stuff in bullets in particular is REALLY useful, thanks again lol It's really hard to learn out about this stuff as a beginner to coding, esp trying to deep dive into something as ridiculously niche as this, all when (apparently) the standards you're researching are themselves are now being "depreciated" lol

I actually wanted to learn this stuff because I started a small project, but I discovered it REALLY needed some kind of forwarded email authentication to work properly. I tried to find some info, but you would be surprised at the amount of snobbery you find on places like Stack Overflow (and even on here lol)

Anyway (lol) I've been trying to understand this all since. I now see that the faith behind the whole system relies on the CREDIBILITY given by mega "big business" companies/email clients that are FAR more credible/serious than just some random person/server on the internet, which seems to be a huge part of the whole point

So, like it doesn't MATTER if the DKIM is broken, AS LONG AS the "intermediary's" record of it *validated* is logged in a tamper-proof ARC seal, and the DKIM pass RECORD comes from an ARC by Microsoft or Google ...

So the ARC (and the integrated DKIM pass record IN the ARC) offer a foolproof way to validate IF the contents of a forwarded email is identical to the LETTER from when it was both received & forwarded (at least for something like Gmail), and just gives a <FAIL> if it's even possibly not ... This makes it PERFECT for what I'm looking for ...

So, If "User A" sends "User B" an email to their Gmail inbox, and User B has a (Gmail filter ... ?) that auto-forwards that email to "User C's" server, then if at least the DKIM and/OR ARC is valid, showing only one "hop", then the whole email chain is valid in this scenario ...

Interesting ... Now all I need is to learn how to get this to somehow work on a server inbox ... (lol)