4.1.3 Content-Type Versus File Extension Mismatch

  • Article

Various clients accept the Content-Type header received from the server but then verify the content. This can include checking the file extension or looking for a thumbprint at the start of the file, and then mapping this data back to a verified Content-Type header value. If the file extension or thumbprint does not match the stated Content-Type header value, a Content-Type header value derived from the file extension or thumbprint is used instead. This behavior is actually described in [RFC2045], which allows the sender to set the Content-Type header value to "application/octet-stream" (or not set it at all). The recipient (1) is then responsible for correctly determining the type of content via alternate means.

In addition, it was found that various clients incorrectly set the Content-Type header either by mistake or intentionally. Support to address the former has existed for quite some time but has opened a path to potentially thwart policy scanning and protection applications running on the server.

Therefore MIME readers can correct mislabeled Content-Type header values so that server Policy Agents and clients can trust the header value. Clients need to offer a mechanism to do one or more of the following:

  • Suppress correcting the value of the Content-Type header.

  • Block attachments by type or extension.

  • Offer some sort of security barrier before running any script or binary.

These steps are particularly important if the sender is unauthenticated.