A while ago I noticed a new warning in the Apple iOS Mail App that appears if you get an email from one email address, the reply-to header is set to a different email address and the display names are identical between both headers.
This warning is curious. I couldn’t find any information from Apple about it, and pretty much nobody posted about it online. There are a few Reddit threads about this warning with concerned users, some who may have misinterpreted the warning (1, 2, and 3).
Here is what that looks like. 
Notice the “?” next to the “Reply To” name. If you tab this question mark, you will receive the following warning: “The email address you’re replying to does not match the original address”
If the display name – in this case “Whatever” – is different, then the warning is not shown.
Having a different From and Reply To header set, is not something unusual. Mailing lists usually do this, and ticket systems do this as well.
It can be argued, that they should in those cases set a different display name.
Apple appears to believe, that having hit reply with the intention to directly replying to the person who has sent the email, but responding to a different email address through the reply-to header, is something that warrants this warning.
Naturally I tried to circumvent this warning.
After a bit of trial and error the following email was in my inbox:
As it may appear, the name is identical and the warning is not shown.
The email addresses in both headers are however different.
The display name of the From header includes a newline and additional text (“Invisible”). In this view the newline is not rendered.
If the message is displayed in the inbox view, the name is suffixed with “…” as there is not enough space to display the two-line name. 
Additionally, if you tab on the name of the From line, it will display the full name.
But in the message view – the view you are most likely be in if you plan to reply – no indication is given that the name is different.
To “inject” the newline, I used the encoded-word syntax, so the headers look like this:
From: =?iso-8859-1?b?V2hhdGV2ZXIKSW52aXNpYmxl?= <test@example.com> Reply-To: Whatever <test@example.org>
Notice that the domain is different (.com vs .org) in both headers.
The encoded-word syntax is basically Base64 encoding. The V2hhdGV2ZXIKSW52aXNpYmxl part decodes to:
Whatever Invisible
It should be noted that only the From header display name can be manipulated. Since there is space under the reply to header, manipulating it would look like this:
Using tricks like adding white-spaces to create display names that look alike did also not work. In these cases the warning was also shown.
In my tests the display names strings had to be different. Using a newline was the best solution to circumvent the warning I could find.
Realistic scenario?
It is hard to tell if there is a realistic scenario in which circumventing this warning poses a real threat to a user. Especially since the warning is generally not well documented, so a user would not depend on it being displayed.
Spear Phishing could possibly use this. In that case the Phishing mail is sent out using a manipulated From header due to incorrect or missing SPF and DMARC settings. That way, a known email address is spoofed.
Adding the external reply to address with the same display name might help the attacker getting a response back from the target.
Avoiding this warning may help the user not noticing that it is a Phishing mail.
Apples response
Despite having not so great success with reporting bugs to Apple, I tried it again and reported this issue on 2024-04-22 through their new and fancy bug bounty web interface.
At some point the issue was moved into the “being reviewed” state. After that I heard nothing back.
Today I manually checked the bug bounty platform and the report was closed – apparently you do not get an email notification for that.
Since Apple was “unable to identify a security issue” in my report, I’m disclosing this non-security issue publicly today.
