Are these email headers RFC-2047 compliant?

Question

I have several clients using a mail client that I wrote myself. They have recently stumbled upon emails where attachment file names arrive are in gibberish.

When I examined these emails, I have discovered that there is apparently a local webmail service that sends attachment names as follows:

Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
    name*="UTF-8''%D7%A2%D7%A8%D7%9B%D7%AA%20%D7%94%D7%A8%D7%A9%D7%9E%D7%94%20TCMP.docx"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
    filename*=UTF-8''%D7%A2%D7%A8%D7%9B%D7%AA%20%D7%94%D7%A8%D7%A9%D7%9E%D7%94%20TCMP.docx

This is a totally invalid mime header according to RFC 2047. It has no quoted-printable identifier (?Q?), the different bytes are encoded with % instead of =, and the entire encoded-word should begin with =? and end with ?=, which it doesn't.

When I fix it to the correct format like so:

Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
    name="=?UTF-8?Q?=D7=A2=D7=A8=D7=9B=D7=AA=20=D7=94=D7=A8=D7=A9=D7=9E=D7=94=20TCMP.docx?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
    filename=?UTF-8?Q?=D7=A2=D7=A8=D7=9B=D7=AA=20=D7=94=D7=A8=D7=A9=D7=9E=D7=94=20TCMP.docx?=

then the header gets decoded correctly.

Can anyone tell me if I'm missing something here? Is there a new extension to RFC2047 that allows for these headers, or are they just completely wrong?

That extension format is described in [rfc2231](https://tools.ietf.org/html/rfc2231). — Alex K., May 24 '17 at 09:47
THANK YOU. It seems I'll have to implement this standard after all. — user884248, May 24 '17 at 09:58

score 0 · Answer 1 · answered Oct 25 '18 at 23:38

As mentioned by @alex-k, the name*= syntax is defined in RFC2231 which was written after RFC2047.

But to answer the question as asked, no. Neither set of headers is RFC2047 compliant.

The *= syntax was not in existence when RFC2047 was written, so the original ones do not conform.

The second set, with MIME encoded words, are invalid because they break the rules about where MIME encoded words are allowed according to section 5 of RFC2047, specifically both of these rules:

   + An 'encoded-word' MUST NOT appear within a 'quoted-string'.

   + 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'.

(Those rules are not consecutive in the RFC.)

Are these email headers RFC-2047 compliant?

1 Answers1