We send out bulk client statements to external parties each month. Some 1500 individual recipient emails with PDF attachments.
The information provided to me was all the attachments were missing for the recipients. They received the emails but no attachment.
The emails are Generated by an internal server application, communicates with an Exchange OnPrem hosted mailbox through IMAP with Modern Auth and SSL connection.
The Exchange is in Hybrid with O365 with all OnPrem emails routing to O365 for mailflow.
I checked our Exchange Online Message trace and confirmed the emails had the attachments in the emails. The KB size matched up including the pdf document.
Checked our Forcepoint Mailcontrol which all outbound mail traverses through and also noted the attachments were present.
Once the emails leave FP they are traversing the internet which is out of our control on how they are handled or received.
Next we looked at recipient domains and mail servers to see if there was a commonality. There was not. iCloud, Bigpond, gmail, hotmail, yahoo.
They can't all be stripping the email attachments unless there was a suspected code or virus false alert.
Normally this would stop the email entirely at the recipients mail server and not deliver the email. Not just remove the attachment.
Qualifying questions were asked at this point.
Is there a common device these emails are being opened on?
Answer: Yes, iphone and iPad.
Q: Has anyone reported the issue with an Android device.
A: No
Q: Can these be opened in a web browser or Outlook.
A: Yes.
Huzzah! The issue is not that the attachments have been stripped from the email. The recipients cannot open the attachments or see the attachments on IOS devices.
The email has a paperclip icon but in the body of the email the attachment icon is not showing to select.
We narrowed this down to users who only have the native inbuilt IOS email client. If they are using Outlook or other email clients the issue does not occur.
Utilising an iPhone with a personal email setup in the native client. We sent an email from the Application with attachment AND from OWA from the onPrem mailbox.
Opening both emails in notepad (or notepad++) we can do a comparison of the two emails and how they are generated.
Located the following:
the Application generated email coding footers that is failing is shown as below:
Content-Type: application/octet-stream;
name="attachment.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment
If an email is sent with the correct below MIME data, the attachment is viewable.
Content-Type: application/pdf; name="attachment.pdf"
Content-Description: attachment.pdf
Content-Disposition: attachment; filename="attachment.pdf";
size=418459; creation-date="Thu, 02 Nov 2023 04:57:58 GMT";
modification-date="Thu, 02 Nov 2023 04:57:58 GMT"
Content-Transfer-Encoding: base64
We believe the email generation and attaching of the pdf is not correctly classifying the content-type class as application/pdf or including the correct content-disposition information or content-description.
This is resulting in IOS devices with the Native Email application not being able to open the pdf attachment.
vThe Content Type of application/octet-stream Directs the email application that the attachment is a binary file. This is incorrect.
Application developer has been notified and has updated the application to follow the correct MIME formatting process that the IOS native client requires.
Possible Alternative Solution: (Not personally tested)
If the Dev can't/won't make the change, or you need to resolve this promptly. I have an alternative solution.
In O365 Exchange Online, Transport rules.
Create a new transport rule. Only apply to emails sent from the specified email address.
In this case, this account only sends emails with attachments for one purpose.
Have the transport rule update the application/octet-stream with application/pdf in the headers/footers.