Bad outgoing attachments received by Office 365

[vaiadubai]

Hello,
I have a recent problem regarding outgoing attachments directed to Office 365 Pro Plus (Outlook 2016).

I always sent correct attachments with Thunderbird to mail client like Lotus Notes, or IBM Notes.

Recently some workmates moved to Office 365 and, when I send them some attachments like pictures,
they visualize badly because the original attachment arrives slightly bigger in size respect
to the original: in some points of the original file is inserted the byte '0xD'.

If the same file is sent to Office 365 from Gmail, the attachment arrives identical.

Reading some forums I tried to change some points of the Configuration Editor but with no result.

Did someone encounter the same problem?

[tanstaafl]

Is https://social.technet.microsoft.com/Fo ... 016ITProIT a similar thread you created in a Office forum?

Is mail.content_disposition_type set to 1 (the default value, saying send it as a real attachment rather than a inline attachment)?

If you use view -> message source or control->U to look at the raw message source what are the headers for the attachment? Its after the message body. For example:

Content-Type: image/jpeg; name="zombie-manger-491x500.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="zombie-manger-491x500.jpg"

is the headers for a jpeg attachment. Its followed by a big block of characters all run together (base64 encoded data, which you don't need to copy&paste).

[vaiadubai]

Yes, I first asked Office Team because the matter seemed to be bound to Office 365, but it's still uncertain.

The flag mail.content_disposition_type is 1 like in the default configuration: I changed other flags in the first tries,
but I can take them back to the original values.

The attachment header has the following look:

--------------DD640021A2F7825C3B37C761
Content-Type: image/jpeg;
name="workpoint.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="workpoint.jpg"

[tanstaafl]

--------------DD640021A2F7825C3B37C761 is a boundary string (not really a header), used to help identify the different parts of a message. It's value will change in every message. I assume the headers were identical if you sent the same message from gmail webmail.

I assume the extra characters occur only in the recipients copy since there was no problem sending it to some other email clients. That makes me suspect the attachment was sent correctly, but for some reason Office365 either mis-interpreted it or corrupted it. However, the headers look fine. I had originally thought there might have been a problem with the Content-Type header.

I found a old thread at https://answers.microsoft.com/en-us/mso ... 235ad7497c where "It seems a similar problem had occurred before something to do with ascii and carriage returns being read wrongly by older outlooks and one post even saying it was a known issue is some versions of Outlook 2010 and 2013 but no resolution". The attachments were corrupt when downloaded through Office365 but if the recipient opened the same message using webmail they were fine. It was suggested that the Outlook profile was corrupt but it turned out the problem was due to Apples .me accounts. Using .icloud.com instead solved the problem.

Are the recipients running Office365 on Windows or MacOS?

"Recently some workmates moved to Office 365 and, when I send them some attachments like pictures,
they visualize badly "

Would it be possible to have one of them try to read the same message using a different email client or webmail to verify that message was sent correctly and the problem is that Office365 doesn't like something about it? It would also be useful to see if the same problem occurred using Office365 if they temporarily disabled all add-ons. https://www.technibble.com/forums/threa ... 016.71777/ for example traced a problem with corrupt attachments to the recipient using Adobe’s Send and Track add-in in Outlook.

[vaiadubai]

Sorry for the delay in the answer, but I made further tests in these days.

Well, when the attachment is received badly, is the same in Windows client, Web Access and Android App.

I probably found which is the first motivation of the bad received attachments: supposing that the workmates
have an address of the type "workmate@company.com", the error seems to happen when in my Thunderbird account I set the field Email address for example with "myself@company.com"
(expected address of the sender).

If in the same field Email address I set the value for example "myself@company.org" (purposedly and slightly
modified string after the @), the attachment arrives correct.

This is a working workaround at the moment: the workmates see a slightly modified Email sender, but I can set
the correct address "myself@company.com" in the field "Answer to this e-mail", so they can reply me.

At present it seems an Office issue, because the same error happens having sent the mail from 3 different PCs.

If you think other tries to make, I can try when I have time.

[tanstaafl]

Weird. Glad you found a workaround. However, I'm surprised your company has both a .com and a .org domain for email.

[vaiadubai]

In fact the company has only domain .com, and .org is only an example of a purposedly mispelled name
in order to make work the attachment.
The name could be also .comm or whatever