Strange encoding of attachment filname

[Michael Storz]

Am 2012-11-15 15:30, schrieb Ralf Hildebrandt:
> Today a user reported that he received a mail without attachment.
>
> Turns out that there *IS* an attachment, but it's strangely named.
>
> Looking at the raw mail we find:
>
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
>         boundary="=_v1cFiJlk+hCgpTYQg6SrNjzrUErl8abdUWfJ88KLUInW8C9C"
>
> ...
> --=_v1cFiJlk+hCgpTYQg6SrNjzrUErl8abdUWfJ88KLUInW8C9C
> Content-Type: application/pdf; name*0*=
>
> 
> "iso-8859-1"%41%6E%66%6F%72%64%65%72%75%6E%67%65%6E%5F%53%7A%31%5F%53";
>         name*1*="%7A%32%2E%70%64%66"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
> 
> 	filename*0*="iso-8859-1"%41%6E%66%6F%72%64%65%72%75%6E%67%65%6E%5F%53%7A%31";
> 	filename*1*="%5F%53%7A%32%2E%70%64%66"
>
> 
> JVBERi0xLjQKJeLjz9MKMyAwIG9iago8PAovUHJvZHVjZXIgKFBERi1YQ2hhbmdlIDMuNjAu
> ...
>
> If we interpret the numbers as HTML entitities, we get:
> Anforderungen_Sz1_Sz2.pdf
> which looks fairly normal.
>
> Is this encoding ok? I know it's OK to encode special characters like
> Umlaut characters. But all of it?
>
> Also I have never seen this "line continuation" of the filename/name
> field. Is that legit?
>
> I've never seen this stuff before...

Ralf,

it is correct. You find the explanation in

RFC 2231
MIME Parameter Value and Encoded Word Extensions:
Character Sets, Languages, and Continuations

Gruß,
Michael