But things like icloud, office365, google workspace and similar are "too big to fail", right? They don't have to play by the same rules as the rest of us peons.
as referenced here, from the post on the 'mailop' mailing list
https://news.ycombinator.com/item?id=43512353
This is either an astonishing level of technical fuck-up from what has to be an entire work group of people with six figure salaries whose jobs are nothing but running email server infrastructure, so they must clearly know better, or a lack of regard for the internet community and accepted standards. I really cannot think of a third possible explanation for it.
To be clear for those people who don't run their own email servers: Having proper reverse DNS for the IP of your outbound SMTP sending server is one of the absolute bare minimum requirements for accepted mail flow, and is a standard that's probably 25 years old or older now. It significantly pre-dates SPF, DKIM, DMARC and all the rest. Proper RDNS is literally one of the first things you verify before you set up everything else.
By posting on Hacker News and making it to the front page. The same support strategy also works for all the other major providers
I'm sure there's a ton of interesting surface area here.
https://www.mail-archive.com/mailop@mailop.org/msg24300.html
with a later response indicating that Apple was aware:
https://www.mail-archive.com/mailop@mailop.org/msg24312.html
I thought at first people were just ignoring me, but when a company reached out to me over SMS to respond to a complaint I had, they said their email reply had bounced so was contacting me on SMS instead
Switched to fastmail at that point.
?
The bus factor (aka lottery factor,[1][2] truck factor,[3] or circus factor[4]) is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase "in case they get hit by a bus".
Did you try postmaster@apple.com, hostmaster@apple.com, or icloudadmin@apple.com (not traditional, but given in their docs)?
Customer support is worthless for actual technical problems as usual for Apple. Fun extra regarding customer support; if you arrange a support call in a language not native to your region, they honor that, but that information is lost if they escalate the call; the callback is always in the national language, despite explicit requests over the phone during the callback schedule
The deliverability issues also apply to their Hide My Email feature. I frequently miss confirmation or verification emails after signing up with a @privaterelay.appleid.com address, so much so that I don't even bother with it anymore.
What's different?
Email has SO many technical issues that if someone would have come out with email today, nobody would use it!
The ONLY thing going for it really is that it’s decentralised and has the network effect that almost everyone uses it. Bzzzt, I kid I kid!
Anyone under 25 will tell you they do NOT use emails and instead prefer instant message, and is email really decentralised? NO!! Try setting up your own relay and you’ll be dropped by any big service. Gmail+Outlook is basically a cartel with zero recourse!
Hmmm… could there even be a case of anti-trust given Gmail’s behaviour
I just means we take RFC 821 and RFC822, then everything build on top of that flaming tire fire and send it into an orbit directly into the sun, and replace it with new open protocols that weren’t designed when the internet was a trusted network but with layers and layers of crust stacked on top in order to mitigate its shortfall
In my gmail inbox I periodically get very strange emails from mailer-daemon@googlemail.com, addressed to username+caf_=username=example.com@gmail.com
(where "username" is my gmail user, and "example.com" is the domain of a consulting client from a decade ago that gave me username@example.com)
The body of these weird messages says
Address not found Your message wasn't delivered to username@example.com because the address couldn't be found, or is unable to receive mail.
550 5.1.1 The email account that you tried to reach does not exist. Please try double-checking the recipient's email address for typos or unnecessary spaces. For more information, go to https://support.google.com/mail/?p=NoSuchUser 6a1803df08f44-6ac070f1538sor47269616d6.5 - gsmtp
above an arbitrary supposedly-forwarded message like
---------- Forwarded message ---------- From: The New Yorker Daily <newyorker@newsletter.newyorker.com> To: username@gmail.com Cc: Bcc: Date: Tue, 28 May 2024 16:31:02 -0400 (EDT) Subject: The Secrets of the Stasi ----- Message truncated -----
https://dns-lookup.jvns.ca/#p00-icloudmta-asmtp-us-central-1...
Except for my mail formatting but who cares..
I sent this more than two weeks ago:
Date: Wed, 12 Mar 2025 22:56:55 +0000 (UTC)
From: John Klos <*******@klos.com>
To: apple.com-Admin@anonymised.email, apple.com-Tech@anonymised.email, Apple-NOC@apple.com, d*******@apple.com
Subject: Issue with Apple's SMTP delivery
Hello,
I've had several issues reported about email delivery from Apple. The error they have in common is this:
Mar 12 21:38:17 daisy sm-mta[28249]: 52CLcCoi028249: ruleset=check_mail, arg1=<*******@me.com>, relay=p-west1-cluster6-host7-snip6-8.eps.apple.com [IPv6:2a01:b747:3003:204:0:0:0:47], reject=550 4.1.8 <*******@me.com>... Access denied. HELO does not resolve. (HELO p00-icloudmta-asmtp-us-west-1a-1.p00-icloudmta-asmtp-vip.icloud-mail-carry.svc.kube.us-west-1a.k8s.cloud.apple.com)
Looking in to this, the resolution of "p00-icloudmta-asmtp-us-west-1a-1.p00-icloudmta-asmtp-vip.icloud-mail-carry.svc.kube.us-west-1a.k8s.cloud.apple.com" results in this list of MX:
mx-in.g.apple.com
mx-in-mdn.apple.com
mx-in-hfd.apple.com
mx-in-ma.apple.com
mx-in-rn.apple.com
mx-in-vib.apple.com
mx-in-rno.apple.com
mx-in-sg.apple.com
All but two of these resolve to A records.
Two of those, though, resolve to more MX:
host mx-in-rno.apple.com
mx-in-rno.apple.com mail is handled by 10 mx-in.g.apple.com.
mx-in-rno.apple.com mail is handled by 20 mx-in-vib.apple.com.
mx-in-rno.apple.com mail is handled by 20 mx-in-rno.apple.com.
mx-in-rno.apple.com mail is handled by 20 mx-in-rn.apple.com.
mx-in-rno.apple.com mail is handled by 20 mx-in-hfd.apple.com.
mx-in-rno.apple.com mail is handled by 20 mx-in-sg.apple.com.
mx-in-rno.apple.com mail is handled by 20 mx-in-mdn.apple.com.
mx-in-rno.apple.com mail is handled by 20 mx-in-ma.apple.com.
host mx-in-mdn.apple.com
mx-in-mdn.apple.com mail is handled by 20 mx-in-mdn.apple.com.
mx-in-mdn.apple.com mail is handled by 20 mx-in-sg.apple.com.
mx-in-mdn.apple.com mail is handled by 10 mx-in.g.apple.com.
mx-in-mdn.apple.com mail is handled by 20 mx-in-vib.apple.com.
mx-in-mdn.apple.com mail is handled by 20 mx-in-rn.apple.com.
mx-in-mdn.apple.com mail is handled by 20 mx-in-hfd.apple.com.
mx-in-mdn.apple.com mail is handled by 20 mx-in-ma.apple.com.
mx-in-mdn.apple.com mail is handled by 20 mx-in-rno.apple.com.
This loop is a mistake and should be fixed.
Additionally, RFC 5321 section 2.3.5 says that the name given in an EHLO / HELO greeting should be an IP literal or a primary host name ("a domain name that resolves to an address RR"). The name given in the EHLO / HELO exchange does not resolve to an address RR; it only resolves to an MX. While this is technically incorrect, the looping MX is the real issue. However, if you're fixing the looping issue, you may want to consider fixing this issue at the same time.
Please look in to this, and please let me know if you have any questions or need any additional information.
Thank you,
John KlosIt’s impossible to tell from the shared page because both services are about DNS caching.