When iCloud emails go into a black hole
We were working on tracking bounces for emails sent via user’s SMTP server in preparation for Google’s move to strict DMARC policy when we came across a weird issue with iCloud addresses (@me.com, @mac.com, @icloud.com):
When sending mail via iCloud SMTP server (smtp.mail.me.com) certain emails are accepted by the server but never delivered to their recipients. No bounce notification is sent either, emails just go into a black hole and disappear without a trace.
Needless say that was very surprising to find out! SMTP server that silently drops some of your emails doesn’t inspire much confidence.
Google search didn’t bring any hints to what might be going on there so we started experimenting with iCloud SMTP server trying to isolate a factor that was causing the mysterious “black hole” effect.
Turns out, iCloud SMTP doesn’t like Message-ID headers with a local part longer than 39 characters.
Yes, it’s only 39 characters, way less than 998 or even 255 character limit for the whole Message-ID prescribed by RFC 4130. This 39 character limit doesn’t include opening “<” character, for example:
A message with that header was accepted by iCloud SMTP but never delivered to the recipients:
Message-ID: <1234567.a32699692dd251892474eac20fbe1c63@host.com>“1234567.a32699692dd251892474eac20fbe1c63” is 40-character local part of the Message-ID that is causing the message not to be delivered.
On the other hand, if local part of the Message-ID was 1 character shorter, the message was delivered successfully:
Message-ID: <123456.a32699692dd251892474eac20fbe1c63@host.com>The length of the host part of the Message-ID doesn’t seem to play any role here, only the length of the local part that matters.
On the bright side, it was very easy to fix the issue once we knew what was causing it. Hopefully this will save someone hours of troubleshooting and prevent emails not being delivered via iCloud SMTP server.
