Anyone who wants the large image can click/tap the image, but the revere is harder to do.
In the other direction, Mt. Everest is 8,848.86 meters above sea level. I guess we don't include Lake Tahoe and/or Crater Lake because even though they're deep(ish), their bottoms are above way sea level?
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).
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.
18 months later the entire library became DRM-free iTunes Plus quality and you could upgrade existing songs you had already purchased or that you had in your library via iTunes Match.
https://en.wikipedia.org/wiki/Aluminium#Naming_and_spelling_...
Cheers. :-)
reply