Created attachment 136806 [details]
Sample mbox file

This should mainly happen with large piece of text being pasted and nothing to do with the traces alone. The problem should be while sending large size plain text mails.

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

Created attachment 140049 [details]
4KB.txt

I wonder why you call 4KB large text file. Anything larger than or equal to 4KB is put into a generic stream, instead of a body stream, in camel-mapi-transport.c::mapi_item_set_body_stream. Then I guess there should be some flag indicating the body is in other place.

I tried the openchangeclient, like this:
openchangeclient -f ~/.evolution/mapi-profiles.ldb -S -t "my-email-address" -P password -s "test 4kb" --html-file ../4kB.txt

and the received message is truncated at 4KB, even I see on console:
> We are about to write 4102 bytes in the stream
> ...    sendmail                 : MAPI_E_SUCCESS (0x0)
I guess it's truncated in 4KB, the last 4000 is shown as 400 only.

Oh, ok, with openchangeclient, when I enlarge a file to 5KB the it ends with 500 instead of 5000, thus I guess it's just "one-byte-off" issue.

Created attachment 140051 [details]
ema.patch

this is what I changed. Notice:
a) mapi_sync_deleted - it cause crashing to me
b) mapi_send_to - there should be _decode_ instead of _write_ function used

Created attachment 140052 [details]
ecs.txt in UTF-8

when using for sending this file, I get some letters broken with openchangeclient, it generates in the body: <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15">&#155;š&#141;&#153;žýáíé
no idea where it get it from, as this should be UTF-8.

ema, on the other hand, is not able to send this at all (pasted file content to plain text message body).

CC'ing Julien to let him know about the above.

Patch seems to work fine in terms of encoding but i get 'cann't send message' error pop up many time and cann't flush outbox after many attempts and it's crashing also , see bug 591032 

(In reply to comment #9)
> Patch seems to work fine in terms of encoding but i get 'cann't send message'
> error pop up many time and cann't flush outbox after many attempts and it's
> crashing also , see bug 591032 

Yeah, that might be because of that _write_ to _decode_ function change. It doesn't like UTF8 letters.

Urhm, this bug seems quite reproducible: it happens every time to me if I reply to a larger message.  Surely this needs to be fixed to have even a minimally functional backend?

I have 2.28.2 in Fedora 12 and I can confirm the bug.
I can't send attachment via email of forward an existing one. 

Small attachments pass through but larger ones aren't sent.

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

I partially touched this in bug #608320, and I have few other changes for this, but it's still not there. I'll update when I'll have something.

Created attachment 152596 [details] [review]
ema patch

for evolution-mapi;

With this patch I can send attachments of "any" length, also body content length is no longer a problem (it was there, only needed few tweaks). I changed slightly message decomposition routine, and body content picking, so if you delete your local summary of downloaded messages (~/.evolution/mail/mapi/<account>/folders/ - note folders.db is not needed to be deleted), then you should also get your unicode messages better or the same as before.

Created commit 16f0e65 in ema master (0.29.90+)
Created commit ff76193 in ema gnome-2-28 (0.28.3+)

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

Still can't sent attachements larger than 4K on FEdora 12 with Evolution 2.28.2
In which release is this fixed?

(In reply to comment #16)
> Created commit 16f0e65 in ema master (0.29.90+)
> Created commit ff76193 in ema gnome-2-28 (0.28.3+)

As this comment says, 0.28.3+ evolution-mapi 0.28.3 release should have the fix for this

I can confirm that this issue is resolved with 2.28.3 in Fedora 12. 

Thank you very much!

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

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