When sending an email via ActiveSync (Outlook) that contains attachments—either by forwarding an existing email with attachments or attaching a message (.eml)—the recipient receives the email, but often the attachments are empty (0kb) or the MIME structure is flattened incorrectly, causing duplication of content or missing bodies in nested messages.
Steps to reproduce the behavior:
Configure an email account on Outlook Desktop using Z-Push ActiveSync.
Select an existing email that contains attachments or nested images.
Forward this email to another recipient (or attach it as a nested .eml message).
The recipient receives the email, but the attachment is 0-byte or corrupted.
Expected behavior: The attachments should be reconstructed correctly with the proper file size, headers, and MIME hierarchy.
Server:
OS: Linux
PHP Version: 8.3
Backend for: IMAP
Z-Push Version: 2.7.5
IMAP/SMTP Server: Dovecot 2.3.20 / Qmail 1.03
SMTP Capabilities: ESMTP with 8BITMIME supported.
Client:
Device: Notebook HP 240 G4
OS: Windows
App: Outlook
Version: 2511
Additional context:
I have analyzed the code in the IMAP backend (backend/imap.php) and found the root causes. I had to patch two functions to fully resolve the issue: add_sub_part and add_extra_sub_parts.
-
The 0-byte Attachment Issue (add_sub_part) The function add_sub_part copies headers from the original message blindly, specifically Content-Length. When Z-Push reconstructs the MIME message (e.g. converting a part to base64), the payload size changes. However, because the old Content-Length header is preserved and copied to the new part, the receiving client/MTA sees a mismatch between the declared length and the actual data, resulting in a truncated or 0-byte attachment. Fix: I modified the loop to exclude/blacklist Content-Length and Content-Transfer-Encoding, allowing the PEAR Mail_mime library to calculate the correct new headers.
-
The Structure/Hierarchy Issue (add_extra_sub_parts) The logic flattened the MIME structure, ignoring multipart containers in the root and treating message/rfc822 incorrectly. This caused nested .eml attachments to lose their body text or, conversely, allowed internal parts of a forwarded message to "leak" into the main body (duplication). Fix: Updated the recursion logic to respect multipart containers properly and pass a context flag ($inside_container) to preserve the structure of nested messages while preventing duplication in the root.
When sending an email via ActiveSync (Outlook) that contains attachments—either by forwarding an existing email with attachments or attaching a message (.eml)—the recipient receives the email, but often the attachments are empty (0kb) or the MIME structure is flattened incorrectly, causing duplication of content or missing bodies in nested messages.
Steps to reproduce the behavior:
Configure an email account on Outlook Desktop using Z-Push ActiveSync.
Select an existing email that contains attachments or nested images.
Forward this email to another recipient (or attach it as a nested .eml message).
The recipient receives the email, but the attachment is 0-byte or corrupted.
Expected behavior: The attachments should be reconstructed correctly with the proper file size, headers, and MIME hierarchy.
Server:
OS: Linux
PHP Version: 8.3
Backend for: IMAP
Z-Push Version: 2.7.5
IMAP/SMTP Server: Dovecot 2.3.20 / Qmail 1.03
SMTP Capabilities: ESMTP with 8BITMIME supported.
Client:
Device: Notebook HP 240 G4
OS: Windows
App: Outlook
Version: 2511
Additional context:
I have analyzed the code in the IMAP backend (backend/imap.php) and found the root causes. I had to patch two functions to fully resolve the issue: add_sub_part and add_extra_sub_parts.
The 0-byte Attachment Issue (add_sub_part) The function add_sub_part copies headers from the original message blindly, specifically Content-Length. When Z-Push reconstructs the MIME message (e.g. converting a part to base64), the payload size changes. However, because the old Content-Length header is preserved and copied to the new part, the receiving client/MTA sees a mismatch between the declared length and the actual data, resulting in a truncated or 0-byte attachment. Fix: I modified the loop to exclude/blacklist Content-Length and Content-Transfer-Encoding, allowing the PEAR Mail_mime library to calculate the correct new headers.
The Structure/Hierarchy Issue (add_extra_sub_parts) The logic flattened the MIME structure, ignoring multipart containers in the root and treating message/rfc822 incorrectly. This caused nested .eml attachments to lose their body text or, conversely, allowed internal parts of a forwarded message to "leak" into the main body (duplication). Fix: Updated the recursion logic to respect multipart containers properly and pass a context flag ($inside_container) to preserve the structure of nested messages while preventing duplication in the root.