I’ve recently moved my mail server to Stalwart 0.16.20 and I’m seeing a strange issue with POP3 on an iPhone.
The server is working normally for POP3 with other mail clients. However, when the account is configured as POP3 in Apple Mail on the iPhone, messages arrive but appear essentially empty. Apple Mail displays something along the lines of:
“No Subject”
“This message has not been downloaded from the server”
I’ve noticed that plain-text-only messages are fine. The problem seems to occur with messages containing HTML/MIME content.
The same messages can be retrieved successfully using other mail clients, so the messages themselves appear to be OK.
I’ve also tested the same account using IMAP on the iPhone. IMAP works perfectly, including the messages that fail when using POP3. So the problem appears to be specifically with Apple Mail’s POP3 handling; IMAP is not affected.
I deleted and recreated the POP3 account on the iPhone, but the behaviour remained.
Has anyone seen this behaviour with Stalwart and Apple Mail/iOS POP3?
Could there be something about the MIME structure, headers, POP3 response, message encoding, line endings, etc. that Apple Mail is particularly sensitive to?
If there are any Stalwart logging/debugging options that would be useful for comparing a message retrieved successfully versus one that Apple Mail considers “not downloaded”, I’m happy to provide whatever information would help.
Thanks!
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
Based on the POP3 code in Stalwart, there’s a real possibility this is related to how the “octets” byte count is calculated versus what’s actually sent to the client.
When Stalwart serves a message via RETR, it reports +OK <n> octets where <n> is the raw stored message size. It then streams the message through a “transparency procedure” that:
inserts a \r before any bare \n that isn’t already preceded by \r (to normalize line endings to CRLF), and
byte-stuffs any line starting with a literal .
Both of these transformations can make the actual number of bytes sent larger than the <n> octet count declared in the +OK response header, because that count is taken from the message’s stored size before the transformation is applied. If a message’s stored MIME/HTML body contains bare LF line endings (common with some HTML-generating mail composers, less common in plain-text-only mail), the octet count Stalwart declares up front will be smaller than what it actually transmits.
Apple Mail’s POP3 client is known to be strict about matching the declared byte count, and a mismatch here could plausibly produce exactly the symptom you’re seeing: the message downloads but Apple Mail treats it as incomplete/corrupt and shows “No Subject” / “This message has not been downloaded from the server,” while other clients tolerate the discrepancy and IMAP is unaffected (IMAP doesn’t use this octet-count mechanism at all).
To confirm, it would help to compare the raw bytes of one of the affected messages (particularly checking for bare \n without \r in the HTML/MIME body) against a working plain-text message. If you can share (or check) whether the failing messages have non-CRLF line endings in their source, that would help pin this down further. I don’t have a documented Stalwart setting to change this behavior, so I’d treat this as something to verify and report with specifics for a maintainer to look at.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
I have the exact same issue with IMAP, and it is related to how iOS handles the processing. If I remember correctly, when an email is too large or has a heavy attachment, iOS fails to decrypt it because it hits a timeout limit. This doesn’t happen on desktop, messages that appeared empty on iOS opened perfectly fine in Apple Mail on my Mac.
Thank you for this information. Very interesting that IMAP does not work for you but is working for us!
I’ve only just cut over to my new Stalwart server this week. Prior to this, I was using a very old Postfix+Dovecot server, and of course we never encountered this issue with our POP3 iPhone clients.
We’ll try to capture some more data and see what we can find.
BTW, I installed Airmail on an iPhone and it can download and display the messages over POP3 just fine. Incredibly frustrating (Apple)!
It normally works fine with IMAP and plain text emails. However, if an email contains a non-standard PDF attachment or something else, it is not displayed in iOS Apple Mail. I was looking for a solution, but I found several posts on the Apple forum stating that this is a known S/MIME bug on IOS. Either way, I just have to wait for a proper JMAP client with S/MIME support to come out.
0.16.23 was released on 21 September. The bug was in POP3 TOP, which Apple Mail uses to fetch headers and previews: it counted the requested lines from the first byte of the message, headers included, and reported the full size even for a partial answer. Messages Apple Mail already downloaded in that state may stay empty, so test with new HTML mail after upgrading. If the old ones are still blank, removing and re-adding the account (with mail left on the server) makes it fetch them again.
