Scenario:
As part of our CI process, we generate an .xlsx file (with EPPlus) of the changes and e-mail it to stakeholders. Recently, our internal SPAM filter starting removing this attachment.
If we opened and saved the document, we could send it again successfully.
After unzipping the .xlsx, I discovered that manually adjusting the [Content_Types].xml file and swapping the lines below [__working order shown below__] solves the problem.
```
<Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/>
<Default Extension="xml" ContentType="application/xml"/>
```
My theory is that the SPAM filter (or possibly the Mail agent) is searching for a relevant MIME Type and finds "application/xml" __before__ "application/vnd.openxmlformats-package.relationships+xml", and "application/xml" is blocked.
Relevant code appears to be in the AddNew method of ZipPackage.
As part of our CI process, we generate an .xlsx file (with EPPlus) of the changes and e-mail it to stakeholders. Recently, our internal SPAM filter starting removing this attachment.
If we opened and saved the document, we could send it again successfully.
After unzipping the .xlsx, I discovered that manually adjusting the [Content_Types].xml file and swapping the lines below [__working order shown below__] solves the problem.
```
<Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/>
<Default Extension="xml" ContentType="application/xml"/>
```
My theory is that the SPAM filter (or possibly the Mail agent) is searching for a relevant MIME Type and finds "application/xml" __before__ "application/vnd.openxmlformats-package.relationships+xml", and "application/xml" is blocked.
Relevant code appears to be in the AddNew method of ZipPackage.