CODEWITHSUNDEEP
c#vstooutlook-addinoffice-interop
GovZ
GovZ

Reputation: 283

BUG: Emails sent with 'eml' file attachments (via Outlook Interop APIs) are not properly encoded

Currently we have a VSTO application which uses the (Outlook) Primary interop assemblies. Fundamentally the code is something like this :

private void AddAttachment()
{
    Outlook.MailItem mail = this.Application.CreateItem(Outlook.OlItemType.olMailItem) as Outlook.MailItem;
    mail.Subject = "My EML file attachment";
    mail.Attachments.Add("a_valid_eml_file.eml", Outlook.OlAttachmentType.olByValue, 1, attachment.FileName);
    mail.Recipients.Add("GovZ R");
    ((Outlook._MailItem)mail).Send();
}

The above code works perfectly for almost all of our end users. When these end users receive the sent-email, they will receive an eml file named "a_valid_eml_file.eml". When they download the received email, and save it as an eml file, the eml file will show something like this :

A. WORKING SCENARIO

In most of our users, the email they received (which they saved as an eml file), will have the following sequence when they open it in a text editor. The snippet below is how "a_valid_eml_file.eml" is incorporated in the sent email :

--B_3705415540_1653959801
Content-type: application/octet-stream; name="a_valid_eml_file.eml";
 x-mac-creator="4F50494D"
Content-ID: <[email protected]>
Content-disposition: attachment;
    filename="a_valid_eml_file.eml"
Content-transfer-encoding: base64

UmVjZWl2ZWQ6IGZyb20gSEswUFIwMU1CMjc1NS5hcGNwcmQwMS5wcm9kLmV4Y2hhbmdlbGFi
cy5jb20NCiAoMjYwMzoxMDk2OjIwMzo5Yjo6MTkpIGJ5IFNHMlBSMDFNQjMxODkuYXBjcHJk
MDEucHJvZC5leGNoYW5nZWxhYnMuY29tDQogd2l0aCBIVFRQUzsgV2VkLCAyNCBNYXIgMjAy
................

In the above scenario, the headers are properly formed, and transfer-encoding is set to base64. Moreover, the actual payload in the attachment eml is the base64-encoded content of the 'a_valid_eml_file.eml' attachment file. The above scenario is the expected behavior.

B. NON-WORKING SCENARIO -

With the same code, however, there are a few cases where the code does not work properly. When recipients of the email, download the email as an eml file and view it on a text editor, they have the following :

--B_3705415540_1653959801
Content-type: application/octet-stream; name="a_valid_eml_file.eml";
 x-mac-creator="4F50494D"
Content-ID: <[email protected]>
Content-disposition: attachment;
    filename="a_valid_eml_file.eml"
Content-transfer-encoding: base64

Received: from HK0PR01MB2755.apcprd01.prod.exchangelabs.com
 (2603:1096:203:9b::19) by SG2PR01MB3189.apcprd01.prod.exchangelabs.com
 with HTTPS; Wed, 24 Mar 202 
..................................

Please take note that the above snippet indicates a Content-transfer-encoding of 'base64', but the content of the attachment was never Base64-encoded.

Has anybody experienced the same issue using the Outlook Interop APIs? What possibly could have caused the non-encoding of data for some of our users?

Thank you all very much.

Upvotes: 1

Views: 685

Answers (1)

Eugene Astafiev
Eugene Astafiev

Reputation: 49445

It seems somebody is changing the attached item in the middle of email travelling. So, two cases are possible:

  1. A corrupted file is attached on the sender's side.
  2. An attached file is altered somewhere.

To check the what happened in the mail flow, let the Office 365 admin run a message trace and analyze the results.

Upvotes: 1

Related Questions