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
