I'm reading up on #ARC, the stuff that I thought was going to solve all my mailinglist and #email forwarding problems with breaking #SPF, #DKIM and #DMARC. But it's not nearly as nice as I had hoped.
I'm reading up on #ARC
, the stuff that I thought was going to solve all my mailinglist and #email
forwarding problems with breaking #SPF
But it's not nearly as nice as I had hoped.https://www.validity.com/blog/how-to-explain-authenticated-received-chain-arc-in-plain-english/
It boils down to someone offering you an email that, according to DKIM and DMARC has been tampered with and should be rejected, assuring you he had to change a few things that broke security, but that it was all in good faith.And you having to trust him...
You've made it this far, nice. I have to warn you that there's a lot more, some of it technical talk about email, some of it about trust.
Would you trust an ARC seal, on a message that doesn't check out, because the one offering it says it's OK?
If I recognise that seal as one of my own servers, or a colleague I trust: I would. If I recognise it as my ISP or one of my favourite mailing lists, I probably would, depending on the context. But a random -possible- spammer, phisher or "state actor"?
How do I know who's who? My mailservers get hammered by hundreds of different machines every day, how do I know if I can trust them if they offer me a message with smoke coming out?
That's basically the problem with ARC: who do I trust?Technical background
Now, some technical stuff to see what we're dealing with. Say, we have two small companies, one does plumbing, the other runs an office and needs some plumbing done. They both have their private email addresses; the plumber has his own domain at his ISP, the office uses GMail to forward mail to theirs.
Now the plumber mails an offer to the office, through his ISP, who adds a DKIM signature and has configured a strict DMARC policy for the domain.
GMail accepts the message, but to successfully forward it to the office's mailserver, they can't use the original envelope-from, because SPF says they're not on the list for that domain. So they use #SRS
to circumvent that: they "wrap" the original "mail from:" address, firstname.lastname@example.org, in one of their own, like:
That satisfies SPF (somewhat), because their servers are allowed to send from addresses within the @google.com domain.
But it breaks alignment for both SPF and DKIM, because now the envelope-from doesn't match the from-header anymore. Those are two indicators that something fishy could be going on.https://mxtoolbox.com/dmarc/spf/spf-alignment
The DKIM signature itself is still valid though, so DMARC is fine and the office's ISP accepts the mail.What if
But what if Google were to change stuff in the actual message? That would break the signature. Like what mailinglist servers do: they change the body, for example by adding an unsubscribe-URL to it. That's legit, but it does break the DKIM signature, causing DMARC to reject the message.
Let's say, they want to add a link to one of their advertisers ("you need a plumber? pick me, pick me!") as an "added service to both parties".
The plumber's DMARC policy would tell the office's ISP to reject that message: exactly what should happen to forged/manipulated messages, that's what DKIM and DMARC are for.
But then there's ARC...
Google adds an ARC seal to the message that basically says "although DMARC says this message stinks to high heaven, we guarantee that it's ok; we had to change a few things, all with good intents. Trust us, we're Google"
BAM! "Approved by Google".Would you trust that seal?
I think most parties would. If you're in the email business, you can't just go about and refuse email from Google, that would basically excommunicate you. You'd be out of business in a few weeks, but more on that later.
But would you trust others?
Would you trust some unknown server in a country with a dubious reputation when it comes to cybercrime and spam, if it tried to deliver a message that DMARC warns you has been tampered with?
Would you trust your government's seal..?
Would you trust those ARC seals enough to override DMARC's verdict, just because that server says it's ok? If so, why? Because they were tech savvy enough to add it?
Before you accept an ARC seal, you should know who's behind it, and that you trust them enough to ignore the alarm bells. DMARC is there for a reason: if every forwarding/relaying system can override it with its own ARC seal, what's the point of having it?
Winston: "Charles, why have we got that cage?" Lock, Stock and 2 Smoking Barrels - Cage scene
Charles: "Er, security?"
Winston: "That's right, that's right: security. So what's the point in having it, if we're not gonna fucking use it?"
So, by the time the world starts to be really careful with whose seals they're trusting, the big ones will have theirs on every allow-list on every system in the world. They can offer mailinglists and email forwarding that "just works", while at the same time being able to manipulate the email flow and getting away with breaking signatures.
The smaller shops that run legitimate mailsystems but can't get the whole world to trust their seal, are going to see some of their forwarded messages being rejected. For every rejected message they should contact the receiver and convince them to add their ARC seal to their "trusted ARC sealer" list, as Microsoft calls it:https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/use-arc-exceptions-to-mark-trusted-arc-senders
So their customers, when confronted with email delivery problems, will hear the same advice over and over again: just use Google or Microsoft, that works.
As a small mailadmin from the Light Side, I don't think I like ARC very much.