On Wed, 2004-07-07 at 18:36 +0200, Olivier DUGEON wrote: > Hi Jeffrey, > > Le mar 06/07/2004 à 19:29, Jeffrey Stedfast a écrit : > > On Tue, 2004-07-06 at 19:04 +0200, Olivier DUGEON wrote: > > > Hi all, > > [...] > > > > My problem comes with attachement and long list of correspondant (say > > > > 20). If I put me in copy, the e-mail I sent was correctly handle by > > > evolution. But, the mail was completely broken for my correspondant > > > who used outlook. The message and the attachement were not interpreted > > > correctly and saw as plain text (i.e. you see the base64 encoding of > > > the attachement in the body of the e-mail). > > > > sounds like an Exchange bug or an Outlook bug. > > I made extra test. So, I discover that all works well if you stay within > the same exchange server. Recipient that are serve by the same exchange > server received correctly the message. > > But, people who are located in another exchange server received a > corrupted message. > > I made another similar test (same message) but this time with mozilla > mail. The test ran ok. The main difference is that mozilla put a CR > after each e-mail address, so the file never exceed the 1024 bytes long > despite that the "To:" field is larger than 1024 bytes. > > > > > when Evolution encodes the email in base64, it sets the Content- > > Transfer-Encoding: header to a value of "base64". You'll see this if you > > look at the message sources in your Sent folder. > > > > Outlook/Exchange/whatever is supposed to respect that header. apparently > > one of them is not. > > > > Yes, apparently the problem comes from an Exchange server because > outlook parse correctly the message when it was received from the same > server (and not corrupted of course !) > > > > > > [...] > > > > > > > - Is somebody have experienced the same problem ? > > > > I have never heard of anyone having any such problem > > > > This explain why I never find any info on the web nor in mailing list. > > > > - Is it a well-know bug of evolution or is it my configuration ? > > > > might be an exchange bug? might be an evo bug. not enough info to know > > for sure. > > > > can you get us a copy of the raw message sources (as extracted from the > > Sent folder's mbox file)? then we can check that the lines were folded > > appropriately. if they weren't, then it's an evo bug. else it's an > > Exchange bug. > > I can send you directly the message if you want. I don't want to bounce > the mailing list. > > > > > > - Is there something in the RFC which tell that the "To:" or "Cc:" > > > field couldn't be larger than 1024 char. ? > > > > there is no such restriction in any of the mail rfcs. headers can be of > > any length so long as they are folder appropriately (such that no single > > *line* is longer than 1000 bytes) > > Ok. This is the problem with evo. It never fold the single line. I > attach an extract of the message comes from the Sent mbox (I delete the > 2nd attachement). You can see that the "To:" and "CC:" are not fold and > are longer than 1000 bytes. it looks to me like you used Evolution's "View Source" to extract this mesage content rather than getting it using a text editor from the file on disk. To check my theory, I apsted all the To headers into a composer and saved the message to disk and I got: To: Olivier Dugeon <Olivier Dugeon wanadoo fr>, LONGFOO1 BAR FTRD/FOO/BAR <longfoo1 bar rd francetelecom com>, LONGFOO2 BAR FTRD/FOO/BAR <longfoo2 bar rd francetelecom com>, LONGFOO3 BAR FTRD/FOO/BAR <longfoo3 bar rd francetelecom com>, LONGFOO4 BAR FTRD/FOO/BAR <longfoo4 bar rd francetelecom com>, LONGFOO5 BAR FTRD/FOO/BAR <longfoo5 bar rd francetelecom com>, LONGFOO6 BAR FTRD/FOO/BAR <longfoo6 bar rd francetelecom com>, LONGFOO7 BAR FTRD/FOO/BAR <longfoo7 bar rd francetelecom com>, LONGFOO8 BAR FTRD/FOO/BAR <longfoo8 bar rd francetelecom com>, LONGFOO9 BAR FTRD/FOO/BAR <longfoo9 bar rd francetelecom com>, LONGFOO10 BAR FTRD/FOO/BAR <longfoo10 bar rd francetelecom com>, LONGFOO11 BAR FTRD/FOO/BAR <longfoo11 bar rd francetelecom com>, LONGFOO12 BAR FTRD/FOO/BAR <longfoo12 bar rd francetelecom com>, LONGFOO13 BAR FTRD/FOO/BAR <longfoo bar13 rd francetelecom com>, LONGFOO14 BAR FTRD/FOO/BAR <longfoo14 bar rd francetelecom com>, LONGFOO15 BAR FTRD/FOO/BAR <longfoo15 bar rd francetelecom com>, LONGFOO16 BAR FTRD/FOO/BAR <longfoo16 bar rd francetelecom com>, zze-airtri01 ext FTRD/RSCL/LAN <airtri01 ext rd francetelecom com> Notice how they are properly folded just as I suspected. so this is most definetely not an Evolution bug. > > > > > > - Is it possible to hack evolution (the mailer part) to split the > > > "To:" or "Cc:" line when it will be larger than 1024 char. ? > > > > feel free to hack it any way you want. > > > > anything's possible, but we won't be doing this. > > Ok. I understand. Can you tell me in which file or files the header To > and CC are formated ie. which file(s) I need to hack ? The evo source is > too big to search in all files. there doesn't seem to be anything to fix, it formats it properly already. but, the code would probably be in camel-internet-address.c Jeff -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. fejj ximian com - www.novell.com
Attachment:
smime.p7s
Description: S/MIME cryptographic signature