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.

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.

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<[email protected]>: 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 [email protected] (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 [email protected]"
  }

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.

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.

We're hoping that by notifying people that there's a vulnerability, people can stop using Hide My Email if it matters to them. I don't think that disclosing the exploit method will get Apple to fix it faster at this point.

> > “It seems that ending new sales of Hide My Email until the problem is fixed would be an effective way to limit the number of customers at risk. Is that an option?” Murphy wrote back.

> I can only hope that was a sardonic moment of frustration quoted out of context

I didn't make my point clearly there, and I think it makes more sense in context, but it was a sincere suggestion that Apple could stop allowing new people to use Hide My Email. There are many other email aliasing services, so they wouldn't be depriving people of a unique offering. At the time, I wasn't aware that Hide My Email was only available as part of iCloud+. All I knew was that it wasn't free.

I've been going back and forth with Apple about it for a year. We don't feel comfortable releasing the exploit details even though they're being slow. We think enough people rely on Hide My Email for personal safety that it would be irresponsible.

I co-founded easyoptouts.com a few years ago because all of the existing options were way too expensive. We focus on publicly-accessible people-search sites. Our customers are happy, and you can check out our privacy policy to see how we handle data.

easyoptouts.com, which I work on, doesn't use manual labor - everything is automated! It's definitely important to avoid giving more people access to the data.

edit: and as a result of automation, our prices are also way lower than most similar services