Attachments names using "ç" are not correctly sent by Evolution (ATT<number>.dat)

I have been exchanging emails with Effenberg re. this one. Since I do not have Outlook or Outlook Express, I do not know how it is actually received. But I did a quick test, attaching a text file called 'ç.txt'.

The MIME headers generated by Evo look as follows:

--=-ceEJcbwlddnv14KpPBAQ
Content-Disposition: attachment; filename*=ISO-8859-1''%E7.txt
Content-Transfer-Encoding: base64
Content-Type: text/plain; name*=ISO-8859-1''%E7.txt; charset=ISO-8859-1

I wonder if the "ISO-8859-1''%E7.txt" is making Outlook lost...

Will look upstream.

Opened upstream bug. I think this is related to the way we are now setting up the MIME headers, but I am not really familiar with it...

Hi Hggdh, if the developers need further information and testing I am willing to help, just tell me what you need.

Thanks,
Effenberg

Any news?

@Effenberg0x0 -- better to poke upstream.

Hggdh, is there anything I could do to get this solved? It's a really annoying one. It is impossible to send attachments unless you live in US or your language doesn't have accents (or you have to always remember to rename attachments to eliminate accents).

It has not yet been seen upstream.

Let me try it -- I will send you an email (I think I still have yours from last time), and I will attach an OO document called 'ç.doc'. Pleas open in on Outlook (I do not have it), and we will see what happens. I will do that from an Evolution 2.23.3 (upstream trunk).

Effenberg0x0 -- can you please add in here the MIME headers for a correctly identified attached file from Outlook? We already know how Evo sends out the MIME headers, but I would like to know what Outlook does.

For the record, 2.23.3 (SVN trunk) has the following:

Content-Disposition: attachment; filename*=ISO-8859-1''%E7.doc
Content-Type: application/msword; name*=ISO-8859-1''%E7.doc
Content-Transfer-Encoding: base64

Which is different from stock 2.22.

Hi Hddgh, I've sent an e-mail with ç.txt attached, from my webmail to my account on latest Outlook Express on a fully updated (SP3) Windows XP. It was received correctly.

Here's the relevant part of the headers:

X-XaM3-API-Version: 5.0(R1)
X-SenderIP: 189.18.236.5
Content-Type: multipart/mixed; boundary="_=__=_XaM3_.1212440074.2A.450123.42.30966.52.42.007.491706507"
MIME-Version: 1.0
Status: O

--_=__=_XaM3_.1212440074.2A.450123.42.30966.52.42.007.491706507
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Test - From webmail to Outlook. Regards.

--_=__=_XaM3_.1212440074.2A.450123.42.30966.52.42.007.491706507
Content-Type: text/plain; name="=?iso-8859-1?Q?=E7.txt?="
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="=?iso-8859-1?Q?=E7.txt?="

123. Regards.

--_=__=_XaM3_.1212440074.2A.450123.42.30966.52.42.007.491706507--

Then I've sent a PDF file (with ç in name) from Outlook to Outlook. It was received correctly.Here's the relevant part:

X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Content-Type: multipart/mixed; boundary="----=_NextPart_000_001E_01C8C4DB.8B977520"
MIME-Version: 1.0
Status: O

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01C8C4DB.8B977520
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Test - From Outlook to Outlook
Regards,
Effenberg

------=_NextPart_000_001E_01C8C4DB.8B977520
Content-Type: application/octet-stream; name="=?iso-8859-1?Q?Documenta=E7=E3o.pdf?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="=?iso-8859-1?Q?Documenta=E7=E3o.pdf?="

And this are the relevant part of the headers of the e-mail you sent me:

Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
 boundary="=-317+N2FIpONB8o7EBVI1"
MIME-Version: 1.0
Status: O

--=-317+N2FIpONB8o7EBVI1
Content-Type: multipart/mixed; boundary="=-8c6wtVYRa4nRIocDkcTw"

--=-8c6wtVYRa4nRIocDkcTw
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2008-06-02 at 17:49 -0300, Alvaro Leal wrote:
>=20
> Hi, can you send it again? You got caught in my ISPs spam filter and
> the attachment was deleted... Now I added you as a trustable source.
>=20

Here it goes.

--=-8c6wtVYRa4nRIocDkcTw
Content-Disposition: attachment; filename*=ISO-8859-1''%E7.doc
Content-Type: application/msword; name*=ISO-8859-1''%E7.doc
Content-Transfer-Encoding: base64

And a lot of stuff (Base64) follows.

This may be bad...

Effenberg0x0 -- would you have any clients/friends/colleagues with Outlook 2007/Exchange 2007?

I looked at FRC 2231 (http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=2231&type=ftp&file_format=pdf), and there is this piece describing MIME parameters (starting at page 6):

parameter := regular-parameter / extended-parameter
(...)
extended-parameter := (extended-initial-name "="
                       extended-value) /
                      (extended-other-names "="
                       extended-other-values)
extended-initial-name := attribute [initial-section] "*"
extended-other-names := attribute other-sections "*"
extended-initial-value := [charset] "’" [language] "’"
                          extended-other-values
extended-other-values := *(ext-octet / attribute-char)
ext-octet := "%" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
charset := <registered character set name>
language := <registered language tag [RFC-1766]>

This ABNF covers current usage of Evolution 2.22;

Additionally there is this other piece:

encoded-word := "=?" charset ["*" language] "?" encoded-text "?="

This covers previous Evolution, and seems to match your Outlook.

Now, going to Microsoft, I see this (http://technet.microsoft.com/en-us/library/cc540463(EXCHG.80).aspx, search for 2231):

(...)
 RFCs: 2045, 2046, 2047, 2049, 4288, 4289
http://rfc.net/rfc2045.html
http://rfc.net/rfc2046.html
http://rfc.net/rfc2047.html
http://rfc.net/rfc2049.html
http://rfc.net/rfc4288.html
http://rfc.net/rfc4289.html
Title: Multipurpose Internet Mail Extensions (MIME)
Updated by: 2184, 2231, 2646, 3798
Obsoletes: 1521, 1522, 1590, 2048
Exchange 2007 specific: Implemented by Exchange 2007.

I am not sure how to interpret this -- is 2231 implemented or not?

So. I would like you, or anybody reading this, to try to send to some friend/partner/whatever that runs Outlook 2007 under Exchange 2003 and Exchange 2007 -- both versions of Exchange (which probably means two different friends/partners/etc).

I will update upstream with a question, and lets see how this goes.

Hggdh-> Dude, we don't have any Outlook or Exchange left in here... The office is totally run on Linux now (which is why it took me so long to understand what our clients and partners were saying about "weird problems in our attachments"). My notebook has XP and Outlook installed on a Virtual Machine but I have no Exchange Server.

But I found this on the web:
http://services.mail2web.com/FreeServices/m2wLive/

They run on Exchange. Do you want me to create an account there and mail you with attachments?

it's worth a try... and hopefully they are running on Exchange 2007...

Thanks, Effenberg0x0.

Dear hggdh ..

Effenberg0x0 find this bug also report on Chinese characters.

I create new attachments file and change to Chinese characters file name sent from Evolution to Windows boxes using Outlook or Outlook Express are converted to ATT<number>.dat files.

and I use same file to change English name sent from Evolution to Windows boxes using Outlook or Outlook Express, is correctly.

victorywu@victory-u2:~$ uname -a
Linux victory-u2 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux
victorywu@victory-u2:~$ evolution --version
GNOME evolution 2.22.3.1
victorywu@victory-u2:~$

Best Regard
Archangelwu

Dear hggdh ..

I can support example file(Chinese characters) for you try !!

Best Regard
Archangelwu

Also affected with chinese attachments.

Long file names (and/or blank space in file name - but I assume not) seem to have the same effect, i.e. instead of the correct filename the attachment is named ATT#######.dat (####### being an arbitrary number)
Outlook might have difficulties with the composed filename format (filename*0 and filename*1)

(File name is "anonymized", but contained only "standard" ASCII)

correpsonding Evolution-MIME-Header:
(Evolution 2.22.3.1 (Ubuntu Hardy))
-------------------------------------------------
Content-Disposition: attachment; filename*0="Xxxxxxx xx XX-X Xxxxxxxxxxxxxxxxxx xx XxxxXxxxxxxxxx xx XXX X"; filename*1="XXX 15Nov07.pdf"
Content-Type: application/pdf; name*0="Xxxxxxx xx XX-X Xxxxxxxxxxxxxxxxxx xx XxxxXxxxxxxxxx xx XXX XXXX "; name*1="15Nov07.pdf"
Content-Transfer-Encoding: base64

in comparison:
MIME-Header using OWA on Exchange-Server 2003 (?) (Microsoft Exchange V6.5)
--------------------------------------------------------------------------------------------------------
Content-Type: application/pdf; name="Xxxxxxx xx XX-X Xxxxxxxxxxxxxxxxxx xx XxxxXxxxxxxxxx xx XXX XXXX 15Nov07.pdf"
Content-Transfer-Encoding: base64
Content-Description: Xxxxxxx xx XX-X Xxxxxxxxxxxxxxxxxx xx XxxxXxxxxxxxxx
        xx XXX XXXX 15Nov07.pdf
Content-Disposition: attachment; filename="Xxxxxxx xx XX-X Xxxxxxxxxxxxxxxxxx xx XxxxXxxxxxxxxx xx XXX XXXX 15Nov07.pdf"

I can confirm this bug. Especially when sending files with long names, spaces and/or letters like ä, ö and ü. Are there any news concerning this bug? I am willing to help.

vl@protheus:~$ uname -r
2.6.24-18-generic
vl@protheus:~$ evolution --version
GNOME evolution 2.22.3.1

The bug remains in

~$ uname -r
2.6.27-7-generic

~$ evolution --version
GNOME evolution 2.24.0

Greeting from China :-)

Is there any workaround?

Tested and it is still present, I ran into the same problem with a document name in spanish (using vowels with accents áéíóú) and it converted my PDF to a .DAT file.

It happens on Outlook 2007, 2003 and even on the OWA (Outlook Web Access), after reading this bug report I tried sending the same file changing the filename, by removing the accents and it worked, the file got to all the people I tried without problems.

If the same exchange account is configured in evolution and the message is opened, the attachment looks ok with the proper name.

I decided to create a message with 2 attachments, one with accent and the oner with regular characters. Obviously the non accented name came well to all the clients, but the other was converted. After looking at the source of the message I found this:

File 1, with accents:
Content-Disposition: attachment; filename*=ISO-8859-1''Presentaci%F3n%20de%20NODE.pdf
Content-Type: application/pdf; name*=ISO-8859-1''Presentaci%F3n%20de%20NODE.pdf

Where Presentaci%F3n%20de%20NODE should be "Presentación de NODE"

File 2, without accents:
Content-Disposition: attachment; filename="Propuesta de mantenimiento.pdf"
Content-Type: application/pdf; name="Propuesta de mantenimiento.pdf"

Seems odd also that instead of enclosing the filename between the quotation mark it is besides the quotation marks(there are 2 in there), I don't know how the RFC defines such cases, but it migth give some clues about the problem.

A quick note, I just tried sending the same email to my gmail account, there it recognizes the attachments with its original content, but still the filename is wrong, it marks it as: ISO-8859-1''Presentaci%F3n%20de%20NODE.pdf

Good to see other people confirming this bug. When I first posted about it, 7 months ago, I couldn't find people from other countries than Brazil with the problem.

Hggdh, do you know if anyone is actually working on this? Tell me if is there anything I can do to help, like debug, testing and such.

Regards,
Effenberg

Effenberg0x0, discussion kept on upstream until July, when it sort of fizzled.

All: it is not Evolution in error, but the rest of the world ;-).

I know, I know... just a joke (could not resist). Evolution is doing the Right Thing (TM), but Microsoft (and, per Milan upstream, pretty much all other servers he could hit) are not. The format Evolution is using *should* be accepted by others.

But it is not. So... disaster.

I strongly suggest that all of you go upstream and -- nicely, please! -- tell them you are having problems. Milan is even willing (or so it seems) to fix it, but not many users complained about it so far. It may be due to the fact that we strive very hard to be at the bleeding edge, while most other distributions are still with Evo 2.22 or older.

Milan, upstream, was nice enough to provide a tentative patch. I am trying to create a test package for Intrepid, and will give you pointers as soon as it is done.

@All: I have published the proposed fix for E-D-S 2.24.1 0ubuntu1, in my PPA (https://launchpad.net/~hggdh2/+archive). This is for Intrepid *ONLY* now.

This is an initial test for the fix, and we would like all to try it, and report here. Upstream is waiting for feedback to commit the change.

I intend to also publish a test package for Hardy, as soon as possible. The Hardy package will be considered for an official backport when we commit.

Again, we would really appreciate feedback on this fix.

assigning to myself

Hi Hggdh, thank you so much for your efforts on this very annoying bug.
I am away from the office right now, will be back tomorrow. As soon as I
get a chance, I'll install Intrepid in a virtual machine and test it.
Don't know if I actually know how to use the file you posted, but I'll
give it a try.

Regards,
Effenberg

-----Original Message-----
From: hggdh <email address hidden>
Reply-To: Bug 205999 <email address hidden>
To: <email address hidden>
Subject: [Bug 205999] Re: Attachments names using "ç" are not correctly
sent by Evolution (ATT<number>.dat)
Date: Tue, 04 Nov 2008 17:30:06 -0000

assigning to myself

** Changed in: evolution (Ubuntu)
     Assignee: Ubuntu Desktop Bugs (desktop-bugs) => hggdh (hggdh2)
       Status: Triaged => In Progress

Hi Effenberg0x0,

The link I provided has the instructions. Basically, you add the two lines shown to your /etc/apt/sources.list; then you either open Synaptic, update the repositories, and select the package (evolution-data-server-2.24.1-0ubuntu1ppa4), or you run from the command line (sudo apt-get update && sudo apt-get install evolution-data-server).

Meanwhile I am looking at the Hardy version of the fix.

@Holger: I am not sure how very long filenames will behave; I *know* spaces will still be a problem (only text after last space will be shown as the attachment filename).

The space issue -- most probably -- will *not* be corrected -- this seems an issue with Outlook indeed, per upstream.

I personally cannot test it since I do not have Outlook (or access to such).

@hggdh: I am out of office and only currently have sparse access to internet. I will test as soon as possible (if there are hardy packages available at the provided link) and give feedback. Thanks for the effort!

@Holger -- and, in fact, all: thanks. For the record, I have published both Intrepid and hardy packages.

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

Thank you Effenberb0x0. Could you please:

1. test with a more complex name, like (say) "ação.txt"? This might be a border-line error only;

2. Could you paste here the MIME headers for the tries?

Thnak you again.

Hi Hggdh, here's the test with "ação.txt'

Return-Path: <email address hidden>
Received: from [208.84.242.124] by calomba.hst.terra.com.br (LMTP); Thu,
06 Nov 2008
 19:31:11 +0000 (UTC)
X-Terra-Karma: -2%
X-Terra-Hash: 9bee4d71d40ef70f971deb21f8796488
Received-SPF: pass (gananoque.terra.com: domain of itdata.com.br
designates
 200.234.205.235 as permitted sender) client-ip=200.234.205.235;
 <email address hidden>; helo=hm770.locaweb.com.br;
Received: from hm770.locaweb.com.br (hm770.locaweb.com.br
[200.234.205.235])
 by gananoque.terra.com (Postfix) with SMTP id 9AF7540000047
 for <email address hidden>; Thu, 6 Nov 2008 19:31:10 +0000 (UTC)
Received: (qmail 12566 invoked from network); 6 Nov 2008 19:24:37 -0000
Received: from unknown (10.1.0.51) by hm770.locaweb.com.br with QMQP; 6
Nov 2008
 19:24:37 -0000
Received: from unknown (HELO ?192.168.1.101?)
(<email address hidden>@201.42.215.108) by
 hm1076.locaweb.com.br with SMTP; 6 Nov 2008 19:24:37 -0000
Subject: Test with =?ISO-8859-1?Q?a=E7=E3o=2Etxt?=
From: Alvaro Leal <email address hidden>
Reply-To: <email address hidden>
To: "alvaro.leal" <email address hidden>
Date: Thu, 06 Nov 2008 17:24:04 -0200
Message-Id: <1225999444.12922.14.camel@effenberg-mobile>
X-Mailer: Evolution 2.22.3.1
X-Abaca-Spam: 227 FD4A61931BQ ;
Content-Type: multipart/mixed; boundary="=-5hGpl2nVDtewDmbpAyxl"
MIME-Version: 1.0
Status: O

--=-5hGpl2nVDtewDmbpAyxl
Content-Type: multipart/alternative; boundary="=-9LPqIp6EAdc8L0s/erSH"

--=-9LPqIp6EAdc8L0s/erSH
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Test with ação.txt
Test with ação.txt
Test with ação.txt

Regards,
Effenberg

--=-9LPqIp6EAdc8L0s/erSH
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">
</HEAD>
<BODY>
Test with a&#231;&#227;o.txt<BR>
Test with a&#231;&#227;o.txt<BR>
Test with a&#231;&#227;o.txt<BR>
<BR>
Regards,<BR>
Effenberg
</BODY>
</HTML>

--=-9LPqIp6EAdc8L0s/erSH--

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

1234

--=-5hGpl2nVDtewDmbpAyxl--

-----Original Message-----
From: hggdh <email address hidden>
Reply-To: Bug 205999 <email address hidden>
To: <email address hidden>
Subject: [Bug 205999] Re: Attachments names using "ç" are not correctly
sent by Evolution (ATT<number>.dat)
Date: Thu, 06 Nov 2008 18:16:21 -0000

Thank you Effenberb0x0. Could you please:

1. test with a more complex name, like (say) "ação.txt"? This might be a
border-line error only;

2. Could you paste here the MIME headers for the tries?

Thnak you again.

Hggdh, what I sent you aboce, 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 workes perfectly.

Return-Path: <email address hidden>
Received: from [208.84.242.122] by calomba.hst.terra.com.br (LMTP); Thu, 06 Nov 2008
 19:34:30 +0000 (UTC)
X-Terra-Karma: -2%
X-Terra-Hash: 954d974ac7c43df09028e7ed6194285c
Received-SPF: pass (sintaluta.terra.com: domain of itdata.com.br designates
 200.234.205.235 as permitted sender) client-ip=200.234.205.235;
 <email address hidden>; helo=hm770.locaweb.com.br;
Received: from hm770.locaweb.com.br (hm770.locaweb.com.br [200.234.205.235])
 by sintaluta.terra.com (Postfix) with SMTP id 1BF7340000157
 for <email address hidden>; Thu, 6 Nov 2008 19:34:29 +0000 (UTC)
Received: (qmail 27941 invoked from network); 6 Nov 2008 19:28:14 -0000
Received: from unknown (10.1.0.51) by hm770.locaweb.com.br with QMQP; 6 Nov 2008
 19:28:14 -0000
Received: from unknown (HELO ?192.168.1.101?) (<email address hidden>@201.42.215.108) by
 hm1076.locaweb.com.br with SMTP; 6 Nov 2008 19:28:14 -0000
Subject: Test with letter =?ISO-8859-1?Q?=E7?= in the attachment
From: Alvaro Leal <email address hidden>
Reply-To: <email address hidden>
To: "alvaro.leal" <email address hidden>
Date: Thu, 06 Nov 2008 17:27:41 -0200
Message-Id: <1225999661.17668.2.camel@effenberg-mobile>
X-Mailer: Evolution 2.22.3.1
Content-Type: multipart/mixed; boundary="=-h+PqkzwHnOOeiXYbCxny"
MIME-Version: 1.0
Status: RO

--=-h+PqkzwHnOOeiXYbCxny
Content-Type: multipart/alternative; boundary="=-nXv9fwX3EIQFp3gZE+gD"

--=-nXv9fwX3EIQFp3gZE+gD
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Test with letter ç in the attachment

Thanks,
EFfenberg

--=-nXv9fwX3EIQFp3gZE+gD
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">
</HEAD>
<BODY>
Test with letter &#231; in the attachment<BR>
<BR>
Thanks,<BR>
EFfenberg
</BODY>
</HTML>

--=-nXv9fwX3EIQFp3gZE+gD--

--=-h+PqkzwHnOOeiXYbCxny
Content-Disposition: attachment; filename=ç.txt
Content-Type: text/plain; name=ç.txt; charset=UTF-8
Content-Transfer-Encoding: 7bit

123

--=-h+PqkzwHnOOeiXYbCxny--

I would like more tests; ideally, with similar filenames as were reported originally by each one of you. I have reported back upstream, but I feel we did not test it all:

- "zurück is back.whatever"
- "Hélène_photo.jpg"

etc, etc.

Unfortunately I have absolutely no access to Outlook*, so I cannot test it myself.

Hggdh: Can you send me all this tests? I'll post back the headers for
everything you send me.

-----Original Message-----
From: hggdh <email address hidden>
Reply-To: Bug 205999 <email address hidden>
To: <email address hidden>
Subject: [Bug 205999] Re: Attachments names using "ç" are not correctly
sent by Evolution (ATT<number>.dat)
Date: Fri, 07 Nov 2008 02:16:17 -0000

I would like more tests; ideally, with similar filenames as were
reported originally by each one of you. I have reported back upstream,
but I feel we did not test it all:

- "zurück is back.whatever"
- "Hélène_photo.jpg"

etc, etc.

Unfortunately I have absolutely no access to Outlook*, so I cannot test
it myself.

Effenberg0x0, I sent you 4 tests, 3 with Western-European compatible languages, and one with the Chinese/Kanji/whatever ideograms provided by Archangelwu in this bug.

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

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.

Thanks, Holger. I passed it to upstream. At least we do have an improvement -- the attachments are now recognised my Outlook*.

Hi Hggdh, sorry for the delay, I was at a meeting all day.

Test 1: I received ATT00022.TXT
=====================

Return-Path: <email address hidden>
Delivered-To: <email address hidden>
Received: (qmail 1982 invoked by uid 1000); 7 Nov 2008 13:49:29 -0000
Received: from unknown (10.1.10.55)
  by hm1076.locaweb.com.br with QMQP; 7 Nov 2008 13:49:29 -0000
X-LocaWeb-Detect-Virus: NON
Received: from unknown (HELO yx-out-1718.google.com) (74.125.44.158)
  by hm55.locaweb.com.br with SMTP; 7 Nov 2008 13:49:28 -0000
Received: by yx-out-1718.google.com with SMTP id 3so470782yxi.64
        for <email address hidden>; Fri, 07 Nov 2008 05:49:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:subject:from:to:content-type
         :date:message-id:mime-version:x-mailer;
        bh=p7idNBTQX+bgW2GtRgDikvENePX3/mknOEAv6xOz1p0=;
        b=WGfGsLpv6wU4NjkxsiOVK63nDyFISGjRMUZ9zAZGS7sy+DedNizeL5UJLUR6BtxfEi
         FMaZ/tKUvb7piES7WWzaDgxrFF/U7pH9ejIz5ASOP5+0ZDH/ZT7Xgf+M3C/i8Xs1Hnab
         IGS1Z4UOMOvuu6JvTA1GormMEyNzEi6ycJVAQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:content-type:date:message-id:mime-version:x-mailer;
        b=hqyx/Gxhe2AWyI1u92xmuT80FP3TWFxQSApPusCPmOaGoKvh+9f/ZVlMz9iY9GuUDl
         5McxklQPVy0bMU7Du1KLYN+em7+qkicpI4MRMUSNvUcfQqpO8hOFrpOl1cDrH0vvmaRy
         /57ZqI5osQ1Fm8ZtvITuAUty9iwXeLSrfsQLU=
Received: by 10.150.152.17 with SMTP id z17mr3558220ybd.63.1226065767227;
        Fri, 07 Nov 2008 05:49:27 -0800 (PST)
Return-Path: <email address hidden>
Received: from ?75.207.189.13? (13.sub-75-207-189.myvzw.com [75.207.189.13])
        by mx.google.com with ESMTPS id m73sm3557165rnd.0.2008.11.07.05.49.25
        (version=SSLv3 cipher=RC4-MD5);
        Fri, 07 Nov 2008 05:49:26 -0800 (PST)
Subject: test 1
From: HggdH <email address hidden>
To: Effenberg0x0 <email address hidden>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Y0sbZFuGqjJ9L8euC7aP"
Date: Fri, 07 Nov 2008 07:49:24 -0600
Message-Id: <1226065764.25744.0.camel@xango2>
Mime-Version: 1.0
X-Mailer: Evolution 2.25.2

--=-Y0sbZFuGqjJ9L8euC7aP
Content-Type: multipart/mixed; boundary="=-XgAkPpDcEgkAZ19zNDQ/"

--=-XgAkPpDcEgkAZ19zNDQ/
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

--=-XgAkPpDcEgkAZ19zNDQ/
Content-Disposition: attachment; filename*=ISO-8859-1''Documenta%E7%E3o.txt
Content-Transfer-Encoding: base64
Content-Type: text/plain; name*=ISO-8859-1''Documenta%E7%E3o.txt; charset="ISO-8859-1"

dGVzdA0K

--=-XgAkPpDcEgkAZ19zNDQ/--

--=-Y0sbZFuGqjJ9L8euC7aP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEUEABECAAYFAkkUR2MACgkQfbrzscpaDCA59gCgxKIqGrp9US2qMWy4QQ2tRzpn
d0UAlRCFroOBIs5gCfc9MLtkmpmV3iE=
=nN3m
-----END PGP SIGNATURE-----

--=-Y0sbZFuGqjJ9L8euC7aP--

Test 2: I received ATT00031.TXT
=====================

Return-Path: <email address hidden>
Delivered-To: <email address hidden>
Received: (qmail 5421 invoked b...

I am kicking myself -- this was my own error: I used Evo 2.25.1 SVN trunk... of course, this fix is *not* there. I will do it again with a 2.24.1 patched.

Very sorry, Effenberb0x0.

Hddgh, lol, ok here are the headers:

Test 1 resend: I received Documentação.txt (yes, with this weird chars in the file name, but better than ATTxxxx anyway).
==============================
Return-Path: <email address hidden>
Delivered-To: <email address hidden>
Received: (qmail 31366 invoked by uid 1000); 7 Nov 2008 20:27:37 -0000
Received: from unknown (10.1.10.166)
  by hm1076.locaweb.com.br with QMQP; 7 Nov 2008 20:27:37 -0000
X-LocaWeb-Detect-Virus: NON
Received: from unknown (HELO qw-out-1920.google.com) (74.125.92.144)
  by hm166.locaweb.com.br with SMTP; 7 Nov 2008 20:27:36 -0000
Received: by qw-out-1920.google.com with SMTP id 5so851885qwf.34
        for <email address hidden>; Fri, 07 Nov 2008 12:27:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:subject:from:to:content-type
         :date:message-id:mime-version:x-mailer;
        bh=Dh7fiLpX2JsWjjw9DCE4/EsTHw/AwchgI2Ig3FEOA+c=;
        b=pLOTAR3Xsk6NAv7oOvm1HhtwCWGevU9a9k7mYL3Fp3Pr25vbII8jXHNOTjbRZAnwIk
         zY3/GKAPZDNGgYmVVO8v6S9LRMR43pkZcIRp4ksNdUvMmcDFz/NmkRNopbWSndV2YS/A
         i412+Be7W8JIW/RBotvqM9oZSnCGJEFGqa/d4=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:content-type:date:message-id:mime-version:x-mailer;
        b=qYC2BMmaTJZeilEevbhDt5jR7U1VPlGRWYgZzcNDpE9ESdCoo9U1dqIyjtC9b8WhPz
         bNtexw8Fh1Q+ybOAVOTSlQrS02kYUL1KBdFPofRuqMniAOl8LOcPRtzPBQqmzC0+DRy/
         RkGhwscPtgeDvhspD7NxkkVFnuFgckLApfSLc=
Received: by 10.214.10.8 with SMTP id 8mr4682668qaj.293.1226089655837;
        Fri, 07 Nov 2008 12:27:35 -0800 (PST)
Return-Path: <email address hidden>
Received: from ?75.207.189.13? (13.sub-75-207-189.myvzw.com [75.207.189.13])
        by mx.google.com with ESMTPS id 6sm8721723yxg.6.2008.11.07.12.27.33
        (version=SSLv3 cipher=RC4-MD5);
        Fri, 07 Nov 2008 12:27:35 -0800 (PST)
Subject: test 1 resend
From: HggdH <email address hidden>
To: Effenberg0x0 <email address hidden>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-o3BubJ0ytExqorHNz9Wi"
Date: Fri, 07 Nov 2008 14:27:31 -0600
Message-Id: <1226089651.17456.0.camel@xango2>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.1

--=-o3BubJ0ytExqorHNz9Wi
Content-Type: multipart/mixed; boundary="=-W1+lCY/R/pUAf1INHzH9"

--=-W1+lCY/R/pUAf1INHzH9
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

--=-W1+lCY/R/pUAf1INHzH9
Content-Disposition: attachment; filename="Documentação.txt"
Content-Transfer-Encoding: base64
Content-Type: text/plain; name="Documentação.txt"; charset="ISO-8859-1"

dGVzdA0K

--=-W1+lCY/R/pUAf1INHzH9--

--=-o3BubJ0ytExqorHNz9Wi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkkUpLMACgkQfbrzscpaDCByOQCffqTbykejbA2BBDBNFF3e20al
ITsAn0oA1R/t1sRj7QHkiZ8UX5yN5O7z
=M8Mg
-----END PGP SIGNATURE-----

--=-o3BubJ0ytExqorHNz9Wi--

Test 2 resend: I received Hélène_photo.txt (yes, with this weird chars in the file name, but better t...

The last one (the one with Kanji/whatever ideograms was correctly received -- this is indeed the real file name.

Meanwhile upstream has created a new version of the patch, based on the comments so far. I will be building a new release of the E-D-S packages, for Hardy and Intrepid. As soon as this is available I will post a comment here.

Thank you for your tests. I really appreciate the help.

Updated test packages have been published. Please upgrade & test & report back. Thank you.

It looks like its fixed!!!
Send me some tests Hggdh, I'll post the results back.

Hddgh, here are the headers for these last tests you sent me:

Test 1 resend: I received Documentação.txt
==============================
Return-Path: <email address hidden>
Delivered-To: <email address hidden>
Received: (qmail 20853 invoked by uid 1000); 8 Nov 2008 22:04:29 -0000
Received: from unknown (10.1.10.41)
  by hm1076.locaweb.com.br with QMQP; 8 Nov 2008 22:04:29 -0000
X-LocaWeb-Detect-Virus: NON
Received: from unknown (HELO nf-out-0910.google.com) (64.233.182.187)
  by hm473 with SMTP; 8 Nov 2008 22:04:28 -0000
Received: by nf-out-0910.google.com with SMTP id b2so933224nfb.34
        for <email address hidden>; Sat, 08 Nov 2008 14:04:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:subject:from:to:content-type
         :date:message-id:mime-version:x-mailer;
        bh=gax2pmEnTicBAYnhVG+zr523yPjsmzxhrWDMzOqg6Ps=;
        b=WDDmWY+Up45K7nxXLPABjzFB/xVcxYmXiwggzl+3CdaonJiTLI0EzX0hHaJ1BFY4ws
         KRJcu0ZBjyW+h4yY/njq6Q4wzxreFDWOl6CBAV2pEDC6I+eiziXtfBA21UkgqrRn+MtT
         dVmMEdispOufdFPwgys/S/iRdFU/BY2TRYJl4=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:content-type:date:message-id:mime-version:x-mailer;
        b=gmSxhB4oJA2RemW3O7ABV5y8DBx4UZpcSUOYzvIci4sTtoMmR6YMlIItmGCYdTnRp3
         +vi5sr2Cd4BSzHRyf2cIeGqpzZKu1gY8jf1nxEaEQrPLl3K098GKU2uRprgOdHl4SnhW
         O+b6EEkvA0yNVdbsty0Btsm2mIgeAuMcJMzgs=
Received: by 10.210.41.1 with SMTP id o1mr2133008ebo.179.1226181867322;
        Sat, 08 Nov 2008 14:04:27 -0800 (PST)
Return-Path: <email address hidden>
Received: from ?192.168.2.100? (pool-71-164-230-11.dllstx.fios.verizon.net [71.164.230.11])
        by mx.google.com with ESMTPS id 3sm6860081eyi.5.2008.11.08.14.04.25
        (version=SSLv3 cipher=RC4-MD5);
        Sat, 08 Nov 2008 14:04:26 -0800 (PST)
Subject: test 1 resend
From: HggdH <email address hidden>
To: Effenberg0x0 <email address hidden>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-UU+0Im7nodBzB83Gor9f"
Date: Sat, 08 Nov 2008 16:04:23 -0600
Message-Id: <1226181863.16303.8.camel@xango2>
Mime-Version: 1.0
X-Mailer: Evolution 2.25.2

--=-UU+0Im7nodBzB83Gor9f
Content-Type: multipart/mixed; boundary="=-fB3+M2PE2bLjgj8+TJMS"

--=-fB3+M2PE2bLjgj8+TJMS
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

--=-fB3+M2PE2bLjgj8+TJMS
Content-Disposition: attachment; filename="Documentação.txt"
Content-Transfer-Encoding: base64
Content-Type: text/plain; name="Documentação.txt"; charset="ISO-8859-1"

dGVzdA0K

--=-fB3+M2PE2bLjgj8+TJMS--

--=-UU+0Im7nodBzB83Gor9f
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkkWDOcACgkQfbrzscpaDCAMCQCgy6q7D5teKcX0e7b5oMoaAIiF
QboAn1p9F5Tk4eVsCHwk1HAzuWLrNZ6Y
=WP7Q
-----END PGP SIGNATURE-----

--=-UU+0Im7nodBzB83Gor9f--

Test 3 resend: I received Hélène_photo.txt
==============================
Return-Path: <email address hidden>
Delivered-To: <email address hidden>
Recei...

So, it seems we don't have the ATT<something>.DAT problem anymore, but the file names are displayed truncated on the Window Box.

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

@Holger: I am not sure why you could not get the updates... perhaps 'apt-get dist-upgrade' would do the trick.

Good to know it is working for you -- but it did not work for me and effenberg0x0 :-(. One reason I see is -- somehow, yet unknown reasons -- you get your encoding as UTF-8, and both of us get it as ISO-8859-1. This may have something to do with our Linux setup.

Anyway, we are still discussing this upstream, so the fix is still in test. I expect Milan will have a new one soon, and I will update the PPA with it.

Upstream proposed a new patch; I tested it against Evo SVN trunk, and it seems to be working. I will now look at backporting it, but we will need some internal discussions on that -- there are string changes on the new patch, and we need to see what might be involved on this.

This might take a bit of time.

Ah well. The new patch does not apply good in 2.22.3... we have a major rewrite on glade and user interface between 2.22 and 2.24. I am not sure how we will proceed here... more on that tomorrow.

new Intrepid packages have been published on my PPA for tests. *BOTH* Evolution and Evolution-Data-Server (and associated libraries) *must* be upgraded.

Please test & report back.

Currently no backporting for Hardy is being considered.

Upstream has committed the fix to trunk. We will see if an official upgrade to Intrepid can be done, but -- right now --, no backporting to Hardy is being considered.

Hi, hggdh,

     Thank you for your instant response and hard work.

     But unfortunately, it seems in my system (Chinese character), it doesn't work. I still received ATT<nnnnn>.dat in outlook
and gb2312''%D6%D0%CE%C4%CE%C4%BC%FE%C3%FB_Chinese_File_Name.txt in gmail
while my file name is “中文文件名_Chinese_File_Name.txt”

my sources.list is:
deb http://ppa.launchpad.net/hggdh2/ubuntu intrepid main
deb-src http://ppa.launchpad.net/hggdh2/ubuntu intrepid main

    The attached picture shows the evolution packages that I have installed.

I think that maybe I missed something, so when the official upgrade to Intrepid releases, I will sync and try?

     Shall I give any more info?

Regards.

Hi CooCoo,

When you upgraded Evolution and E-D-S -- did you also upgrade the libraries?

    * libcamel1.2-14_2.24.1-0ubuntu1ppa8
    * libebackend1.2-0_2.24.1-0ubuntu1ppa8
    * libebook1.2-9_2.24.1-0ubuntu1ppa8
    * libecal1.2-7_2.24.1-0ubuntu1ppa8
    * libedata-book1.2-2_2.24.1-0ubuntu1ppa8
    * libedata-cal1.2-6_2.24.1-0ubuntu1ppa8
    * libedataserver1.2-11_2.24.1-0ubuntu1ppa8
    * libedataserverui1.2-8_2.24.1-0ubuntu1ppa8
    * libegroupwise1.2-13_2.24.1-0ubuntu1ppa8
    * libexchange-storage1.2-3_2.24.1-0ubuntu1ppa8
    * libgdata-google1.2-1_2.24.1-0ubuntu1ppa8
    * libgdata1.2-1_2.24.1-0ubuntu1ppa8

Most of them would not be required, but should still be upgraded for consistency.

Certainly, libcamel *is* required.

Please check. If you *did* upgrade, I would like to have the MIME headers of your test emails.

Hi, hggdh,

        Thank you for your kind help.

        But after a blindly automatic system update, I found the evolution was changed to the release version.
And when I use "apt-get install evolution", it said that "evolution is now the newest version" (Translated from Chinese:) )
It seems that I have to wait for the official release upgrade? ( I am a freshman on ubuntu :)

----------------------------
$ sudo apt-get install evolution
正在读取软件包列表... 完成
正在分析软件包的依赖关系树
正在读取状态信息... 完成
evolution 已经是最新的版本了。
下列软件包是自动安装的并且现在不再被使用了：
  libuser-identity-perl libchewing3-data scim-modules-table ttf-wqy-zenhei
  libmime-types-perl linux-headers-2.6.27-7 thunderbird-locale-zh-cn
  scim-chewing thunderbird-locale-zh-tw scim-tables-zh
  linux-headers-2.6.27-7-generic libfile-remove-perl libchewing3
  libio-stringy-perl xfonts-wqy language-support-input-zh
  libobject-realize-later-perl ttf-arphic-ukai openoffice.org-l10n-zh-tw lrzsz
  scim-pinyin openoffice.org-help-zh-tw libdigest-hmac-perl
  language-support-fonts-zh libmail-box-perl libdigest-sha1-perl
使用'apt-get autoremove'来删除它们
共升级了 0 个软件包，新安装了 0 个软件包，要卸载 0 个软件包，有 0 个软件未被升级。

----------------------------

Hi CooCoo,

an update for Evolution was pushed last week/this week; I have not yet created a new test package for this version level.

I should be able to do it this evening.

An updated version of Evolution and Evolution-data-server is available from my PPA. Please make sure *all* packages for the Intrepid version are updated. The easiest way to do that is by running and accepting all updates.

No Hardy packages will be built -- the affected code changed radically from 2.22 to 2.24 and later.

This brings us to 2.24.1.1. Upstream should release yet another update to Evo in about 2 weeks, and we will go again through the process until we find if the fix works correctly or not.

For the record, the fix has been committed to Evolution trunk, currently 2.25.2 (which will be available on Jaunty).

Hi, hggdh,

        I am glad to report that the issue was resolved after the new update.

        Thank you for your hard effort! :-)

Hi Hggdh,

I have just installed Intrepid on 5 machines here, fully updated them, added your PPA to sources.list and updated all machines again.

To my surprise, ATT<something>.dat seems to be back :( "Método de Ação.txt" triggered it again.

I was under the impression that it was working for Intrepid. Can you give me a hand here?

Strange... what version of the PPA did you install (current is *-2.24.2-0ubuntu1ppa2), published yesterday evening)?

aleal@aleal-mobile:~$ apt-cache policy evolution
evolution:
  Instalado: 2.24.2-0ubuntu1ppa2
  Candidato: 2.24.2-0ubuntu1ppa2
  Tabela de versão:
 *** 2.24.2-0ubuntu1ppa2 0
        500 http://ppa.launchpad.net intrepid/main Packages
        100 /var/lib/dpkg/status
     2.24.1-0ubuntu2 0
        500 http://br.archive.ubuntu.com intrepid/main Packages
aleal@aleal-mobile:~$

I have tested it over and over today, it really is still broken
. Also, I experienced some new segfaults, but I didn't had the time to get information on that.

the new version is in jaunty now

Hi, when I update my ubuntu from 8.10 to 9.04 (jaunty),
I found that the problem appeared again.

evolution 2.26.1

I'm having the same problem.
Attachments using ç, ö, á, etc are sent by evolution as .dat format.
Running evo 2.26.1 on Jaunty.

~$ apt-cache policy evolution
evolution:
  Instalado: 2.26.1-0ubuntu2
  Candidato: 2.26.1-0ubuntu2
  Tabela de Versão:
 *** 2.26.1-0ubuntu2 0
        500 http://archive.ubuntu.com jaunty-proposed/main Packages
        100 /var/lib/dpkg/status
     2.26.1-0ubuntu1 0
        500 http://archive.ubuntu.com jaunty/main Packages

Any news?

Hi,
I dont write good english but wil try
This is the solution for compatibility between ubuntu evolution and office outlook

Evolution 2.26.1

Open evolution
Go to
"Editar/Preferencias/Preferencias del editor"

Here choose the option
"codificar nombres de archivo de la forma Outlook/Gmail"

Its work for me!!

Bye

Saludos!!

This problem exist in ubuntu 9.10
Send an attachment with Chinese filename, the receiver could not know the original filename.

 apt-cache policy evolution
evolution:
  Installed: 2.28.1-0ubuntu2
  Candidate: 2.28.1-0ubuntu2
  Version table:
 *** 2.28.1-0ubuntu2 0
        500 http://210.77.68.241 karmic-updates/main Packages
        100 /var/lib/dpkg/status
     2.28.1-0ubuntu1 0
        500 http://210.77.68.241 karmic/main Packages

Sorry, get the answer:
It is an option now in ubuntu 9.10, just as AFP_SCH(#68) said:
check the option in : edit -> preference -> composite preferences (unsure, the fourth) -> general
Encode file names in an Outlook/GMail way

Hi,

Using the "Encode file names in an Outlook/GMail way" resolves the problem of attachment names received by Outlook.
The attachment names are still not correctly displayed in sent-emails and when sent from Evolution to Evolution.

Evolution should read correctly attachment file names using this option.

Has somebody found a workaround for this issue ?

Evolution 2.28.3
Ubuntu 10.04 LTS - the Lucid Lynx

I have the same problem on Ubuntu 10.10 with Evolution 2.30.3.