Apple 'Hide My Email' vulnerability reveals peoples' real email addresses

I am not using Yahoo. Idk. I tested it multiple times to make sure I am not making up drama. I would post screenshots but I can't be bothered to edit them for privacy right now.

The disclosure mail has this in source (from OMA perspective):

X-Icloud-Hme: p=HME@icloud.com; d=; f=REAL@icloud.com; r=to; e=OMA@OMA.COM; s=OMA@OMA.COM

I know little about mail, but I think it's pretty evident there is a fuck-up, because the HME and real mail address should never be found next to each other anywhere. I kinda suspect this is meant to be forwarded to the sent box like this, but got forwarded to OMA or something.

Again, I checked multiple times, the iOS mail client shows the HME in from-field. It could be, this is "just" a bug in the iOS mail client. I presume the OP found something generally wrong with HME. But only the abyss I see here makes me absolutely not trust Apple with this anymore.

Did you do 2. and to the same OMA? The thing is, initiated from from iOS client, the ping pong goes fine-ish (despite disclosing HME usage) first time, but then "reusing" the alias, exchange initiated from same OMA is the important differentiation, apparently. There must be some issue with header rewriting, threading, idk... I presume OMA structures the header differently and does not trigger HME response as Apple expects. Or Apple already got a HME translation route for the OMA, and can't make a new one, fails to reuse the old one. Some mail servers may cut some X-whatever meta data. I mean, "X-Mailer: iPhone Mail" is cringe as fuck bloat...

right.

That Received header is inserted by smtp.gmail.com (Google), not Apple.

I've run decently sized SMTP servers in the course of my career. I have some idea how SMTP works. In my testing, Apple's HME SMTP servers do NOT sanitize the headers at all.

If you setup HME to forward to a non-iCloud address, you absolutely risk leaking information if you reply to an HME email. For example, in my testing, the replies disclosed the DMARC policy I have on my domain when Apple's SMTP servers themselves added that header:

    X-DMARC-Info: pass=pass; dmarc-policy=reject; s=r1; d=r1; pdomain=mydomain.org

(Where "mydomain.org" is my actual personal domain from which I replied when I had HME setup to forward to js2@mydomain.org.)

So in that sense, I'm agreeing with you.

But, that's not the claim that alexpc201 made. To wit: "sends a response email (from the real address) with the rejected email message"

Sure, that's possible, but I doubt it and I was also unable to trigger such behavior. An oversized message is bounced directly by the receiving SMTP server with:

    message size 67539976 exceeds size limit 28311552 of
    server mx01.mail.icloud.com[17.57.154.33]

I tried various approaches. They all bounce at the edge:

    Reporting-MTA: dns; mailfout.phl.internal
    X-Postfix-Queue-ID: 13B6AEC00E7
    X-Postfix-Sender: rfc822; elided@pobox.com
    Arrival-Date: Thu,  2 Jul 2026 18:28:38 -0400 (EDT)

    Final-Recipient: rfc822; word-word.0x@icloud.com
    Original-Recipient: rfc822;word-word.0x@icloud.com
    Action: failed
    Status: 5.0.0
    Remote-MTA: dns; mx02.mail.icloud.com
    Diagnostic-Code: smtp; 550 We are unable to send your email as one or more of its attachments may be corrupted or may contain malicious content.

So the theory now has to be that possible to sneak something past the edge SMTP server, past the point where the system rewrites the HME address, then bouncing, and in sending the bounce, failing to properly rewrite something on the way back out, thus disclosing the real address. I remain skeptical that's what's happening.

Elsewhere in this thread someone theorized that the leak doesn't involve SMTP at all, but maybe some other service Apple operates.

---

Since doing this testing, I updated my HME setting to forward to my real iCloud.com address instead of my personal domain. If I then reply on icloud.com, nothing that I can see is leaked.

So basically, the HME SMTP servers are:

1. Rewriting the From and To address in a reply.

2. Are not sanitizing message headers.

3. When replying from a non-icloud.com domain, are actually inserting new headers which leak information such as your domain if you have a DMARC policy setup.

Eeek! So be careful when replying to an HME email! But even though the blog post is vague, I believe the claim is that no reply from the HME address is necessary.

> Try figuring out the message size that the forwarding edge (icloud.com) accepts, but the receiver (the mailbox server) does not.

Is this a theory or did you test this yourself?

Anything even 1 byte less than that rejected at the edge passes through. And there's not a chain of SMTP servers either. It goes through a single SMTP server into my iCloud mailbox.

If you think this is the flaw, you're welcome to prove it. I'm skeptical and not spending more time on it.

Edit: this is with forwarding to an icloud.com address. If forwarding to a private domain and that domain's SMTP servers have more restrictive size limits, then yes, that bounce could reveal the real address. Don't use a non-icloud.com real address with HME. But the original (vague) description of the problem says nothing about whether the real address matters. In any case, I have no way to test that scenario.