Re: [Evolution] Corrupted mail send to too many correspondant

[Jeffrey Stedfast <fejj ximian com>]

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