Duplicate of bug #129, try Horde 3.2.1.

When you click on the "download" icon for an attachment whose name 
includes non-ascii characters, the name displayed in the IE 6 
Open/Save dialog appears to be an iso-8859-1 interpretation of the 
UTF-8 name.  Not sure at the moment if this is true for IE 7.  It is 
displayed correctly in Firefox.



Though not the cause of the IE problem, I noticed that the 
Content-Disposition header value is incorrect acording to the RFC's as 
the filename attribute value should either be US-ASCII (2045) or 
conform to the RFC 2231 extension (based on 2047 encoding).  Reworking 
it to RFC 2231 conformance did not help with IE 6, but Firefox handles 
it properly.



I did a little additioanl testing to see what it would accept and 
found that simple url encoding displayed the proper filename in the 
Open/Save dialog and in the filename textbox of the Save dialog (but 
it was displayed wth the url encoded name in the title bar of notepad. 
  2 out of 3 is pretty good when working around Microsoft problems :). 
  Simply returning the filename attribute url encoded caused Firefox 
to display it as a literal string, i.e. it did not get url decoded.



So a simpe solution (though probably not the one you'll want to go 
for) is to update the download_attach action handler in imp/view.php 
to something like this:



$name = $mime->getName(true, true);

// Work around IE content-disposition bug

if($browser->isBrowser('msie')) {

         $name = urlencode($name);

}