Closed martinknafvework closed 2 weeks ago
The issue is the mix-and-match encoding rules that your sample email uses. It uses both rfc2231 and rfc2047 encoding rules when it should only use rfc2231 -or- rfc2047 (technically, it should use rfc2231 since that is the standard, but rfc2047 encodings were used in the 90's because rfc2231 didn't exist yet).
Instead, the client that sent this message used rfc2047 encoding and then passed that through the rfc2231 encoding rules.
I don't think this is a case worth working around because I guarantee whatever client sent this is the only client in existence that does this.
Describe the bug
When loading an email using
MimeMessage.Load
, attachments containing base64-encoded utf8 file names are not parsed properly.Platform (please complete the following information):
To Reproduce
email.txt
.Now you will see the attachment filename
=?UTF-8?B?SGVsbG9Xb3JsZC50eHQ=?=
printed to console.Expected behavior I expect to see the attachment file name
HelloWorld.txt
printed to the console. This is what is shown if I open the same file in Outlook or Mozilla Thunderbird.Code Snippets If applicable, add code snippets to help explain your problem.
Additional context
Email.txt
I am parsing EML files produced by external systems. The actual files have the attachment file names split over multiple lines (
filename*0=
,filename*1=
etc). But since the issue was reproducible with a single, I hoped that would be sufficient.