RFC 2047 is not a deprecated/bad standard as you note.  But RFC 2047 
explicitly *forbids* traditional MIME encoding in parameter values.   
See RFC 2047[5]:



   An [RFC 2047] 'encoded-word' MUST NOT be used in parameter of a

   MIME Content-Type or Content-Disposition field



The necessity isn't "questionable", it is required.  2231 describes 
the justification.  See also http://weblog.timaltman.com/node/834
We can't control behavior on other clients.  RFC 2047-like parameter 
encoding may work w/outlook clients, but it doesn't work on other 
clients.  When confronted with differing behaviors, the choice is to 
pick the standards way which is what we have done.



FYI, Opera, Thunderbird, and KMail (at a minimum) send w/ correct 2231 
encoding.  TheBat! was recently fixed to support 2231 decoding, so 
upgrade if that is an issue (see 
https://www.ritlabs.com/bt/view.php?id=4197)



Same issue as always - we are not going to fail to update our 
software/be standards compliant based on the actions of a single/few 
pieces of software.



Additionally, preserving correct filename information, in the grand 
scheme of things, is probably the least important element of mail 
delivery, especially considering some browsers can't reliably download 
filename information anyway.

Generally I would support software that supports as much standards as 
possible. But in this case I think it is more rationale to keep the 
old behaviour (as in RFC2047), because this brakes a large amount of 
clients. Especially when RFC2047 is not deprecated/bad standard or 
something and the necessity for RFC2231 is questionable.



Also, I must note, that this is not the problem with attachment name 
display only. It seems that everytime I try to save such attacment it 
is saved under different name. For example if I get ATT0001.zip in 
outlook and save it, filename on disk becomes ATT00020.zip. This is 
very confusing.

Big surprise then - Outlook is broken.  It is not handling RFC 2231 
encoded parameters correctly:

http://www.faqs.org/rfcs/rfc2231.html

Well it worked in the past that's for sure. I can see IMP generated 
attachment in Thunderbird but not in Outlook/Outlook Express or The 
Bat!.



This is what The Bat and Outlook generated when I tried to attach file 
with non-latin characters:



Content-Disposition: attachment;

        filename="=?UTF-8?B?dGVzdMSFxI3EmcSNxK/EmcSXxK8ueGxz?="



And this notation worked with all the clients above.

Apparently whups doesn't like these characters either :)  Using rough 
english equivalents, the filename is myfileacece.zip.

Guess I am confused.  That MIME encoding resolves to the following 
filename: myfile?????.zip



So are you saying this is still the incorrect filename?

Still doesn't work.



Content-Disposition: attachment;

        filename*="utf-8''myfile%C4%85%C4%8D%C4%99%C4%8D%C4%99.zip"

"

Try what I just committed.

After recent CVS update, attachments with non-latin characters in 
filename created with IMP doesn't show up right in Outlook Express 
anymore. I only get ATT00000 instead.