I do not think it's question of the recent version, I tried almost same thing with some old version of evolution, and outlook still doesn't understand the attachment names.

Then I tried to sent from outlook to Evo and both recognized it properly, maybe the evo part should follow same as that outlook does:
------=_NextPart_000_0005_01C8DE0F.F0BF3E40
Content-Type: text/plain; format=flowed; name="=?iso-8859-2?B?7Lno+L794e3pLnR4dA==?="; reply-type=original
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="=?iso-8859-2?B?7Lno+L794e3pLnR4dA==?="

but maybe not. Jeff, any idea on this thing?

well, the way Outlook encodes the filename is strictly illegal and the way Evolution encodes them is the proper IETF defined encoding format as specified in rfc2184/2231

Evolution should not be made to break standards imho.

Thanks for pointing the RFC numbers. I agree Evolution should not break standards. I didn't check the code yet, but do you think it has some workaround for outlook attachments that it can read its name without any problem even it's not encoded in the standard way?

sadly, there's probably no workaround other than maybe ascii'ifying the filenames.

E.g.: ç.doc -> c.doc

but that wouldn't be what the user would expect, so... 

Milan, its the other way around: Evolution-sent attachments cannot be read by Outlook :-)

Jeff, I would be happy with ascii-fying the filenames, since this would produce an attachment that even Outlook would be able to swallow. The problem I see is how do we identify when the recipient is Outlook? We probably would not really like to send an ascii-ficated filename to everybody, just to cater for a product that is unable to follow standards.

In this case I would rather publish a warning somewhere, stating something like "Attention: if the recipient of the email is running Outlook, please do not use extended/nationalised characters for the attachment(s) filenames. Outlook will not be able to deal with it.".

(OT -- Man, I loved being able to transform ASCII! ascii-nisation sounds really cool :-)

Created attachment 114165 [details]
Appearance of non-asci attachment names in Gmail

Hi!

I guess it's not Outlook only, but Gmail also doesn't recognize non-ascii characters in attachment names. I created attachments with names ü.txt, ğ.txt, İ.txt, ı.txt, ş.txt, ç.txt, ö.txt, Turkish language characters. Attached is the appearance in Gmail when the attachments are sent from Evolution.

Hope it helps,
Janberk

Gmail also uses encoded-words in filename, even it should not, as is written in the above RFCs. To be honest, I tried with other of my email accounts and all of them do this same, none of them conforms the above RFCs, but uses encoded-word.
We also "support" the encoded words on the input, even it should not be there.

I agree with Jeff about following standards, but is this so important even in such place like the name/filename of Content-Type/Content-Disposition?

Greet from China!

Does it means that Evolution will do nothing on this issue? Nor any workaround?

It is sad for me, who are looking for changing my work platform from Windows
to Linux. Since I cannot force my colleagues and friends to abandon Outlook.

I think it should be true that the RFC Evolution used is better than what Outlook used. But the law of Internet is the "de facto" standard weigh heavy than the "advanced" standard...

Could anyone tell me if there is an email client on Linux that can send a non-English filename attachment to Outlook?

Thank you!




(In reply to comment #2)
> well, the way Outlook encodes the filename is strictly illegal and the way
> Evolution encodes them is the proper IETF defined encoding format as specified
> in rfc2184/2231
> 
> Evolution should not be made to break standards imho.
> 

I have just searched and found that Evolution used RFC 2231 as the 
Message Header standard, while Outlook used RFC2047.

Is that possible that Evolution add an option of RFC2047?


(In reply to comment #9)
> Greet from China!
> 
> Does it means that Evolution will do nothing on this issue? Nor any workaround?
> 
> It is sad for me, who are looking for changing my work platform from Windows
> to Linux. Since I cannot force my colleagues and friends to abandon Outlook.
> 
> I think it should be true that the RFC Evolution used is better than what
> Outlook used. But the law of Internet is the "de facto" standard weigh heavy
> than the "advanced" standard...
> 
> Could anyone tell me if there is an email client on Linux that can send a
> non-English filename attachment to Outlook?
> 
> Thank you!
> 
> 
> 
> 
> (In reply to comment #2)
> > well, the way Outlook encodes the filename is strictly illegal and the way
> > Evolution encodes them is the proper IETF defined encoding format as specified
> > in rfc2184/2231
> > 
> > Evolution should not be made to break standards imho.
> > 
> 

It seems ASCIIfying the file names would not work, since this is affecting non-ASCII users (as reported on the Ubuntu bug). Also, an ASCII filename with spaces will trigger the bug. And yes, I realise we could replace the space by -- say -- an underscore.

But it really sounds better to make it compatible with the broken servers in the world (a lot of them, if I follow mchra).

@Janberk Sahin: what version of Evolution are you running?

Created attachment 121905 [details] [review]
proposed eds patch

for evolution-data-server;

Do not take me wrong, I do not like the change, but I want to support out users.
The change comes quite low in the code, thus no option available, I'm sorry.

guys, can you confirm, if the patch works for you?

I just noticed it has some issues with spaces in the file name in Outlook, but it doesn't seem to be under our control, because the encoded filename in the mail source seems correct to me.

I am building a test (PPA) package for Ubuntu Intrepid, and should have it available for the reporter and CC on UBuntu in a few.

Since they have been the most vocal on this bug, it makes sense to have it available for them to test. I will update here on the results.

Milan, what is it you are changing here?

@@ -3322,7 +3330,7 @@ header_encode_param (const unsigned char
 	str = out->str;
 	g_string_free (out, FALSE);
 	*encoded = TRUE;
-	
+
 	return str;
 }

test packages for Ubuntu Hardy and Intrepid have been put available. I will wait for feedback, and will post it here.

(In reply to comment #16)
> Milan, what is it you are changing here?

It's not visible, but it's there, the '-' line has \t, but the '+' line doesn't.

First feedback from the Ubuntu bug:

"Hi Hggdh, I followed your instructions and updates Evolution with the
Hardy package.

ç.txt still is received by Outlook Express as ATTxxxxxx.dat...

The good news is that "this is a test.txt" was received properly!!"

I will ask the reporter for the MIME headers.

New comments from the Ubuntu bug.

(cherry-picked the important pieces of the comments)
-------- start comments --------
--=-5hGpl2nVDtewDmbpAyxl
Content-Disposition: attachment; filename*=ISO-8859-1''a%E7%E3o.txt
Content-Type: text/plain; name*=ISO-8859-1''a%E7%E3o.txt; charset=UTF-8
Content-Transfer-Encoding: 7bit


Hggdh, what I sent you above, for the file "ação.txt" did not work. I received ATT<something).dat in Outlook Express. What I'm pasting now is for "ç.txt", that actually works perfectly.

--=-h+PqkzwHnOOeiXYbCxny
Content-Disposition: attachment; filename=ç.txt
Content-Type: text/plain; name=ç.txt; charset=UTF-8
Content-Transfer-Encoding: 7bit
-------- end comments --------
Darn! I do not have Outlook to test!

But I did sent to GMail a "ação.txt"-attached file. I can see the attachment, and it is correctly recognised; then name is hosed, though: "ação.txt".

New comment from the Ubuntu bug (https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/205999/comments/39)

-------- start comments --------

I tested a few cases (with the supplied hardy-packages on launchpad):

Äbö lü.txt
Äbölü.txt
Xxxxxxx xx XX-X Xxxxxxxxxxxxxxxxxx xx XxxxXxxxxxxxxx xx XXX XXXX 15Nov07.pdf
Xxxxxxx_xx_XX-X_Xxxxxxxxxxxxxxxxxx_xx_XxxxXxxxxxxxxx_xx_XXX_XXXX_15Nov07.pdf

Contrary to the comment of hggdh of Nov 5th, both long filenames (with
and without blanks) passed ok. So my experience is in line with
Effenberg0x0 (comment nr. 32)

However, the shorter names with "Umlaute" did not work out :( There is however an improvement. It is *not* anymore ATTXXXXX.DAT, just hyroghlyphic names with the original extension (s. attachment). It is remarkable that the name is shown differently in OWA (Web-Access) and Outlook.
Might be a problem of Encoding (us-ascii; 7 bit).

I can test more beginning of next week if required.

the relevant part of the header follows:

--=-+JaI8DjvsOFjibbhVfpv
Content-Disposition: attachment; filename=Äbölü.txt
Content-Type: text/plain; name=Äbölü.txt; charset=us-ascii
Content-Transfer-Encoding: 7bit


--=-+JaI8DjvsOFjibbhVfpv
Content-Disposition: attachment; filename="Äbö lü.txt"
Content-Type: text/plain; name="Äbö lü.txt"; charset=us-ascii
Content-Transfer-Encoding: 7bit


--=-+JaI8DjvsOFjibbhVfpv
Content-Disposition: attachment; filename="Xxxxxxx xx XX-X Xxxxxxxxxxxxxxxxxx xx XxxxXxxxxxxxxx xx XXX XXXX 15Nov07.pdf"
Content-Type: text/plain; name="Xxxxxxx xx XX-X Xxxxxxxxxxxxxxxxxx xx XxxxXxxxxxxxxx xx XXX XXXX 15Nov07.pdf"; charset=us-ascii
Content-Transfer-Encoding: 7bit


--=-+JaI8DjvsOFjibbhVfpv
Content-Disposition: attachment; filename=Xxxxxxx_xx_XX-X_Xxxxxxxxxxxxxxxxxx_xx_XxxxXxxxxxxxxx_xx_XXX_XXXX_15Nov07.pdf
Content-Type: text/plain; name=Xxxxxxx_xx_XX-X_Xxxxxxxxxxxxxxxxxx_xx_XxxxXxxxxxxxxx_xx_XXX_XXXX_15Nov07.pdf; charset=us-ascii
Content-Transfer-Encoding: 7bit


--=-+JaI8DjvsOFjibbhVfpv--

** Attachment added: "Owa-Outlook.png"
   http://launchpadlibrarian.net/19459766/Owa-Outlook.png

-------- end comments --------

Holger then added a new comment stating "Don't overestimate my guessing on encoding. On a second look, the specified charset and Encoding is for the content - which was in my test case empty dummy files. Will test further, but unfortunately only beginning of next week."

Created attachment 122211 [details] [review]
proposed eds patch ][

for evolution-data-server;

Updated patch. When I was testing the previous one, it worked fine for my characters, but for yours it's quite different. I tried with the u.txt and it yells it's not the UTF-8 valid text, thus this should help (it'll encode them to the form of "=XY", where XY is the code of the unknown character).

I also noticed from the above comments the file name is not always quoted, thus fixed that too.

One of the first replies, where if "filename*=", it seems like previously saved message. This works for new messages only.

Thank, Milan. I will build an updated test package for the Ubuntu users.

New comment from the Ubuntu bug:

@hgddh: I did not get the hardy packages with a simple 'sudo aptitude update; sudo aptitude upgrade'. Is there an error with the repository (non-updated package list?!) or is something messed up with my system? I installed manually:
ii  evolution-data-server                 2.22.3-0ubuntu3ppa5
ii  evolution-data-server-common  2.22.3-0ubuntu3ppa5
Hope that is all what was needed.

With this update, the problem seems solved (see screenschot in
attachment). Outlook Web Access also shows the attachment names
correctly (no screenshot attached). Thanks to everyone involved!

As a sidenote:
I did a comparison of the e-mail headers seen from within evolution (Ctrl+U to see the "source code" of the message, scrapping out the message content that also shows up) and of the e-mail headers seen from within outlook (via message properties, only "headers" schown, no content in-between):

holger@RL-U200:~/temp/evotests$ diff headers-seen-from-evo.txt headers-seen-from-outlook.txt
3c3
< Content-Transfer-Encoding: 8bit
---
> Content-Transfer-Encoding: 7bit
6,8c6,8
< Content-Disposition: attachment; filename=Äbölü.txt
< Content-Type: text/plain; name=Äbölü.txt; charset=UTF-8
< Content-Transfer-Encoding: 8bit
---
> Content-Disposition: attachment; filename=Äbölü.txt
> Content-Transfer-Encoding: base64
> Content-Type: text/plain; name=Äbölü.txt; charset=UTF-8
11,13c11,13
< Content-Disposition: attachment; filename="Äbö lü.txt"
< Content-Type: text/plain; name="Äbö lü.txt"; charset=UTF-8
< Content-Transfer-Encoding: 8bit
---
> Content-Disposition: attachment; filename="Äbö lü.txt"
> Content-Transfer-Encoding: base64
> Content-Type: text/plain; name="Äbö lü.txt"; charset=UTF-8
16,17c16,17
< Content-Disposition: attachment; filename=Hélène_photo.jpg
< Content-Type: image/jpeg; name=Hélène_photo.jpg
---
> Content-Disposition: attachment; filename=Hélène_photo.jpg
> Content-Type: image/jpeg; name=Hélène_photo.jpg
31,33c31,33
< Content-Disposition: attachment; filename="zurück is back.whatever"
< Content-Type: text/plain; name="zurück is back.whatever"; charset=UTF-8
< Content-Transfer-Encoding: 8bit
---
> Content-Disposition: attachment; filename="zurück is back.whatever"
> Content-Transfer-Encoding: base64
> Content-Type: text/plain; name="zurück is back.whatever"; charset=UTF-8


It is interesting to see that they show differences! I leave it to the experts to interpret the meaning (if any).
Furthermore, in the headers-view of outlook, the filenames show up "ugly", whereas in the usual Outlook-view of messages, they show up nice and clean as desired.

Hope this provides all the necessary information to the evo-hackers out
there that cannot and have not to access outlook/exchange.

Thanks again to everyone involved to have (hopefully completely) solved
this problem.

** Attachment added: "Screenshot of attachmentnames as seen in Outlook"
   http://launchpadlibrarian.net/19530101/Outlook-hardy_2.22.3-0ubuntu3ppa5.png

I am wondering if locale might be affecting this.

I'm not sure how to read the differences, but one thing I'm sure about is that the filename/name params of the header should be enclosed in quotes. The second patch was supposed to do that every time. Furthermore, if text is not in the UTF-8 it "escapes" wrong characters. It'll break file names heavily, but they will be available as attachments, what I hope is good thing.

(In reply to comment #25)
> I am wondering if locale might be affecting this.

Hmm, maybe.

Created attachment 122341 [details]
tar containing file that does not encode properly

Created attachment 122360 [details] [review]
proposed eds patch ]I[

for evolution-data-server;

Hopefully the last version. It doesn't work without evo's part.

Created attachment 122361 [details] [review]
proposed evo patch

for evolution;

it uses extern int camel_header_param_encode_filenames_in_rfc_2047 defined in camel, similar to camel_application_exiting, even here we write there in evo.

seems to work fine against trunk, thanks. I will now get back to the Ubuntu bug, and start looking at backporting it.

Again, thank you, Milan.

Milan, could you put a big 'HACK:' in the camel code? And commit ?

eds part committed to trunk. Committed revision 9756.
evo part committed to trunk. Committed revision 36779.

"HACK:" added in the comment before the global variable definition.

this breaks the mail component says bug reported downstream 
https://bugzilla.novell.com/show_bug.cgi?id=445397

After upgrading on 13-Nov-2008, evolution no longer shows mail component.
However other components are usable. When I start evolution from command line,
I see following errors.

(evolution:18776): e-utils-WARNING **: can't load plugin
'/usr/lib/evolution/2.26/plugins/liborg-gnome-exchange-operations.so':
/usr/lib/evolution/2.26/components/libevolution-mail.so: undefined symbol:
camel_header_param_encode_filenames_in_rfc_2047

(evolution:18776): e-utils-WARNING **: can't load plugin
'/usr/lib/evolution/2.26/plugins/liborg-gnome-exchange-operations.so':
/usr/lib/evolution/2.26/components/libevolution-mail.so: undefined symbol:
camel_header_param_encode_filenames_in_rfc_2047
evolution-shell-Message: Killing old version of evolution-data-server...

(evolution:18776): evolution-shell-WARNING **: Cannot activate
'OAFIID:GNOME_Evolution_Mail_Component:2.26': g_module_open of
`/usr/lib/evolution/2.26/components/libevolution-mail.so' failed with
`/usr/lib/evolution/2.26/components/libevolution-mail.so: undefined symbol:
camel_header_param_encode_filenames_in_rfc_2047'


(evolution:18776): e-utils-WARNING **: can't load plugin
'/usr/lib/evolution/2.26/plugins/liborg-gnome-default-mailer.so':
/usr/lib/evolution/2.26/components/libevolution-mail.so: undefined symbol:
camel_header_param_encode_filenames_in_rfc_2047

(evolution:18776): e-utils-WARNING **: can't load plugin
'/usr/lib/evolution/2.26/plugins/liborg-gnome-evolution-startup-wizard.so':
/usr/lib/evolution/2.26/components/libevolution-mail.so: undefined symbol:
camel_header_param_encode_filenames_in_rfc_2047

(evolution:18776): evolution-shell-WARNING **: Unknown component mail
(evolution:18776): e-data-server-DEBUG: Loading categories from
"/root/.evolution/categories.xml"
(evolution:18776): e-data-server-DEBUG: Loaded 29 categories

linux-xzu9:~ # QObject: Do not delete object, 'unnamed', during its event
handler!

Someone forgot to bump the "eds_minimun_version" in configure.in.

No, I take that back; it's bumped already.  Downstream reporter just needs to upgrade and rebuild their evolution-data-server.

*** Bug 339415 has been marked as a duplicate of this bug. ***

*** Bug 517893 has been marked as a duplicate of this bug. ***