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.

▲ js2 a day ago | parent [-]

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.

▲

winstonwinston a day ago | parent | next [-]

> 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.

▲

js2 a day ago | parent [-]

> 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.

▲

winstonwinston a day ago | parent [-]

> 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.

▲

js2 a day ago | parent [-]

Why don't you give it a try and report back.

▲

winstonwinston a day ago | parent [-]

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.

	▲	a day ago \| parent \| next [-]
		[deleted]
	▲	js2 a day ago \| parent \| prev [-]
		Were you able to unmask an HME address via SMTP or not? If so, was the real address an iCloud.com address?

▲

sealedmailuk 19 hours ago | parent | prev [-]

[flagged]