Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content-Disposition: filename* vs. Content-Type: name #239

Closed
cyberangel opened this issue May 5, 2016 · 5 comments
Closed

Content-Disposition: filename* vs. Content-Type: name #239

cyberangel opened this issue May 5, 2016 · 5 comments
Labels
compatibility Compatibility with existing software

Comments

@cyberangel
Copy link

cyberangel commented May 5, 2016

Hello.

First of all thank you for your excellent library for handling MIME. It saves us a lot of headache parsing e-mails.

I'm having an issue with file attachments with names encoded in UTF-8, as in this example:

Content-Type: image/jpeg; name="=?utf-8?q?SBD_=C5=A0kodov=C3=A1k=2Ejpg?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment; size=1049971;
    filename*="utf-8''SBD%20%C5%A0kodov%C3%A1k%2Ejpg"
Content-ID: <m1548006d0c3m73d>

The filename is supposed to be "SBD Škodovák.jpg" and the Content-Type.Name properly decodes the quoted string.
But the ContentDisposition.FileName decodes as "SBD Škodovák.jpg"". I see it is URL encoded ->
"utf-8''SBD%20%C5%A0kodov%C3%A1k%2Ejpg" -> HttpUtility.UrlDecode -> "utf-8''SBD Škodovák.jpg".

Clearly there is something amiss and I've modified my program to use The Content-Type.Name property instead.
But I would like to hear your opinion - is it a bug in MimeKit.ContentDisposition or is the client composing the message at fault?

Thanks.
Honza

@jstedfast
Copy link
Owner

The problem is that the filename parameter is inside of a quoted string (it's not supposed to be), which means that the charset is parsed as "utf-8 (note the leading dquote) which of course is a bogus charset and so it falls back to iso-8859-1.

jstedfast added a commit that referenced this issue May 5, 2016
@jstedfast
Copy link
Owner

I've fixed the code to work around this issue.

The plan is to release a new version to nuget.org this weekend.

@jstedfast jstedfast added the compatibility Compatibility with existing software label May 5, 2016
@cyberangel
Copy link
Author

Thank you.

@michael-o
Copy link

michael-o commented Dec 11, 2019

FTR, @cyberangel Your content id is wrong.

@cyberangel
Copy link
Author

FTR, @cyberangel Your content id is wrong.

This was copied without change, so whatever the Content-ID was there was copied with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility Compatibility with existing software
Projects
None yet
Development

No branches or pull requests

3 participants