From: anyone@icloud.com - Spoofing Arbitrary Apple iCloud Identities

01.10.2026

research vulnerability

A case study on discovering two email spoofing vulnerabilities in Apple iCloud.

(Image illustration, partially AI-generated)

In the course of a research project in collaboration with the SEC Consult Vulnerability Lab, Timo Longin (@timolongin) - known for SMTP smuggling - discovered two exotic email spoofing vulnerabilities in Apple iCloud's emailing infrastructure.

At the end of 2023 SMTP smuggling made a dramatic entrance, allowing email spoofing for millions of email servers worldwide. Ever wanted to send emails as admin@outlook.com while still passing SPF checks? SMTP smuggling had you covered!

However, in 2024, most SMTP implementations adapted, and released security updates for their software. Does this mean the end of SMTP smuggling? Or does this attack have more to offer?

Let's dive into a case study of Apple iCloud's SMTP parsing jungle and try to spoof emails once more!

Note: This blog post is related to SMTP Smuggling - Spoofing E-Mails Worldwide. For additional contextual and background information, we recommend reading it first.

1. TL;DR

Even though no novel techniques for traditional SMTP smuggling were discovered, a subclass of email spoofing was explored - header smuggling. Again highlighting the parsing discrepancies in SMTP implementations, header smuggling builds upon the lessons of its bigger brother SMTP smuggling. Based on a case study of Apple iCloud's emailing services, we once again reveal the dangers of trusting emails by being able to send messages from arbitrary icloud.com addresses.

2. SMTP Smuggling Recap

First of all, let's have a short recap on SMTP smuggling. With traditional SMTP smuggling, we exploited interpretation differences of the SMTP protocol between outbound (sending) and inbound (receiving) SMTP servers. More specifically, we capitalized on the fact that lots of SMTP implementations deviated from RFCs, leading to different understandings of the so-called end-of-data sequence. Since the end-of-data sequence indicates where the message data ends, we could achieve the following between vulnerable outbound and inbound SMTP servers (figure 1).

Now, as mentioned, this concept gets explained in detail in the original SMTP smuggling blog post. As also mentioned, this should theoretically no longer work since 2024. With SMTP implementations like Postfix, Sendmail, Exim, and more being fixed (see smtpsmuggling.com), we must find new ways to smuggle emails. Fortunately, we have a huge bag of tricks!

3. SMTP Smuggling Reloaded?

When trying to find vulnerabilities that are based on interpretation differences in a vast protocol like SMTP, options are seemingly endless. From differing data encodings to how message data lines get handled, everything looks like a promising target. To get a rough understanding of what "promising" might be, here are some of the ideas:

• Attacking the data conversion between DATA and BDAT and vice versa
• Reflecting dangerous end-of-data sequences via bounce messages
• Exploiting the handling of long lines (>1000 characters) to inject rogue <CR><LF> sequences
• Creating or removing dot characters by exploiting non-compliant RFC behavior
• Digging down into minuscule parsing differences in proprietary SMTP implementations
• Analyzing complex internal SMTP sending architectures

Then, after weeks of analysis, we can proudly look at the results and see that NOTHING worked. None of the approaches above as well as none of the hundreds of attempted test cases allowed us to break out of the data section and smuggle SMTP commands. Bummer...

However, before dropping the idea of SMTP smuggling completely, another visit to the drawing board was necessary.

4. The "From" Header

With SMTP smuggling, we are trying to escape the message data section to be able to execute SMTP commands for a second email. But actually, we don't have to do that to be able to spoof the sender address. This is because most receivers do not view the sender address from the SMTP MAIL FROM command as the sending address, but the address from the From header, which is part of the message data. Hence, if we can spoof the From header, we can spoof the sender address!

However, things are not that simple. Let's look at the example below (figure 2).

Here we are trying to send an email as admin(at)icloud.com, even though we authenticated to the iCloud SMTP service as user(at)icloud.com. Since Apple only wants us to send with our own email address (user(at)icloud.com), this will be blocked with the following error message:

5.7.0 From address is not one of your addresses

It's worth noting that such authentication checks are not mandated by SMTP itself. It's a proprietary check each email provider enforces (or doesn't) on their own. However, solutions for open-source SMTP software like Postfix exist (see MilterFrom). 

So, if changing the From header is not possible, how would we spoof it? This is the point where a lot of research has already happened in the past, with one of the bigger publications being Weak Links in Authentication Chains: A Large-scale Analysis of Email Sender Spoofing Attacks from 2021. In 2024, security researcher @slonser_ has also shown ways to make exactly this possible. And just recently in 2025, Hao Wang (@MrRed_Panda) and Caleb Sargent (@squared_) got this formalized as CERT/CC vulnerability note VU#517845, covering ambiguous From header interpretation across major providers. The general approach is very similar to what we have had with SMTP smuggling: interpretation differences.

For instance, @slonser_ managed to send emails from any @gmail.com address to SMTP services like Outlook, by exploiting how alias names (aliases for the sender address) in the From header get parsed (figure 3).

In this case, Gmail thinks that the From header indicates user(at)gmail.com as sender address, allowing the email to be sent. However, when Outlook receives this email, the From header is parsed with admin(at)gmail.com as the sender address.

Now, with all of this research already done, what is there left to be discovered? Well, with our extensive knowledge on smuggling all kinds of things in the SMTP world, we can take From header spoofing for another ride!

5. From Header Smuggling @ iCloud - Line Breaks

In traditional SMTP smuggling, we were dealing with carriage returns <CR> and line feeds <LF> in end-of-data sequences <CR><LF>.<CR><LF>. But why stop there? For example, how would SMTP servers react, if we would send bare <LF> or <CR> characters as line breaks in the message data, instead of <CR><LF>? The answer is: Differently!

Some SMTP implementations follow RFC 5321 section 2.3.8 and RFC 5322 section 2.3 when transmitting emails, which state that bare <LF> or bare <CR> characters MUST NOT be transmitted independently, others don't.

While looking at SMTP software in the testbed (see FAQ), something interesting popped up for iCloud SMTP services (figure 4).

Even though it looks like two From headers were specified on email submission, one of them contains <CR> characters before and after the colon. On authentication, the first From header containing the <CR> characters gets ignored, and the second From header is used for matching with the email address of the authenticated user. At this point, something strange happens inside of iCloud's SMTP services. The <CR> characters get stripped from the first From header and the email gets forwarded to the receiving inbound SMTP server containing two legitimate From headers. How did that happen?

5.1. iCloud Parsing Internals

Based on the observed behavior, we can assume the following internal SMTP infrastructure after an email gets sent to the iCloud submission servers at smtp.mail.me.com on port 587 (figure 5). For simplicity, we are calling them parser 1 and parser 2:

Derived from message parsing and message signatures, it is likely that parser 2 is based on Postfix. Since software for From header checks is largely custom-made, it is unclear how parser 1 works internally.

5.2. You got mail!

Even though we can now send an email with a From header having the value admin(at)icloud.com, most inbound receivers won't allow multiple From headers in the message data (see RFC 5322 section 3.6). In theory, we must find a mechanism that makes parser 1 see the legitimate From header to pass authentication, and that hides the legitimate From header from parser 2. In practice, we can further abuse <CR> characters. Since parser 2 replaces standalone <CR> characters with <CR><LF>, we can push the legitimate From header (From: user(at)icloud.com) into the message body, where it will no longer be interpreted as a header. Let's see how this can be done (figure 6).

When parser 2 is done, we get mail! (figure 8)

Figure 8: Receiving an email from admin@icloud.com

Since we are smuggling a Content-Type: multipart/alternative header, we can narrow down the parts that are shown on the receiver side to data between the boundary-string markers. Since the smuggling header stops with --boundary-string--, which indicates the end of the multipart content, everything after will be ignored. Another interesting part about this vulnerability is not only that it works for arbitrary inbound SMTP servers, but that it also passes SPF and DKIM checks, hence also passing DMARC (see figure 9).

Figure 9: Passing SPF, DKIM and DMARC security checks

So, why does DKIM, a cryptographic signature mechanism, pass, even though the message was heavily altered by message parsing/normalization?

In this case, DKIM verification passes, since DKIM signatures are created after parser 2 processed the message, just before the email gets sent to the inbound server. If the DKIM signature would be created at parser 1, DKIM signature verification would most likely fail.

Anyway, to make sure that this is not a fluke, here's an email from Apple's former CEO Tim Cook by spoofing tim.cook(at)icloud.com (could also be any other @icloud.com email address (e.g., no-reply@icloud.com)) (see figure 10 and figure 11).

Figure 10: Spoofed email from tim.cook@icloud.com

Figure 11: Spoofed email from tim.cook@icloud.com passing SPF, DKIM and DMARC security checks

6. From Header Smuggling @ iCloud - Dot-Peeling

Trying to remediate the previous parsing issue, Apple eventually adapted parser 1 (see Disclosure Timeline) to be stricter in terms of From header parsing. Headers like From\r:\radmin@icloud.com now get parsed as an actual From header and thus fail authentication. If a header starts with "From", this most likely won't allow us to find interpretation differences between parsers 1 and 2. Can we still bypass this?

We know that parser 1 and parser 2 work inherently differently, so we take another look at some SMTP RFCs. For our scenario, there is a set of rules that seems to work nicely with what we are trying to achieve: dot-stuffing.

Dot-stuffing is defined in RFC 5321 section 4.5.2 and says the following:

1. Adding dots
   Before sending a line of mail text, the SMTP client checks the
   first character of the line. If it is a period, one additional
   period is inserted at the beginning of the line.
2. Removing dots
   When a line of mail text is received by the SMTP server, it checks
   the line. If the line is composed of a single period, it is
   treated as the end of mail indicator. If the first character is a
   period and there are other characters on the line, the first
   character is deleted.

Since parser 1 doesn't honor these rules, the following exploit allows us to "peel" dots (see figure 12):

As a final proof-of-concept, here is another email from tim.cook(at)icloud.com (figure 15 and figure 16).

Figure 15: Spoofed email from tim.cook@icloud.com via dot-stuffing/peeling

Figure 16: Spoofed email from tim.cook@icloud.com passing SPF, DKIM and DMARC security checks

7. Detectability and Defense

Even though we managed to bypass From header authentication, the methods we used still leave some traces that a careful analyst or provider-aware filter might notice. The raw email contains the following "indicators" for the original email address (e.g., attacker(at)icloud.com):

ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@icloud.com header.s=1a1hai header.b=eUsqthuD;
spf=pass (google.com: domain of attacker@icloud.com designates 17.57.155.19 as permitted sender)
smtp.mailfrom=attacker@icloud.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=icloud.com
Return-Path: <attacker@icloud.com>
Received: from qs51p00im-qukt01080102.me.com (qs51p00im-qukt01080102.me.com. [17.57.155.19])
by mx.google.com with ESMTPS id d75a77b69052e-46e66b61d89si95295111cf.213.2025.01.27.08.16.06 for
<receiver@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 27 Jan 2025 08:16:06 -0800 (PST) Received-SPF: pass (google.com: domain of attacker@icloud.com
designates 17.57.155.19 as permitted sender) client-ip=17.57.155.19;
Authentication-Results: mx.google.com; dkim=pass header.i=@icloud.com header.s=1a1hai header.b=eUsqthuD;
spf=pass (google.com: domain of attacker@icloud.com designates 17.57.155.19 as permitted sender)
smtp.mailfrom=attacker@icloud.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=icloud.com

Since usually there is no mismatch between the envelope MAIL FROM address (Return-Path) in emails coming from iCloud, this could be flagged by some heuristics. However, as it is, this is a legitimate and authenticated email.

8. Responsible Disclosure

The process of disclosing non-standard email parsing issues takes time. After roughly one and a half years of back and forth communication, we finalized the disclosure with Apple.

Apple didn't take this issue lightly. They rewarded a $15,000 bounty for the discovery of these vulnerabilities. (see figure 17).

Figure 17: Apple bug bounty

This not only demonstrates great appreciation for this kind of research, but may also lay the foundation of a new bug bounty branch. Emailing is widely used in phishing attacks and scams, yet spoofing vulnerabilities are often out-of-scope or not considered dangerous enough. Such bug bounties could convince other providers to take these reports more seriously, and be an incentive to bring new researchers/bug hunters into the field.

9. Conclusion

Whether SMTP smuggling or smuggling inside of SMTP, parsing issues in old and complex protocols like SMTP will always remain. This research again highlights how hard SMTP is to parse, yet how easily it can be exploited. For Apple's iCloud SMTP services, we've looked at two different cases of email spoofing that are rooted in ambiguous parsing in parts of Apple's own infrastructure.

As previous research shows, this is not an isolated case. From large-scale analysis to independent researchers finding new bypasses year after year, spoofing keeps resurfacing across providers, old and new alike. This post adds two more examples to that pattern and proves that even mature, heavily used email infrastructure can be exploited to undermine sender identity entirely. Unfortunately, based on what was discovered so far, this is unlikely to be the last stop on this journey. Sender identity in emailing will most likely remain far less solid than most users assume.

10. FAQ

Does that mean legacy SMTP smuggling is all fixed and no longer possible?

With the vulnerability being released at the end of 2023, lots of SMTP implementations fixed their parsing issues right away. However, unpatched systems, novel smuggling approaches, and smaller SMTP implementations might still be around. For more information, check out Email Spoofing with SMTP Smuggling: How the Shared Email Infrastructures Magnify this Vulnerability.

Where can I find more information about SMTP smuggling?
Here!

What SMTP software did we analyze?

We again analyzed a mixture of proprietary and open-source SMTP software hosted at email service providers or on our own servers, including:

• outlook.com
• gmail.com
• gmx.net
• icloud.com
• zoho.com
• fastmail.com
• runbox.com
• startmail.com
• mailbox.org
• aol.com
• yahoo.com
• web.de
• Postfix
• Sendmail
• Exim
• Sendgrid
• Mandrill
• Mailgun

Note that a lot of enterprise-grade solutions could not be tested.

11. Disclosure Timeline

About the author