This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Some incoming messages end up with MIME content in message body (Exchange 2016, XG 17.5 MR4)

A small subset of incoming email messages are appearing in user inboxes in a strange format which I'd characterise as "MIME not decoded properly" format. For example, the first few lines of one message:

--_011_SG2PR03MB27978A7DFBD4A8CA199558A49D550SG2PR03MB2797apcp_
Content-Type: multipart/alternative;
        boundary="_000_SG2PR03MB27978A7DFBD4A8CA199558A49D550SG2PR03MB2797apcp_"

--_000_SG2PR03MB27978A7DFBD4A8CA199558A49D550SG2PR03MB2797apcp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U3VyZQ0KVGhhbmtzDQpQaWVybw0KDQoNCkZyb206IFphcmVlbiBQcmFzYWQgPFphcmVlblBAZ3Nh
aWIuY29tLmF1Pg0KU2VudDogVHVlc2RheSwgMiBBcHJpbCAyMDE5IDEwOjA4IEFNDQpUbzogUGll
cm8gQnVhIDxwYnVhQGZyZWRvbi5jb20uYXU+DQ

There doesn't seem to be any pattern to this yet; or at least none I've identified. There are no other MTAs involved - just Office 365, Sophos in MTA mode, and the internal Exchange server. Since most messages are working, I'm not even sure where to start with this or what other information will help, so any suggestions are welcomed.

Edit: There appears to be a significant difference in the SMTP headers. The "broken" email I have shows headers like this:

Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <CAE841EFD23DD34192139305BBCFBF4D@internal.domain.name>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Compare that to a working email from the same sender to the same recipients:

Content-Type: multipart/related;
	boundary="_011_87BAF6626415BF45BAFCAE4854537C6AFFF2EFDAGASSIN01gadintr_";
	type="multipart/alternative"
MIME-Version: 1.0

Is it possible the Sophos is breaking it apart and reassembling poorly during scanning? There doesn't appear to be anything obviously "strange" in the re-sent copy that worked.



This thread was automatically locked due to age.
Parents Reply Children
No Data