The Schrödinger Email

# The Schrödinger Email Source: [https://yashgarg.dev/posts/the-schrodinger-email/](https://yashgarg.dev/posts/the-schrodinger-email/) Contents- [1\.The Problem](https://yashgarg.dev/posts/the-schrodinger-email/#the-problem) - [2\.Attempt \#1 \- Outlook Rule](https://yashgarg.dev/posts/the-schrodinger-email/#attempt-1---outlook-rule) - [2\.1\.The First Clue](https://yashgarg.dev/posts/the-schrodinger-email/#the-first-clue) - [2\.2\.The Authentication Stuff](https://yashgarg.dev/posts/the-schrodinger-email/#the-authentication-stuff) - [2\.3\.The Original Email Was Fine](https://yashgarg.dev/posts/the-schrodinger-email/#the-original-email-was-fine) - [3\.Attempt \#2 — Add an @outlook\.com alias](https://yashgarg.dev/posts/the-schrodinger-email/#attempt-2--add-an-outlookcom-alias) - [4\.Attempt \#3 — Cloudflare Email Routing](https://yashgarg.dev/posts/the-schrodinger-email/#attempt-3--cloudflare-email-routing) - [5\.Attempt \#4 — Email Worker](https://yashgarg.dev/posts/the-schrodinger-email/#attempt-4--email-worker) - [6\.The Final Solution](https://yashgarg.dev/posts/the-schrodinger-email/#the-final-solution) How hard can emails be? Or so I thought\. Boy, was I wrong\. This post is basically me fucking around with email infrastructure and finding out the hard way\. ## The Problem As a person with multiple credit cards \(no judging\!\) — I like to track all of them in a single place using apps such as[CRED](https://cred.club/)or[Fold](https://fold.money/)\. They often ask for email access to read the statements and I don’t want to give complete access over my emails\. Hence, I have a separate email where I forward emails via[mail rules](https://support.microsoft.com/en-us/outlook/mail/manage-email-messages-by-using-rules-in-outlook), but the problem is*forwarding*them removes the original sender information i\.e\. the bank here and I want to retain all this information\. In an ideal world, this would’ve just worked and I will not be writing this post :P ## Attempt \#1 \- Outlook Rule I created a rule to*redirect any mail to my Gmail address*for testing purposes\. The rule itself works but there’s no status indication anywhere, so you cannot tell if it failed or not? Bad UX\. Gmail’s[postmaster](https://en.wikipedia.org/wiki/Postmaster_(computing))luckily sends a notification that the redirection failed stating:**“Gmail has detected that this message is likely suspicious due to the very low reputation of the sending domain\.”**This is a hard[SMTP](https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol)rejection and this is where things get interesting\. ### The First Clue The original test email was sent from Gmail to Outlook\. When Outlook received it, the authentication results were perfectly fine: ``` SPF: PASS DKIM: PASS DMARC: PASS ``` Why was Gmail rejecting it when Outlook tried to send it ahead? The important detail is that**email forwarding creates another SMTP delivery**\. So, the flow essentially is: The authentication that happened on the first hop doesn’t automatically mean the second hop will be accepted\. ### **The Authentication Stuff** So what do[SPF](https://en.wikipedia.org/wiki/Sender_Policy_Framework),[DKIM](https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail)and[DMARC](https://en.wikipedia.org/wiki/DMARC)actually have to do with this? These are standard email authentication protocols designed to verify where an email came from and help prevent spoofing and abuse\. #### Sender Policy Framework \(SPF\) SPF is basically: > **Is this server allowed to send mail for this domain?** If`example\.com`sends an email through its own mail servers, SPF can verify that those servers are authorized\. But forwarding changes the server that delivers the message\. The original message might have come from Google’s infrastructure: After Outlook redirects it: Gmail is now receiving the message from Microsoft’s infrastructure rather than the original sender’s infrastructure\. This can make SPF complicated\. #### DomainKeys Identified Mail \(DKIM\) DKIM works differently\. The original sender can cryptographically sign the message\. That signature can survive forwarding, provided the forwarding system doesn’t modify the signed parts of the message\. This is one reason DKIM is particularly important for forwarded mail\. #### **Domain\-based Message Authentication, Reporting and Conformance \(DMARC\)** DMARC ties the authentication results back to the domain in the visible`From:`address\. The policy is published as a DNS TXT record under`\_dmarc`: ``` _dmarc.example.com TXT "v=DMARC1; p=reject" ``` Here,`p=reject`tells receiving mail servers to reject messages that fail the domain’s DMARC policy\. Forwarding can therefore create a mismatch between: - who originally sent the message, - who is now transmitting it, - and which domain the message claims to be from\. There are mechanisms such as[**ARC**](https://en.wikipedia.org/wiki/Authenticated_Received_Chain)that can preserve authentication information across forwarding hops, but the receiving mail server still gets to make its own delivery decision\. And Gmail doesn’t only look at SPF/DKIM/DMARC\. It also has spam and reputation systems to prevent abuse\. ### The Original Email Was Fine Looking at the headers of the test message, Outlook had successfully authenticated the original Gmail message: ``` spf=pass dkim=pass dmarc=pass ``` So the first hop was fine\. The failure happened when Outlook’s forwarding engine attempted the second hop\. The headers gave me another clue: ``` Resent-From: <[email protected]> auto-submitted: auto-generated x-ms-exchange-generated-message-source: Mailbox Rules Agent ``` In other words, this wasn’t me manually sending another email\.**Outlook’s Mailbox Rules Agent was generating the redirected delivery\.** I found out that this exact issue was supposed to be fixed in 2024?? Microsoft has[documented](https://support.microsoft.com/en-US/Support/known-issues/fixes-or-workarounds-for-recent-issues-on-outlook-com)the issue involving country\-domain addresses and Gmail rejecting messages with essentially this same error\. The documented workaround was to add an`@outlook\.com`alias\. So I added one as`abc@outlook\.com`to the same Microsoft account\. I also switched`@outlook\.com`address as the primary alias instead of`@outlook\.in`\. Then I ran the exact same redirect test again\.**It still failed**as the headers for the redirected message still contained: ``` Resent-From: <[email protected]> x-ms-exchange-generated-message-source: Mailbox Rules Agent ``` The new`@outlook\.com`alias hadn’t changed the identity used by the automatic redirect\. So, the alias workaround wasn’t useful for this particular redirect path\. ## Attempt \#3 — Cloudflare Email Routing Okay\. If Outlook doesn’t want to deliver directly to Gmail, maybe I can put another[mail routing](https://www.cloudflare.com/products/email-routing/)layer in between\. I have routing rules set up such as`abc@yashgarg\.dev`to forward emails to Gmail\. The idea was to let Cloudflare handle the forwarding instead of having Outlook directly deliver the redirected message to Gmail\. Unfortunately, that didn’t solve the problem either\. Adding another forwarding layer doesn’t inherently solve the authentication and reputation problems that can happen when mail crosses multiple SMTP hops\. At this point my email architecture was starting to look like this: Needless to say, this didn’t work either\. ## Attempt \#4 — Email Worker I was thinking, instead of redirecting directly to my Gmail address, what if I use`abc@yashgarg\.dev`and route it through an[Email Worker](https://developers.cloudflare.com/email-service/api/route-emails/email-handler/), then forward the message myself? Something as simple as: ``` export default { async email(message, env, ctx) { console.log("From:", message.from); console.log("To:", message.to); await message.forward("[email protected]"); }, }; ``` The idea was that I’d get the message into my Worker and then have full control over what happened to it\. But I didn’t realize that Cloudflare performs its authentication checks**before**the message reaches the Worker\. If the inbound email fails those checks, it’s rejected before my code ever gets a chance to run\. > Cloudflare performs SPF, DKIM, DMARC, and ARC checks on incoming mail\. Messages that fail authentication according to the sender’s DMARC policy are rejected\. So, there goes my last hope\. ## The Final Solution I did the thing I really didn’t want to do\. I moved all my**banking\-related emails**from Outlook to my Gmail address manually\. Not exactly the elegant solution I was looking for, but after all that, it was simply easier than fighting email infrastructure\. I spent more time than I would’ve liked on this but nonetheless, it’s done\. *Until next time\! 👋*