Not for me. I don’t even remember when (or since how many years ago) I turned off Protect My Email and turned on both Hide IP Address and Block All Remote Content. I still have these toggles as they are, despite the fact that I use beta releases as and when they’re released (currently still on iOS 26.x).
I also just tried this as well, sending an email from a Migadu-based account to one at both Gmail and MXRoute using Mail.app under macOS 15.7.7. Neither included any private IP address info I could find in either headers or raw source. That would be a good leak to know about and as sibling comment said saagarjha definitely knows their stuff, so any tips to replicate would be appreciated.
Received: from smtpclient.apple (ptr. [ip])
by smtp.gmail.com with ESMTPSA id ...
for <...>
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Thu, 02 Jul 2026 ..:..:.. -0700 (PDT)
For me that IP belongs to apple, when using the iOS mail client. I presume Apple forces third party apps to use their API and then stuff like this happens. Guess that's also on google, not mitigating that issue, tho.
Have you tried a VPN? I wonder, if Apple manages to expose IP despite a VPN. They had issues with stuff like that before.
Same, I remember it being in the headers long ago but don't see it now. macOS Tahoe, Mail.app client, iCloud email sending to itself or to my Gmail, both set up in default ways, IPv6 disabled
> The reason why my IP address is visible is because Apple Mail sends emails with SMTP.
Unless you use a proxy, your IP address is visible to an SMTP server, just like it's visible to an HTTP server when you use a web browser. This is not specific to Apple Mail or to Gmail.
Yeah but I think Gmail seems to actually just keep that header rather than nuking it. To be fair I don't entirely know what I would do to fix it since (like the post) this seems like there aren't many good options here.
I clearly remember many years ago that this wasn’t the case with Gmail, when looking for the source IP address in a case involving harassment of a person. I could only get Gmail’s own IP address in the headers from the multiple emails I examined at that time.
Nevertheless, as js2 said in another comment, it’s your mail provider (in this case Gmail) deciding whether to include the sender’s IP address or not.
Fetching any email content is always worse than blocking it, because the typical threshold for spam is "is this inbox monitored". If that is true, then blast it with spam. And fetching anything ever proves that the inbox is monitored.
At least in Gmail, downloading content (e.g. images) is disabled by default for suspicious emails. There is no way for the sender to know if it’s monitored unless this is disabled by explicit user action.
This freaked me out the first time I used Mail. It rendered a PDF about buying bitcoin on PayPal (I don't have PayPal). Looked at the same email in Gmail and Thunderbird, it's just a PDF attachment, no message, and the sender was different. No wonder people are falling for those scams, Mail makes it easy for them.
Now if only I had a better client on my phone (never buying an iPhone again)
I am starting to think all these "privacy" features merely exist as excuse for getting people to hand off their mails to Apple. Clearly the all do not deliver on the intended functionality, but the proxy/relay routing happens to some extent anyway. How convenient. If you were a company promising its users all the privacy, but secretly not giving a fuck beyond collecting user traffic and meta data, wouldn't you expect the state of things to look exactly like that? I mean, how could you explain this any other way, considering the size of Apple and the relative ease of developing such features reliably? Apple is hardly breaking ground here.
I guess the vulnerability should work as follows (I haven't tried it), you send an email with a very large attachment to a "hide my email" address, the server that receives it (private.icloud.com) forwards it to the email server registered in iCloud which, being the very large attachment, sends a response email (from the real address) with the rejected email message. It's the first thing I would try.
Apple rewrites the From address of before forwarding so that replies go back through its SMTP servers. Those SMTP servers should rewrite the reply not to leak information.
Even when it rewrites message envelope and headers, the actual message body of an NDR (nondelivery report) can disclose original address information. Because the NDR is generated by the receiver server, the HideMyEmail does not have influence on what the message body can contain. Think of it as if you had an out-of-office autoreply which includes your email address among other information in the message body.
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:
(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.
> 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.
> 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.
Try figuring out the message size that the forwarding edge (icloud.com) accepts, but the receiver (the mailbox server) does not. SMTP is tricky business, because you don't really know at which point the NDR might happen.
> 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.
I did but where is fun in that. When I got involved in infosec community decades ago, veterans told me then, I should always investigate for myself, not just reading someones reports, they were right. That’s why I suggested it, because you seemed interested.
Yeah it’s a good guess. I was also thinking there might be some header leaks. Or possibly if you return server busy on the first attempt or something like this, some sort of edge case the developers overlooked.
My guess would be it has nothing to do with email itself. Maybe it's some iCloud API that accepts obfuscated emails but returns the original email in the response, or an ID which can be used to retrieve the iCloud email from another API endpoint. Could be as simple as an "add contact/friend" feature in some Apple product (like a mail client, or a file sharing service) that resolves the obfuscated email to the original iCloud account.
In the comment section of the 404media article Joseph Cox writes when asked whether it reveals the icloud address the email is forwarded to or the apple id [0]:
> It reveals the email linked to the Apple ID.
So I assume you are right that it has nothing to do with the email itself, but prob some other service that links the obfuscated email to the appleid of the user.
I think they are hinting at the ad hoc "use hidemyemail" feature within e.g. the mail client.
I don't know what I am doing, but from a quick test, the mail header is at least disclosing the internal recipient (mail@host.com) "translation address" (as mail_at_host_com_12345abc_12345abc@icloud.com) and an alias creation date. But the latter seems to be a unix timestamp related to the real address alias creation time and is identical between an hidemyemail mail and a normal one, so there may be already a possible information leak for correlation. Side note, it also seems like the sending hidemyemail server contains the unsuspicious name "junk_forwarder". Lol.
Disclosing an address as alias and particularly as throwaway alias (through the translation address and server) already seems kinda counterproductive to begin with, but I would bet you can use this information somehow to get the sender "translation address". Either by some API interaction, or by messing with the mail header scrubbing of the translation service somehow. A server named "junk_forwarder" may be a little more lenient about what to accept or not.
Edit: Can confirm the Reddit comment linked. You simply send an email to the HME address, reply from Apple mail client, and then the real mail address gets disclosed. Mind you not even hidden. It's shown as sending from the HME alias in mail, but I received the mail with the real address as sender......... Jesus fucking christ, Apple. Did you even test this a little?
> then the real mail gets disclosed in the mail source.
It's not just in the source, I totally overlooked the fact the real email address is shown as sender. Lol.
> Does the initial sender matter? Like if it’s the HME address that sends first and receives the reply? I have around 180 of these addresses.
Appears so. Here is exactly what I did:
1. Created the HME through mail, sending to other email service address (OMA). (This disclosed the information in my original comment.)
2. Did some reply ping pong. (No additional disclosure.)
3. Send a new email from OMA to above HME.
4. Replied from iOS mail client (UI showing usage of HME alias. Yes, I verified this multiple times not to make a fool of myself.)
5. Received at OMA, the real address is disclosed.
6. On the iOS client side, the mail shows up as sent from the real mail address, too.
Not sure if 1. for HME creation is required, you can likely skip straight to 3. for any HME address.
Funny enough, I observed 6. in the wild before, but was kinda hoping that's an artifact of forwarding a copy of the mail to the thread. I tested this some, but not this particular ping-pong. So yeah... I now gonna check where I evidently leaked my real mail address already...
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):
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...
That's what I thought, but I happens to coincide with the actual leakage, so....
What is bad UX is the fact there are two reply buttons in the iOS client. One "in" the mail and one for the thread. The mail one pretends to reply from HME alias, the thread one does not. This alone could expose you by accident, since anyone would expect to reply with HME in any case, but you get exposed either way.
...which makes it seem like perhaps the attack surface is limited to scenarios involving a Yahoo/Sonic address (assuming that Apple only sends X-Sonic-* headers when talking to those providers that want to see it), which might be a small percentage of users.
It’s hard for me to assess how real this risk is. Without details, we’re just extrapolating from circumstantial vibes.
What’s described sounds like it might be spooky. It might also be a magic trick to some degree… Mr. Cox’s PoC—“I gave a fresh Hide-My-Email alias to a guy who knows who I am, and he told me the email on my Apple ID”—is consistent with the claimed behavior but not exactly watertight.
It also sounds like it might be the sort of thing that’s either “just how the email ecosystem works” or mitigable by covert means. For example, if Apple can identify exploit attempts from its privileged vantage over its infrastructure, maybe that’s the basis for its relaxed impact assessment.
I’m reminded of Amazon’s risk assessment with respect to some Quick bug recently [0]: “yeah, it’s bad, but we checked and there are literally zero people other than you who’ve ever used that feature that way.”
Or maybe it’s the kind of thing that requires a structural sort of tradeoff to conclusively fix. I could imagine the exposure mechanism having something to do with their forthcoming move to segregate aliases to their own “private.icloud.com” domain.
(A move at which Mr. Cox swipes in the 404 Media article, too, of course, but hey—“impact journalism.”)
And then, since we have only vibes to go on, there’s the judgment reflected in the researcher’s email to Apple:
> “It seems that ending new sales of Hide My Email until the problem is fixed would be an effective way to limit the number of customers at risk. Is that an option?” Murphy wrote back.
I can only hope that was a sardonic moment of frustration quoted out of context… Hide My Email is “sold” as a tiny tiny bonus feature of a much bigger iCloud+ product. But as-quoted, it’s giving a little bit of Chicken Little… I’m reminded of the time somebody demanded that a firm I’m familiar with halt all sales (and pay hush money) because of a CRITICAL SECURITY HOLE: you could access the contents of a password field by typing the password in the field, pressing F12 in the browser, and typing $(“#pw-input”).value …
If the flaw really is the sort of thing that required fundamental product changes to fully address—like this domain segregation thing—a year doesn’t seem wild at all to make that transition safely and at scale. Especially if they identified effective mitigations in the meantime.
> > “It seems that ending new sales of Hide My Email until the problem is fixed would be an effective way to limit the number of customers at risk. Is that an option?” Murphy wrote back.
> I can only hope that was a sardonic moment of frustration quoted out of context
I didn't make my point clearly there, and I think it makes more sense in context, but it was a sincere suggestion that Apple could stop allowing new people to use Hide My Email. There are many other email aliasing services, so they wouldn't be depriving people of a unique offering. At the time, I wasn't aware that Hide My Email was only available as part of iCloud+. All I knew was that it wasn't free.
Makes sense to me! I'd gone off the 404 Media article originally linked. The way you put it in your blog timeline (now the link of record) makes perfect sense to me:
> We hope that Apple will take steps to limit the attack surface area even before the vulnerability is fixed. Disabling creation of new Hide My Email addresses could be helpful. It also seems responsible to notify all Hide My Email users of the risk.
Thank you for your work, and your persistence against our Sphinx-like overlords!
Can you please clarify whether this is only an issue if I reply to an email sent to one of my HME addresses or whether you can unmask any HME address w/o needing a reply from the recipient.
Can you also clarify whether it matters what the forwarding address is? e.g. whether my HME addresses forward to an icloud.com address (e.g. js2@icloud.com) or say a personal domain associated with my Apple ID (e.g. js2@example.org).
Thanks for everything y'all do with Easy Opt Outs. I've put a number of family members and acquaintances onto it. I'm glad this service exists at an actually affordable rate
I think "real email" address is underselling it, since that's commonly the apple-ID, which is the gateway to some people's whole digital existence. Not to mention the fact, you tend to use hidemyemail in particular for services you don't want any identity leaked to. The "real email" may contain your legal name already.
As someone who uses this feature I never send messages from a hide my email address as I only use it for random email signups. Am I still at risk of having my email exposed??? It’s also handy for using for free trials lol.
I've been going back and forth with Apple about it for a year. We don't feel comfortable releasing the exploit details even though they're being slow. We think enough people rely on Hide My Email for personal safety that it would be irresponsible.
Hopefully nobody in the criminal underworld has figured it out on their own.
Do you believe the mitigation would be difficult to engineer? If, say somebody else, publicly disclosed the unmasking technique how long would you guess it would take Apple to implement a verifiable fix?
We're hoping that by notifying people that there's a vulnerability, people can stop using Hide My Email if it matters to them. I don't think that disclosing the exploit method will get Apple to fix it faster at this point.
If having your personal email exposed would be a matter of personal safety or similar, then stop using it. If you're just using it for junk mail or to get a free trial then keep using it.
Yes, but a mitigation suggestion like "keep using it, except don't do X specific sequence" (for example, send to a Yahoo address via the Reply button, or whatever the case may be) could be helpful as well, since it seems that bad actors (and/or good actors spilling the beans) will figure it out sooner than later anyway.
I use this feature often and I'm very disappointed. Depending on the exploit, I'm awaiting to join a class action lawsuit. I'm constantly humiliated by believing Big Tech's security promises and I've had enough. I suspect that this is yet another intentional backdoor. When these security systems fail, people like me experience violence.
That timeline was exactly my experience with Apple here - https://www.grepular.com/Apples_Protect_Mail_Activity_Doesnt...
They don't seem to know or care what is going on with their own email systems.
Has anyone seen Protect Mail Activity get re-enabled after you've disabled it? I wrote about that a few days ago: https://lapcatsoftware.com/articles/2026/6/6.html
Not for me. I don’t even remember when (or since how many years ago) I turned off Protect My Email and turned on both Hide IP Address and Block All Remote Content. I still have these toggles as they are, despite the fact that I use beta releases as and when they’re released (currently still on iOS 26.x).
I’m still mildly annoyed every email I send using Mail has my IP embedded in it
This is your email provider doing this. I use Fastmail. Fastmail does not log the IP of the sender when you use its SMTP servers.
Source? I don't think this is true. Doesn't seem to be the case for me. Maybe your email provider attaches your IP address?
It’s in the headers. Send an email to your self from Mail and open the source in the inbox. There is your IP.
I also just tried this as well, sending an email from a Migadu-based account to one at both Gmail and MXRoute using Mail.app under macOS 15.7.7. Neither included any private IP address info I could find in either headers or raw source. That would be a good leak to know about and as sibling comment said saagarjha definitely knows their stuff, so any tips to replicate would be appreciated.
Received: from smtpclient.apple (ptr. [ip]) by smtp.gmail.com with ESMTPSA id ... for <...> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jul 2026 ..:..:.. -0700 (PDT)
Using Mail: Version 16.0 (3864.600.51.1.1).
Sent from a Google Apps mail.
For me that IP belongs to apple, when using the iOS mail client. I presume Apple forces third party apps to use their API and then stuff like this happens. Guess that's also on google, not mitigating that issue, tho.
Have you tried a VPN? I wonder, if Apple manages to expose IP despite a VPN. They had issues with stuff like that before.
That Received header is inserted by smtp.gmail.com (Google), not Apple.
Is this from iOS? I just tested from MacOS, and the only IPs were for the transit and auth servers.
I'm not actually doubting it. saagarjha knows his stuff. I just don't see it, so maybe I'm holding it wrong.
Same, I remember it being in the headers long ago but don't see it now. macOS Tahoe, Mail.app client, iCloud email sending to itself or to my Gmail, both set up in default ways, IPv6 disabled
From what I see above, it looks like the trick is to send from Mail.app to an account read by a different app (maybe just Gmail?).
I would need to test with my hosting Webmail client, so maybe tomorrow.
See my comment here: https://news.ycombinator.com/item?id=48758444.
I saw that, in my headers, but in my case, it was not an IP in any subnet of mine.
I’ll mess around, today, and see what comes up.
Seems like this is a Gmail thing: https://ylukem.com/blog/apple-mail-leaks-your-ip-address
It's not a Gmail thing:
> The reason why my IP address is visible is because Apple Mail sends emails with SMTP.
Unless you use a proxy, your IP address is visible to an SMTP server, just like it's visible to an HTTP server when you use a web browser. This is not specific to Apple Mail or to Gmail.
Yeah but I think Gmail seems to actually just keep that header rather than nuking it. To be fair I don't entirely know what I would do to fix it since (like the post) this seems like there aren't many good options here.
> I think Gmail seems to actually just keep that header rather than nuking it.
I think that's common among email providers.
Gmail's SMTP servers are what's adding the received header with your IP address, not Apple Mail.
I clearly remember many years ago that this wasn’t the case with Gmail, when looking for the source IP address in a case involving harassment of a person. I could only get Gmail’s own IP address in the headers from the multiple emails I examined at that time.
Nevertheless, as js2 said in another comment, it’s your mail provider (in this case Gmail) deciding whether to include the sender’s IP address or not.
Yes, was able to repro just now
Why? Something real, or just nonspecific vibes?
right.
Fetching any email content is always worse than blocking it, because the typical threshold for spam is "is this inbox monitored". If that is true, then blast it with spam. And fetching anything ever proves that the inbox is monitored.
My impression as a Mutt user (which never downloads linked content) is that spammers don’t really care about whether an inbox is “monitored” or not.
At least in Gmail, downloading content (e.g. images) is disabled by default for suspicious emails. There is no way for the sender to know if it’s monitored unless this is disabled by explicit user action.
This freaked me out the first time I used Mail. It rendered a PDF about buying bitcoin on PayPal (I don't have PayPal). Looked at the same email in Gmail and Thunderbird, it's just a PDF attachment, no message, and the sender was different. No wonder people are falling for those scams, Mail makes it easy for them.
Now if only I had a better client on my phone (never buying an iPhone again)
What made you prefer Mail to Gmail, given you don’t seem satisfied with Apple’s Mail app?
I prefer Thunderbird
I am starting to think all these "privacy" features merely exist as excuse for getting people to hand off their mails to Apple. Clearly the all do not deliver on the intended functionality, but the proxy/relay routing happens to some extent anyway. How convenient. If you were a company promising its users all the privacy, but secretly not giving a fuck beyond collecting user traffic and meta data, wouldn't you expect the state of things to look exactly like that? I mean, how could you explain this any other way, considering the size of Apple and the relative ease of developing such features reliably? Apple is hardly breaking ground here.
I guess the vulnerability should work as follows (I haven't tried it), you send an email with a very large attachment to a "hide my email" address, the server that receives it (private.icloud.com) forwards it to the email server registered in iCloud which, being the very large attachment, sends a response email (from the real address) with the rejected email message. It's the first thing I would try.
Apple rewrites the From address of before forwarding so that replies go back through its SMTP servers. Those SMTP servers should rewrite the reply not to leak information.
Even when it rewrites message envelope and headers, the actual message body of an NDR (nondelivery report) can disclose original address information. Because the NDR is generated by the receiver server, the HideMyEmail does not have influence on what the message body can contain. Think of it as if you had an out-of-office autoreply which includes your email address among other information in the message body.
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:
(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:
I tried various approaches. They all bounce at the edge: 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.
> 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.
> 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.
Try figuring out the message size that the forwarding edge (icloud.com) accepts, but the receiver (the mailbox server) does not. SMTP is tricky business, because you don't really know at which point the NDR might happen.
> 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.
> Is this a theory or did you test this yourself?
This is just a pointer for exercise you could do if you are interested. I can’t tell what is the actual HME vulnerability they claim to exist.
Why don't you give it a try and report back.
I did but where is fun in that. When I got involved in infosec community decades ago, veterans told me then, I should always investigate for myself, not just reading someones reports, they were right. That’s why I suggested it, because you seemed interested.
Were you able to unmask an HME address via SMTP or not? If so, was the real address an iCloud.com address?
[flagged]
Yeah it’s a good guess. I was also thinking there might be some header leaks. Or possibly if you return server busy on the first attempt or something like this, some sort of edge case the developers overlooked.
Is it based on mail undeliverable errors? Or attempts to login using IMAP or SMTP with it? Or is it exposed during the SMTP protocol?
My guess would be it has nothing to do with email itself. Maybe it's some iCloud API that accepts obfuscated emails but returns the original email in the response, or an ID which can be used to retrieve the iCloud email from another API endpoint. Could be as simple as an "add contact/friend" feature in some Apple product (like a mail client, or a file sharing service) that resolves the obfuscated email to the original iCloud account.
In the comment section of the 404media article Joseph Cox writes when asked whether it reveals the icloud address the email is forwarded to or the apple id [0]:
> It reveals the email linked to the Apple ID.
So I assume you are right that it has nothing to do with the email itself, but prob some other service that links the obfuscated email to the appleid of the user.
[0] https://www.404media.co/apple-hide-my-email-vulnerability-re...
I think they are hinting at the ad hoc "use hidemyemail" feature within e.g. the mail client.
I don't know what I am doing, but from a quick test, the mail header is at least disclosing the internal recipient (mail@host.com) "translation address" (as mail_at_host_com_12345abc_12345abc@icloud.com) and an alias creation date. But the latter seems to be a unix timestamp related to the real address alias creation time and is identical between an hidemyemail mail and a normal one, so there may be already a possible information leak for correlation. Side note, it also seems like the sending hidemyemail server contains the unsuspicious name "junk_forwarder". Lol.
Disclosing an address as alias and particularly as throwaway alias (through the translation address and server) already seems kinda counterproductive to begin with, but I would bet you can use this information somehow to get the sender "translation address". Either by some API interaction, or by messing with the mail header scrubbing of the translation service somehow. A server named "junk_forwarder" may be a little more lenient about what to accept or not.
Edit: Can confirm the Reddit comment linked. You simply send an email to the HME address, reply from Apple mail client, and then the real mail address gets disclosed. Mind you not even hidden. It's shown as sending from the HME alias in mail, but I received the mail with the real address as sender......... Jesus fucking christ, Apple. Did you even test this a little?
> You send an email to the HME address, reply, and then the real mail gets disclosed in the mail source.
Does the initial sender matter? Like if it’s the HME address that sends first and receives the reply? I have around 180 of these addresses.
> then the real mail gets disclosed in the mail source.
It's not just in the source, I totally overlooked the fact the real email address is shown as sender. Lol.
> Does the initial sender matter? Like if it’s the HME address that sends first and receives the reply? I have around 180 of these addresses.
Appears so. Here is exactly what I did:
1. Created the HME through mail, sending to other email service address (OMA). (This disclosed the information in my original comment.)
2. Did some reply ping pong. (No additional disclosure.)
3. Send a new email from OMA to above HME.
4. Replied from iOS mail client (UI showing usage of HME alias. Yes, I verified this multiple times not to make a fool of myself.)
5. Received at OMA, the real address is disclosed.
6. On the iOS client side, the mail shows up as sent from the real mail address, too.
Not sure if 1. for HME creation is required, you can likely skip straight to 3. for any HME address.
Funny enough, I observed 6. in the wild before, but was kinda hoping that's an artifact of forwarding a copy of the mail to the thread. I tested this some, but not this particular ping-pong. So yeah... I now gonna check where I evidently leaked my real mail address already...
Did #1 on macOS Mail.app, but #4 on iOS Mail client like you.
#5., real address not disclosed at OMA for me.
(now that I see the reddit thread) is this potentially Yahoo/Sonic-only?
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...
6. is a sign of bad UX but not leakage to the recipient.
That's what I thought, but I happens to coincide with the actual leakage, so....
What is bad UX is the fact there are two reply buttons in the iOS client. One "in" the mail and one for the thread. The mail one pretends to reply from HME alias, the thread one does not. This alone could expose you by accident, since anyone would expect to reply with HME in any case, but you get exposed either way.
As someone who doesn't rely on this feature, I'd love to know now as well, but perhaps the etiquette in public would be to align ourselves with:
> we will not discuss or disclose the details of the exploits until they're fixed.
But if there's a public forum where the cat's already out of the bag, then game on. Perhaps this:
https://www.reddit.com/r/apple/comments/1ukilw1/apple_hide_m...
...which makes it seem like perhaps the attack surface is limited to scenarios involving a Yahoo/Sonic address (assuming that Apple only sends X-Sonic-* headers when talking to those providers that want to see it), which might be a small percentage of users.
I wonder if it is replies to delivery receipts that causes this problem
It’s hard for me to assess how real this risk is. Without details, we’re just extrapolating from circumstantial vibes.
What’s described sounds like it might be spooky. It might also be a magic trick to some degree… Mr. Cox’s PoC—“I gave a fresh Hide-My-Email alias to a guy who knows who I am, and he told me the email on my Apple ID”—is consistent with the claimed behavior but not exactly watertight.
It also sounds like it might be the sort of thing that’s either “just how the email ecosystem works” or mitigable by covert means. For example, if Apple can identify exploit attempts from its privileged vantage over its infrastructure, maybe that’s the basis for its relaxed impact assessment.
I’m reminded of Amazon’s risk assessment with respect to some Quick bug recently [0]: “yeah, it’s bad, but we checked and there are literally zero people other than you who’ve ever used that feature that way.”
Or maybe it’s the kind of thing that requires a structural sort of tradeoff to conclusively fix. I could imagine the exposure mechanism having something to do with their forthcoming move to segregate aliases to their own “private.icloud.com” domain.
(A move at which Mr. Cox swipes in the 404 Media article, too, of course, but hey—“impact journalism.”)
And then, since we have only vibes to go on, there’s the judgment reflected in the researcher’s email to Apple:
> “It seems that ending new sales of Hide My Email until the problem is fixed would be an effective way to limit the number of customers at risk. Is that an option?” Murphy wrote back.
I can only hope that was a sardonic moment of frustration quoted out of context… Hide My Email is “sold” as a tiny tiny bonus feature of a much bigger iCloud+ product. But as-quoted, it’s giving a little bit of Chicken Little… I’m reminded of the time somebody demanded that a firm I’m familiar with halt all sales (and pay hush money) because of a CRITICAL SECURITY HOLE: you could access the contents of a password field by typing the password in the field, pressing F12 in the browser, and typing $(“#pw-input”).value …
If the flaw really is the sort of thing that required fundamental product changes to fully address—like this domain segregation thing—a year doesn’t seem wild at all to make that transition safely and at scale. Especially if they identified effective mitigations in the meantime.
Then again, maybe they really are negligent…
[0] https://www.theregister.com/columnists/2026/05/13/aws-patche...
> > “It seems that ending new sales of Hide My Email until the problem is fixed would be an effective way to limit the number of customers at risk. Is that an option?” Murphy wrote back.
> I can only hope that was a sardonic moment of frustration quoted out of context
I didn't make my point clearly there, and I think it makes more sense in context, but it was a sincere suggestion that Apple could stop allowing new people to use Hide My Email. There are many other email aliasing services, so they wouldn't be depriving people of a unique offering. At the time, I wasn't aware that Hide My Email was only available as part of iCloud+. All I knew was that it wasn't free.
Makes sense to me! I'd gone off the 404 Media article originally linked. The way you put it in your blog timeline (now the link of record) makes perfect sense to me:
> We hope that Apple will take steps to limit the attack surface area even before the vulnerability is fixed. Disabling creation of new Hide My Email addresses could be helpful. It also seems responsible to notify all Hide My Email users of the risk.
Thank you for your work, and your persistence against our Sphinx-like overlords!
archive link: https://archive.vn/mCbBw
We put up a timeline of the disclosure here: https://easyoptouts.com/guides/apple-hide-my-email-is-leakin...
Can you please clarify whether this is only an issue if I reply to an email sent to one of my HME addresses or whether you can unmask any HME address w/o needing a reply from the recipient.
Can you also clarify whether it matters what the forwarding address is? e.g. whether my HME addresses forward to an icloud.com address (e.g. js2@icloud.com) or say a personal domain associated with my Apple ID (e.g. js2@example.org).
Can you comment on this: https://news.ycombinator.com/item?id=48752294 ?
To me it seems, at least in this instance there is not even an exploit needed and the feature apparently is just broken beyond belief.
Thanks! We'll make that the main URL and put the submitted link in the toptext.
Thanks for everything y'all do with Easy Opt Outs. I've put a number of family members and acquaintances onto it. I'm glad this service exists at an actually affordable rate
Related:
Apple is about to make Hide My Email useless
https://news.ycombinator.com/item?id=48559935
I submitted your post to Apple’s feedback for on iCloud. If others do the same, perhaps they’ll take notice:
https://www.apple.com/feedback/icloud/
I think "real email" address is underselling it, since that's commonly the apple-ID, which is the gateway to some people's whole digital existence. Not to mention the fact, you tend to use hidemyemail in particular for services you don't want any identity leaked to. The "real email" may contain your legal name already.
As someone who uses this feature I never send messages from a hide my email address as I only use it for random email signups. Am I still at risk of having my email exposed??? It’s also handy for using for free trials lol.
Shameless plug
https://github.com/webmonch/hide-my-mail-cloudflare
The value of Hide My Email, SimpleLogin is that you can blend in with the crowd. If you use your own domain then the domain becomes the common link.
Why not just use cloudflare with catch all email routing?
That's disappointing, both that the vulnerability exists in the first place, and that Apple takes over a year to not even fix it.
They're a struggling company and can't hire top talent.
Not as disappointing as the discover's decision to leave affected users ignorant and hence at risk.
I think you should formally write to Apple and give notice of 30 days to contact you or you will reveal it.
Send it to the USA media and regulator too
I've been going back and forth with Apple about it for a year. We don't feel comfortable releasing the exploit details even though they're being slow. We think enough people rely on Hide My Email for personal safety that it would be irresponsible.
Hopefully nobody in the criminal underworld has figured it out on their own.
Do you believe the mitigation would be difficult to engineer? If, say somebody else, publicly disclosed the unmasking technique how long would you guess it would take Apple to implement a verifiable fix?
> We think enough people rely on Hide My Email for personal safety that it would be irresponsible.
I am guessing you haven't tried that excuse on the users your witholding is leaving exposed.
We're hoping that by notifying people that there's a vulnerability, people can stop using Hide My Email if it matters to them. I don't think that disclosing the exploit method will get Apple to fix it faster at this point.
The problem there is users cannot evaluate if it matters to them whilst all information needed to do so is being witheld.
If having your personal email exposed would be a matter of personal safety or similar, then stop using it. If you're just using it for junk mail or to get a free trial then keep using it.
Yes, but a mitigation suggestion like "keep using it, except don't do X specific sequence" (for example, send to a Yahoo address via the Reply button, or whatever the case may be) could be helpful as well, since it seems that bad actors (and/or good actors spilling the beans) will figure it out sooner than later anyway.
Its the only reason I even pay the $1 a month icloud plan, so might as well cancel it if its gonna be eternally broken.
I use this feature often and I'm very disappointed. Depending on the exploit, I'm awaiting to join a class action lawsuit. I'm constantly humiliated by believing Big Tech's security promises and I've had enough. I suspect that this is yet another intentional backdoor. When these security systems fail, people like me experience violence.
[dead]
"This is the one thing we didn't want to happen"
Ok, yet another reason I have a totally separate burner Gmail instead of complicating things like this.
[dead]
[flagged]
Sorry I'm not seeing how your comment is relevant to the orignal post, can you clarify?
The post is about a vulnerability in Apple under CEO Tim Cook, who did horrible things after Steve Jobs died — most importantly, changing the UI/UX.