[Dibby053]

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.

[freehorse]

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

[jijijijij]

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 ([e-mail]) "translation address" (as [e-mail]) 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?

[impish9208]

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

[jijijijij]

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

[Barbing]

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?

[jijijijij]

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=[e-mail]; d=; f=[e-mail]; r=to; e=[e-mail]; s=[e-mail]

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

[dustyharddrive]

6. is a sign of bad UX but not leakage to the recipient.

[jijijijij]

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.