[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]

We don't have full headers, unfortunately. I'm not very familiar with SMTP, but to test things out, we ended up running a minimal custom mail server with the nodejs 'net' module to have full control over responses. I think it'd be possible to set something similar up so that the same mail server handles Hide My Email and normal iCloud addresses differently.

  const net = require('net')
  
  const server = net.createServer((socket) => {
   socket.setEncoding('utf8')
   socket.write('220 ...')
  
   socket.on('data', (data) => {
    if (isHideMyEmail(data)) {
     // handle one way
    } else {
     // handle another way
    }
   })
  
   ...
  })
  
  server.listen(25, '0.0.0.0', () => {
   console.log(`Ready for incoming emails`)
  });

That being said, I have no idea how Hide My Email works technically. Maybe the headers would make it clearer.