Rendered at 23:29:01 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
satvikpendem 1 days ago [-]
But Apple did not yet walk back that they wanted a single dedicated domain for private emails, privacy.icloud.com, such that it'd be easy for any host to block them.
halJordan 1 days ago [-]
I'm honestly getting tired of us requiring big corps to do everything for us. Use the private domain. Dont have the account if they block it. End users and consumers need to bite the bullet.
lern_too_spel 1 days ago [-]
Private domains aren't really private because they can be matched across data leaks. Fine for tracking senders though.
argee 1 days ago [-]
I have a question I wasn’t sure how to ask HN that is tangentially related to this. I’m the developer of an app where people can add other users to their workspaces, via email. The way this currently works is that your email gets added to the workspace and then when you log in with that email, you get access.
Now, this of course fails with “hide my email”. What’s the appropriate/standard way to handle this? Should I be using urls with invite codes instead of associating the email itself with access? I’m a little hesitant to do that since the code would have to persist in session and the business logic would have to occur on the login portal, since the mobile/desktop apps don’t share web cookies. Is deep linking the answer?
layer8 1 days ago [-]
In general it's bad practice for a user to expose someone else's email address to an application provider without consent (email providers being the one necessary exeception, of course), therefore I would abandon that approach in any case.
You could implement read-only access to a workspace via a generated link (containing a UUID or similar), like e.g. a Dropbox link. You would store the link IDs with the workspace, and you can implement (user-configurable) link expiration and such. Since links are shareable, these wouldn't be personalized to the recipient. A recipient who wants more than read-only access would still have to create an account with you and ask the workspace owner for write access.
argee 1 days ago [-]
> In general it's bad practice for a user to expose someone else's email address to an application provider without consent
Thanks, that makes sense as a rule of thumb. I'll move towards invite code (and work domain/SSO) based access. It's also a bit awkward to be able to add existing users to a workspace without any sort of confirmation, so my system needs a bit of rework regardless.
WorldMaker 1 days ago [-]
I've seen this kind of thing fail in so many ways just as a user with a custom domain. Someone adds my real email (the custom domain) to a Google invite and my primary Google Account uses its own email (a Gmail account) that is in no way my primary email address and Google gets confused and won't let me access the thing sent to my real email because I'm trying to access it from my Google Account. (Plus additional variations where my custom domain was briefly hosted on what today is called Google Workspace and some things still seem to be misconfigured to point to shutdown accounts for my real primary address still apparently ghosts in Google Workspace.)
That's eternally a frustrating experience. It ranks among the reasons I groan every time someone asks if we can meet in Google Meeting instead of other options.
That's just dealing with one large giant of a company who you would think if anyone would have the software resources to truly untangle email addresses from account assumptions, they would have more than enough resources available.
Lots of little papercuts like that exist everywhere else. I have multiple accounts with various "Pledge Managers" because I gave Kickstarter a specific filtered address but still tend to respond to surveys and other things sent more directly to me with my primary email address. "For my convenience" most of these "Pledge Managers" tie their accounts to whatever email address they get from a Kickstarter export spreadsheet and then assume that each email address is 1:1 useful for marking an account as mine. It's often easier to juggle a bunch of reminder notes in my Password Manager which campaign is with which account with which "Pledge Manager" than to unify accounts. It becomes the opposite of convenience.
I've seen the same thing happen with + addresses, not just custom addresses at custom domain addresses. Add a + to a signup to get autofiltering when you sign up for a service and most services see `accountname+filter@gmail.com` as a different email address than `accountname@gmail.com`. Which is the correct behavior because `+` filtering is a convention not a guarantee/standard. But it again adds complexity in these sorts of "auto-invites" when you are trying to auto-correlate based on specific email address.
It seems important to me to not assume that the address an invite is delivered to is the primary address for that person nor the intended address for their account with you. It may be useful to associate that delivered address automatically as a "secondary" address in some cases, but to insist that it be the primary on the account that results from the invite is a papercut friction for at least some of your potential users.
argee 1 days ago [-]
I've already had to add code to "normalize" addresses with dots and plusses. That should've been my first sign to move to a different design.
Rumudiez 1 days ago [-]
email addresses are not good primary or foreign keys, so yes you should be using IDs of one form or another. this shouldn't affect your authentication scheme (cookies vs bearer tokens or what have you), just authorization. if you've muddied the two, you'll have some debt to resolve and this issue could just be a valuable tip-off to that
hawtads 1 days ago [-]
I think OP is referring to the initial sign up based on an invite link, not the database storage itself.
It depends whether you want to check the invite code against the invitee's email. It very much depends on the application. For most use cases, just verifying the code is fine and accept any email addresses that posses it.
Essentially ask yourself this, if you change the UI a bit and allow any user to sign up with any email, and the workspace joining is done via a code they enter after login, is that acceptable for your product design and security posture.
Rumudiez 1 days ago [-]
okay, I have that use case as well and it is driven by an invite code. it works well for new sign-ups and existing users, and you can even just let the user copy the link and send it themselves if they're on discord or something else. no email required for pseudonymous sharing, bonus feature to send an email invite if it is given
js2 1 days ago [-]
> 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 1 days ago [-]
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 1 days ago [-]
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.
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<redactedForPrivacy@gmail.com>: 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 icloudadmin@apple.com (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 icloudadmin@apple.com"
}
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 24 hours ago [-]
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. hello_world_0a@icloud.com -> real@icloud.com
2. hello_world_0a@icloud.com -> real@example.com 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 23 hours ago [-]
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 22 hours ago [-]
> 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 real@icloud.com 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 21 hours ago [-]
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.
Looks like that was the original article, which didn't have much details about how the exploit worked.
> 404 Media is not revealing the exact details of the vulnerability because it can still be exploited as of Monday, when 404 Media verified the issue with one of our own hidden email addresses.
However, based on the current article:
> 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. “We don't know how often hidden email addresses were leaked in email logs. For many major email hosts, the leak was triggered simply by an email being automatically rejected as spam, even if it was a legitimate message. Such emails probably didn't make it to your inbox, so you can’t review your spam folder to learn whether you were affected,” Murphy and EasyOptOut co-founder Ben Weiner said in a new statement.
My guess is that if an e-mail was rejected as Spam, the response had the actual e-mail included. However, based on the next paragraph:
> “The bug that caused Apple's Hide My Email to leak hidden email addresses to senders has been fixed. However, we don't think the risk to Hide My Email users has been eliminated. Because non-malicious emails could bounce, revealing your hidden email address, and because mail transfer logs are often retained, we'd assume that any hidden email address linked to a Hide My Email address created before July 7, 2026, may have been exposed and could still be in third-party logs,” they added.
It seems even bounced e-mails could leak your actual e-mail.
nashashmi 1 days ago [-]
What about requesting delivery receipts? That could trigger an auto-send from the masked email service.
lapcat 1 days ago [-]
> Apple told 404 Media it deployed a patch for the issue on July 3, which the company says has fully resolved the issue.
> 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.
I would note that Mac Mail app (I haven't tested iOS Mail) still has an Apple Account email address disclosure vulnerability, though this requires the user to reply to a maliciously crafted email. The vulnerability affects all users of Mail app, even if they don't use Hide My Email! https://lapcatsoftware.com/articles/2026/7/9.html
philipwhiuk 1 days ago [-]
> The vulnerability affects all users of Mail app, even if they don't use Hide My Email!
If they don't use "Hide My Email" trivially replying discloses their email?
layer8 1 days ago [-]
It will disclose your Apple account address even when you received the email on a different account in the Mail app.
1 days ago [-]
hulitu 15 hours ago [-]
> Apple Fixes ... After ... Media Coverage
Like always. Apple fixes vulnerabilities _if_ and _after_ they are publicly published.
sitzkrieg 1 days ago [-]
apple privacy is mostly marketing proven again
dzhiurgis 16 hours ago [-]
Kinda. Whenever I try to use hide my email on any more of a serious service - it never registers me.
Now, this of course fails with “hide my email”. What’s the appropriate/standard way to handle this? Should I be using urls with invite codes instead of associating the email itself with access? I’m a little hesitant to do that since the code would have to persist in session and the business logic would have to occur on the login portal, since the mobile/desktop apps don’t share web cookies. Is deep linking the answer?
You could implement read-only access to a workspace via a generated link (containing a UUID or similar), like e.g. a Dropbox link. You would store the link IDs with the workspace, and you can implement (user-configurable) link expiration and such. Since links are shareable, these wouldn't be personalized to the recipient. A recipient who wants more than read-only access would still have to create an account with you and ask the workspace owner for write access.
Thanks, that makes sense as a rule of thumb. I'll move towards invite code (and work domain/SSO) based access. It's also a bit awkward to be able to add existing users to a workspace without any sort of confirmation, so my system needs a bit of rework regardless.
That's eternally a frustrating experience. It ranks among the reasons I groan every time someone asks if we can meet in Google Meeting instead of other options.
That's just dealing with one large giant of a company who you would think if anyone would have the software resources to truly untangle email addresses from account assumptions, they would have more than enough resources available.
Lots of little papercuts like that exist everywhere else. I have multiple accounts with various "Pledge Managers" because I gave Kickstarter a specific filtered address but still tend to respond to surveys and other things sent more directly to me with my primary email address. "For my convenience" most of these "Pledge Managers" tie their accounts to whatever email address they get from a Kickstarter export spreadsheet and then assume that each email address is 1:1 useful for marking an account as mine. It's often easier to juggle a bunch of reminder notes in my Password Manager which campaign is with which account with which "Pledge Manager" than to unify accounts. It becomes the opposite of convenience.
I've seen the same thing happen with + addresses, not just custom addresses at custom domain addresses. Add a + to a signup to get autofiltering when you sign up for a service and most services see `accountname+filter@gmail.com` as a different email address than `accountname@gmail.com`. Which is the correct behavior because `+` filtering is a convention not a guarantee/standard. But it again adds complexity in these sorts of "auto-invites" when you are trying to auto-correlate based on specific email address.
It seems important to me to not assume that the address an invite is delivered to is the primary address for that person nor the intended address for their account with you. It may be useful to associate that delivered address automatically as a "secondary" address in some cases, but to insist that it be the primary on the account that results from the invite is a papercut friction for at least some of your potential users.
It depends whether you want to check the invite code against the invitee's email. It very much depends on the application. For most use cases, just verifying the code is fine and accept any email addresses that posses it.
Essentially ask yourself this, if you change the UI a bit and allow any user to sign up with any email, and the workspace joining is done via a code they enter after login, is that acceptable for your product design and security posture.
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.
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.
I tested on July 2 when the original submission was made: https://news.ycombinator.com/item?id=48767855
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.
1. hello_world_0a@icloud.com -> real@icloud.com
2. hello_world_0a@icloud.com -> real@example.com 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.)
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.
I don't think so because when I examine the headers of an HME delivered message to my real@icloud.com 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.
> 404 Media is not revealing the exact details of the vulnerability because it can still be exploited as of Monday, when 404 Media verified the issue with one of our own hidden email addresses.
However, based on the current article:
> 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. “We don't know how often hidden email addresses were leaked in email logs. For many major email hosts, the leak was triggered simply by an email being automatically rejected as spam, even if it was a legitimate message. Such emails probably didn't make it to your inbox, so you can’t review your spam folder to learn whether you were affected,” Murphy and EasyOptOut co-founder Ben Weiner said in a new statement.
My guess is that if an e-mail was rejected as Spam, the response had the actual e-mail included. However, based on the next paragraph:
> “The bug that caused Apple's Hide My Email to leak hidden email addresses to senders has been fixed. However, we don't think the risk to Hide My Email users has been eliminated. Because non-malicious emails could bounce, revealing your hidden email address, and because mail transfer logs are often retained, we'd assume that any hidden email address linked to a Hide My Email address created before July 7, 2026, may have been exposed and could still be in third-party logs,” they added.
It seems even bounced e-mails could leak your actual e-mail.
> 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.
I would note that Mac Mail app (I haven't tested iOS Mail) still has an Apple Account email address disclosure vulnerability, though this requires the user to reply to a maliciously crafted email. The vulnerability affects all users of Mail app, even if they don't use Hide My Email! https://lapcatsoftware.com/articles/2026/7/9.html
If they don't use "Hide My Email" trivially replying discloses their email?
Like always. Apple fixes vulnerabilities _if_ and _after_ they are publicly published.