Base64 encoded attachment filenames

[b33f3r]

In pursuit of better integration with commercial doc scanners:

Change MimePart.cs line 91:

Name = name;

to:

Name = Functions.DecodeMailHeader(name).Replace("\r","").Replace("\n","");

Aaaaaaaaaaaaaaand you're welcome, again.

[jstedfast]

rfc2047-encoded parameter values is, unfortunately, quite common even though it is not the correct encoding to use.

[jstedfast]

FWIW, this code might be helpful: https://github.com/jstedfast/MimeKit/blob/master/MimeKit/ParameterList.cs#L770

The preceding code tokenizes all of the parameters and then that loop combines the (properly) rfc2231-encoded parameter values. For non-rfc2231 parameters, it uses my Rfc2047.DecodeText() method to handle potential rfc2047-encoded values.

[bertjohnson]

Once again, thanks for submitting the fix b33f3r. And good point / reference code, jstedfast. This is checked into the 1.6.3 release.

I plan to do another pass of the RFCs in the future and may redo / rename some methods to clarify which RFC requirements they match, similar to how Jeffrey has organized his methods.

[jstedfast]

I actually hate having a class named Rfc2047... I just couldn't think of a better name for it and there is just so much code to properly handle all ways that broken mailers out there mal-encode headers, I felt for sanity's sake I had to split all that logic into its own file :-)

FWIW, I have a summary of some of the ways that mailers mal-encode their headers which may be helpful:

http://jeffreystedfast.blogspot.com/2013/08/why-decoding-rfc2047-encoded-headers-is.html

Someone from the Thunderbird project wrote a 4-part series of blog posts about the problems with dealing with various aspects of MIME:

http://quetzalcoatal.blogspot.com/2013/09/why-email-is-hard-part-1-architecture.html
http://quetzalcoatal.blogspot.com/2013/10/why-email-is-hard-part-2.html
http://quetzalcoatal.blogspot.com/2013/11/why-email-is-hard-part-3-mime.html
http://quetzalcoatal.blogspot.com/2013/12/why-email-is-hard-part-4-email-addresses.html

You may find his blog posts more useful than mine as he seems much more articulate than I am at writing blog posts. They are definitely worth the read.

Hope that helps.

[bertjohnson]

Yep, good points. The RFC nomenclature is a necessary evil in this case. I'm not sure how the internal naming will end up in OpaqueMail, but you've taken a rational approach with MimeKit.

I've read through the Quetzalcoatal blog series in the past and agree that it's a good resource. Thanks for sharing that and your post -- definitely worth checking out. It's been a few months since I've gone through those and the RFCs in detail, so it's probably worth a refresher...