323390 - [RFE] add a warning about non-rfc2231 compliant mua when sending an email with a long file name and allow to use legacy (pre-rfc2231) encoding

Status: RESOLVED WONTFIX

(Thunderbird :: Message Compose Window, enhancement)

Description

[Matp75]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060112 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060112 Firefox/1.5

RFC2231 filename encoding is by default with thunderbird 1.5 (see bug 193439 :
implementation and bug 309566 about the consequences on the receiving side (ie
mostly with outlook).
At the moment one solution is for the user to change the value of
mail.strictly_mime.parm_folding, which is not easy at all for most users.
It's also possible to change it via a extension (see
https://bugzilla.mozilla.org/show_bug.cgi?id=309566#c17 or directly at
http://www.mozilla-japan.org/products/thunderbird/patches/309566.xpi thanks to
Mozilla Japan). 

this bug/rfe is about warning thunderbird users when sending a mail with a long attachement that some mua don't yet support rfc2231 and allow sending the mail using legacy mode.
Message could be :
"Thunderbird will use a standard method (rfc2231) for encoding long file names, which is not yet supported by all clients.

[X] Use standard method
[ ] Use legacy method
 
[ ] Don't ask again 

        Send              Cancel                "
  
the warning should not appear if there is no attachement or attachement filename encoded is less than 62 characters (as this will not use multiples lines when encoding)
Pref can be changed again in the preference window(see bug 323388) 

with this warning, it easier to see that the problems are on the receiving side and are not thunderbird fault.


Reproducible: Always

Comment 1

[Claus Berghammer]

I vote for this new feature, since the attachment problem is the most serious in TB1.5 :-(

I think the "warning dialog" is the best solution, that is why I proposed it myself in 309566#c10 some time ago ;-)

All Readers who also think that this is the best solution to this problem, PLEASE VOTE for it...

Comment 2

[script]

Confirmed problem with sending a 58 character long .pdf to 

   QUALCOMM Windows Eudora Version 6.1.1.1

Attachent name is rendered truncated. Guys, we have all the Outlook and Eurora users receiving long named attachments incorrectly!!! 

Comment 3

[yop]

I vote for something like this. Since attachments that have *non* english characters in the file name are messed up aswell. Yahoo mail, mdaemon mailserver and other webmail services aswell

attachment "וצה.doc" are in yahoo mail "file.bin"
And in Mdaemon webmail "ATT00001.EXE"
Really no good :)

Comment 4

[bob ball]

I voted for this bug, but I only think half of it should be fixed.

Users should not be presented with information about RFC2231, instead they should be informed "Some email clients (such as Microsoft Outlook) do not accept files with long file names properly.  Do you wish to send anyway or rename the file?"

Comment 5

[Claus Berghammer]

I think this issue can be closed. The problem "doesn't longer ocour" since TB 2.x...

Comment 6

[Matp75]

resolving won'tfix as TB2.x and latter offer a solution to send both rfc2231 compliant for new mua and old way for non compliant.