Content-Type: =?windows-1252?q?application/pdf; considered as text/plain

Content-Type: =?windows-1252?q?application/pdf; considered as text/plain

[Denis Bitouzé]

Hi,

here is an excerpt of a mail I received:

  ┌────
  │ This is a multi-part message in MIME format.
  │ --------------090708010503020305020500
  │ Content-Type: text/plain; charset=ISO-8859-1; format=flowed
  │ Content-Transfer-Encoding: quoted-printable
  │ 
  │ [...]
  │ 
  │ --------------090708010503020305020500
  │ Content-Type: =?windows-1252?q?application/pdf;
  │  name="PVCONSEIL DIRECTION 09 Septembre 2019.pdf"
  │ Content-Transfer-Encoding: base64
  │ Content-Disposition: attachment;
  │ 
  │ [...]
  └────

Strangely enough, the attached PDF file is considered by Gnus as a plain
text file.

  ┌────
  │ text/plain; PVCONSEIL DIRECTION 09 Septembre 2019.pdf
  └────

Do you know what's going on?

Thanks.
-- 
Denis

Re: Content-Type: =?windows-1252?q?application/pdf; considered as text/plain

[Florian Weimer]

* Denis Bitouzé:

>   │ Content-Type: =?windows-1252?q?application/pdf;
>   │  name="PVCONSEIL DIRECTION 09 Septembre 2019.pdf"

> Strangely enough, the attached PDF file is considered by Gnus as a plain
> text file.
>
>   ┌────
>   │ text/plain; PVCONSEIL DIRECTION 09 Septembre 2019.pdf
>   └────
>
> Do you know what's going on?

Reading Section 5.1 of RFC 2045 and section 5 of RFC 2047

  <https://tools.ietf.org/html/rfc2045#section-5.1>
  <https://tools.ietf.org/html/rfc2047#section-5>

I don't think encoded-words are allowed in Content-Type headers.  The
latter is quite explicit about this:

|   + An 'encoded-word' MUST NOT be used in parameter of a MIME
|     Content-Type or Content-Disposition field, or in any structured
|     field body except within a 'comment' or 'phrase'.

So I would say that the message is malformed.