[Tickets #4733] Re: attachments with non-latin characters

[bugs@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=4733
-----------------------------------------------------------------------
 Ticket             | 4733
 Updated By         | Michael Slusarz <slusarz at horde.org>
 Summary            | attachments with non-latin characters
 Queue              | IMP
 Version            | HEAD
 Type               | Bug
 State              | Resolved
 Priority           | 2. Medium
 Owners             | Michael Slusarz
-----------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2006-12-06 09:05) wrote:

> 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.

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

> 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.

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.