Description of problem:
A few times, I've seen Evolution fail, without any kind of warning, to put sent
mail into the "Sent" folder. The mail is actually sent alright, but this problem
makes it hard to track conversations, audit and such. More importantly, it makes
the user "lose data", they thought they had.
I'm running against a dovecot IMAP server (currently via an SSH tunnel, but I've
seen the problem over normal IMAP too)
Version-Release number of selected component (if applicable):
I've seen this happen a few times but am not able to reproduce on demand. There
does not seem to be any interesting messages in logfiles or .xsession-errors or
such that I've been able to find. :o(
I'm kind of hoping that someone else has seen this and has been able to find
some signs to where the problem lies. I can't say with 100% certainty that this
isn't a server (dovecot-1.0-1.2.rc15.el5) problem, but I've only seen this with
Let me know if there's anything I can do to get you guys more info.
Created attachment 155433 [details]
evolution related stuff from .xsession-errors log when this happened
Just happened again when replying to a mail.
It looks like evolution has put stuff into the .xsession-errors file, so i've
extracted evolution related stuff from that file and attached it here for your
viewing pleasure. Unfortunately, all I see is the error messages (nothing
specifically related to this) I'd like to have seen DEBUG info, to track down
where it goes wrong. but even --debug doesn't provide this!?
Thanks for the additional info. This looks awfully suspicious:
(evolution:6842): camel-imap-provider-CRITICAL **: imap_command_start: assertion
Looks like maybe Evolution was trying to issue a command to the IMAP server and
for some reason the output stream was invalid. Might possibly be your missing
Hmmm! Is there anything I can do to up the verbosity of these messages?
Like I mentioned - I'm running over an SSH connection and while it can sometimes
be sluggish, the connection was not broken. The tunnel lacks the ability to
reconnect, meaning that I'll be prompted for a password it the connection
breaks. That's how I know that connection was not down in this case. Also, the
mail is sent (SMTP) through the same tunnel and I can tell from the postfix logs
that no problems appeared with the SMTP communication.
Perhaps some IMAP handshaking/initialization/re-connection code is too
optimistic and needs some some retry functionality? I have no idea how evolution
works in this area.
I would really be useful if we could increase the verbosity to figure out
exactly what goes wrong.
Yes, here's some information on generating debugging messages:
(see the "Discover What Causes the Bug" section)
You'll want to set at least CAMEL_DEBUG=all and CAMEL_VERBOSE_DEBUG=1.
Is this problem still present on Fedora 8 Test 2 or later?
I'm not running Fedora 8 test 2 or later on any of my machines, and won't until
F8 is our for real... Is there some specific components you'd like me to update
on my F7 for a similar result?
Thanks for responding. Fedora 8 will be out enough so no rush. If you want you
can try upgrading your evolution and evolution-data-server packages to what's
currently in Rawhide.
Setting this back to NEEDINFO for the time being to help me track it.
The problem still exists in F8T3 (current as of today), with Evolution running
against an Exchange server, and it's fully reproducible. When replying to mails
the reply is never stored in the Sent Items folder, but the envelope in the
leftmost column of the Inbox view is decorated with an orange arrow, indicating
that the mail has been replied to.
I found an upstream bug that sounds similar:
The reporter claims it occurs if, while composing a message, you click on a folder from a different IMAP account than the one you're sending from. Sounds kinda fishy to me, but thought I'd mention it since we haven't found a pattern for the "sometimes" aspect of the bug report.
Sorry this has been sitting idle for so long. Is anyone still seeing Evolution occasionally drop sent messages using Fedora 10 or later?
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
This is no longer a problem on my fully updated F10 install.