Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=803991

This was initially reported against evolution-mapi, that filename which included UTF-8 letters is encoded in a way which evolution cannot read. After quite some investigation we figured out that the issue is with Edit->Preferences->Composer Preferences->Encode filenames in an Outlook/GMail way. Where there is a filename like "FIS Direct_ДБО_2012.pdf" then
a) without the option being checked evolution encodes it as
> Content-Disposition: attachment;
>     filename*=UTF-8''FIS%20Direct_%D0%94%D0%91%D0%9E_2012.pdf
   which it can read without any issue.
b) with the option being checked evolution encodes the file name as
> Content-Disposition: attachment;
>    filename="FIS =?UTF-8?Q?Direct=5F=D0=94=D0=91=D0=9E=5F2012=2Epdf?="
   and the worse, it cannot read it itself, and shows it in this form in UI.
 The interesting part is that the current GMail (as of today) doesn't have any issue with either format of these (thus it finally supports encoding as it should be), only evolution itself is confused with header value it created itself.

I realized that the problem is the space in the file name, which breaks header value into two words. While evolution is doing it right, it doesn't try to decode multiword value from encoding described by RFC 2047 in header parameters (it is not supposed to be there, as this was just a workaround for filenames in headers from times when outlook and gmail had problem with correct formatting). Having filename one single word fixes the issue for all involved. (I tested with GMail only, but I suppose older Outlook will be fine too).