[js2]

> Now Apple says it has been fixed, we can add that, in simple terms, it required sending a target Hide My Email user a message that got rejected as spam.

Frustratingly vague. I was unable to reproduce when the original article was posted. I did not test exhaustively, but I was able to get HME to reject messages in various ways (mostly by sending oversize messages) and none disclosed my real address because they were rejected before any rewriting to the final address occurred. And in looking at messages that were delivered, I didn't see any additional SMTP servers in the path that would reject the message.

The most I was able to leak was a DMARC header showing my real domain, but even that only occurred when I replied to an HME email from my real (non-icloud.com) domain. When I updated HME to use my icloud.com address, even that leak went away (but it did make it clear that HME was not sanitizing message headers).

Maybe if you have HME setup to forward to a non-icloud.com domain and that domain's SMTP servers rejected the message as spam, I can see how this could occur. But if forwarding to an icloud.com address, no way this should've been able to happen in the first place.

I wish they'd included a sample message including full headers to see the vulnerability in action. Where in the delivery path was the bounce being generated?

I want more details.

[tjames7000]

We'll publish more details soon. In short, emails that triggered 550 5.7.1 or 552 5.7.0 were what we saw the most. 550 5.1.1 was also a problem in the real world, but not possible to exploit. The error message contained the meant-to-be-hidden address.

We don't know whether attachment-related rejections or other rejections, e.g. for a full inbox, were a problem. Apple fixed most of the issues on July 2 or July 3, so if you were testing after that, you may have been too late.

These are basically the reproduction instructions we provided with our initial report: 1. Send a spammy email to the Hide My Email address. Or send an email that doesn't strike you as spammy and hope that the email is rejected as spam anyway. 2. If the email is rejected SMTP code 550, look at the long description field and observe the real email address. 3. If the email wasn't rejected by the email server as spam, try again with a spammier email or different email. I think that once you've identified a message that's rejected as spam consistently, you can keep using it.

Post-fix, we're realizing that it seems like emails forwarded via Hide My Email bounce as spam at higher rates than the same emails sent directly. Which could explain why we were getting bounces for non-spam transactional emails sent only to paying customers, and why the bounces were only happening for icloud addresses. The issue may have been more prevalent than someone might assume, given typical bounce rates.

[js2]

And just to clarify: this occurred ever when HME was setup to forward to an icloud.com address? I'd love to see the full headers of a bounced message to understand the MTAs that were involved in disclosing the address.

I tested on July 2 when the original submission was made: https://news.ycombinator.com/item?id=48767855

[tjames7000]

We saw the issue for a wide variety of hidden address domains. We use Mailgun to send emails so we were seeing Mailgun logs with things like this. I replaced the customer's real email username with "redactedForPrivacy".

  "delivery-status": {
   "code": 550,
   "description": "This is a system-generated message to inform you that your email could not\r\nbe delivered to one or more recipients. Details of the email and the error are as follows:\r\n\r\n\r\n<[e-mail]>: host 127.0.0.1[127.0.0.1] said: 550 5.7.1 message\r\n    content rejected due to spam; if you feel that your email was rejected in\r\n    error, please forward a copy to [e-mail] (in reply to end of\r\n    DATA command)\r\n",
   "enhanced-code": "5.7.1",
   "message": "smtp; 550  message content rejected due to spam; if you feel that your email was rejected in error, please forward a copy to [e-mail]"
  }

The "description" fields' contents were almost identical regardless of the hidden email address's mail host, but I don't know if that means anything.

It sounds like iCloud limits messages to 20 megabytes. You might have needed to be forwarding to a final destination with a smaller limit so that the rejection came from the final destination rather than from iCloud. We didn't test that until July 7.

[js2]

So what I'm trying to clarify here is whether this worked when the final address was an icloud.com address. i.e. there are two scenarios:

1. [e-mail] -> [e-mail]

2. [e-mail] -> [e-mail] where example.com is not any of icloud.com, me.com, mac.com (such as in your example, gmail.com)

HME can be configured for either of setups.

I really want to establish whether you were able to unmask a real address under (1), since in this case any bounce message should occur too early to disclose the real address.

Under (2), the bounce message can occur after rewriting and I can totally see how it was leaking the real address.

(For the purposes of the exploit, it doesn't matter that you used Mailgun to send the email, but I appreciate that detail.)

[tjames7000]

Okay, I see what you mean. We never paid attention to whether (1) was happening. I imagine Apple can tell based on the code that was running at the time.

Even in case (1), isn't it possible that Hide My Email bounces happen differently from regular @icloud.com bounces despite being on the same domain?

We've also been wondering whether Hide My Email was ever responsible for generating the messages with meant-to-be-hidden addresses or whether it was only passing them along and failing to hide them. I don't think we have enough information to tell.

[js2]

> Even in case (1), isn't it possible that Hide My Email bounces happen differently from regular @icloud.com bounces despite being on the same domain?

I don't think so because when I examine the headers of an HME delivered message to my [e-mail] address there's only a single MTA involved.

> We've also been wondering whether Hide My Email was ever responsible for generating the messages with meant-to-be-hidden addresses or whether it was only passing them along and failing to hide them. I don't think we have enough information to tell.

The full headers of the bounce message will tell you.

[tjames7000]

Here are some more details: https://easyoptouts.com/guides/apple-hide-my-email-was-leaki...