Red Hat Bugzilla – Bug 239215
Evolution escapes 'From ' on sending mail.
Last modified: 2008-03-13 04:12:30 EDT
When sending mail with lines starting 'From ', Evolution will escape them by
adding '>' at the beginning of the line.
It's not clear why Evolution would ever do that on sending mail -- that's _only_
required when delivering into mbox storage, and Evolution doesn't _do_ any mail
delivery to mboxes (except possibly in the case of copying a mail from non-mbox
to mbox storage).
It certainly shouldn't be doing it on _sending_.
This has confused me for a while because I think bugzilla might also do the same
when it sees a line starting with
From -- but I've just sent test messages with both Evolution and 'mail' and
inspected them immediately on the queue of the mail server, and Evolution is
definitely doing it.
This escaping also happens in the sent-mail folder (IMAP, backed by Maildir).
It's not just in the SMTP transaction.
GNOME bug 245683 is closed. I'm not going to get involved with the muppet who
closed it -- please could someone else reopen it.
Note that this corruption _is_ noticeable to Evo users -- I see the '>From'
quite clearly, and lines appearing in grey as if they're quotes, rather than
black for original text.
We did reopen that GNOME bug. I will provide a patch, in a while, which could
help and I'll be glad if you could test it. Then, if it will work good, I'll put
that patch upstream.
Created attachment 155181 [details]
proposed patch 1/2
Created attachment 155182 [details]
proposed patch 2/2
Hm, it seems I can no longer commit to a private branch in CVS, as I've been
doing for as long as I can remember to get usable evolution and e-d-s builds.
With a local build, though, that does seem to work. Thanks.
Cool, I'll get these patches into Rawhide then.
Note that I don't actually use mbox files -- except for the local Outbox of course.
So it's probably worth having someone who _does_ use mbox mailboxes test too.
My packages are in a yum repo at ftp://ftp.infradead.org/pub/dwmw2-fc7/ but
since I couldn't commit to CVS I haven't built in koji -- it's just a local
build so it's ppc only. The src.rpm is there too though.
I copied those patch files to upstream bug, maybe they will commit it to trunk too.
Based on Jeff's comments in the upstream bug , it seems the root problem here
is that Evolution uses mbox for its Outbox folder when it really should be using
maildir. That's an issue for upstream to address.
But in the meantime Jeff also suggested passing a newly-written message through
CamelMimeFilterCanon to change lines beginning with "From " to "=46rom " using
Quoted-Printable encoding. That sounds like a reasonable workaround and
something we could do.
Milan, would you like to take a shot at implementing Jeff's suggestion?
Sounds like making it use maildir would be the better fix. Why can't we do that
and offer it to upstream?
It would be, but Jeff seems to think the transition would be painful. I don't
really have a sense of it myself though I can imagine backward compatibility
being a major concern.
I'm okay with offering upstream a patch to use maildir, but I don't want to have
to maintain such a patch in Fedora/RHEL. Upstream would have to accept the
patch and trickle it down to us by way of a new release.
The workaround, however, sounds simpler and I'd be okay with maintaining such a
patch (at least for awhile), assuming it works.
From email conversation about this with Matt,
> Matt wrote:
> I think we should try to implement Jeff's suggestion to use
> quoted-printable encoding to keep mbox "From " lines from
> getting mangled. Once David Woodhouse is satisfied with it,
> forward the solution upstream. I imagine varadhan will review
> Do you think you can try that?
I think that quoted-printable isn't the right way, because you need to
change original encoding to ours and, for example, when you have a mail
in plain-text/7bit, somewhere inside it with text: "69-4=65", then after
changing from 7bit to quote-printable, you will get in evolution "69-4A"
which isn't obviously that on "input" (you know, same output like
input). The same for camel-mime-filter-canon, which is only one-way,
from "From " to "=46rom " no way to get back properly. All that same
output as input is also for signatures, because you alter message body,
then you will never restore back what you'd got on input.
Most easier way was about that qmail behavior, which Jeff rejected. So a
workaround is changing for default local stores to other type, which
didn't suffer from this kind of troubles, like was mentioned in GN-bug.
As I was talking to varadhan last week, he need to do an import because
of change from "spool" protocol to "spoolfile"/"spooldir", which he
thinks is better than changing UI, and I suggest hit that we could join
this import together with changing default local stores, and he admitted
that we could. Unfortunately there is still no progress about
varadhan's talk to Jeff about "spool".
As I think about this now, it could be some kind of work to have a
checkbox with mbox, which will say something like "Behave as qmail
mbox" (but something more sense-able for customers), maybe default
checked, and it will turning on/off this ">>From " => ">>>From "
conversions from/to mbox file.
*** Bug 288351 has been marked as a duplicate of this bug. ***
This bug is annoying. I could understand changing my e-mail while I write it,
but not after I have clicked send.
This bug is somehow stuck in upstream, unfortunately. Jeff is against any "easy"
way how to solve this, and any other solution involves changing that cannot be
easily held by migration from older version. I do not know what to do more with
this than I did in upstream bug, I'm sorry.
(In reply to comment #17)
> I do not know what to do more with this than I did in upstream bug, I'm sorry.
Well, the is one standard way how to deal with the situation like this --
Everybody moves upstream, where the real solution is, our bugzilla is not
plagued by the bug which is not the Red Hat problem, and it could be more useful
for us. I do it for other (especially gecko) bugs all the time and we are
finally getting into Bugzilla being almost useful for us.
There is only one problem with this solution. David absolutely hates this, and
closing bug where he is reporter as UPSTREAM leads to endless flamewar with him.
In my opinion he has the problem distinguishing his mathematical ideal with our
reality where every action has some real costs, but I haven't managed to
persuade him yet.
I learn my children to do what they believe is right. I think I should do
likewise. So, putting on flame-resistant armor, closing down my helmet, and
crawling to corner expecting flamethrower attack, I am closing this bug as
UPSTREAM (the upstream bug is of course
Closing stuff UPSTREAM is fair enough as long as upstream is sane and bugs get
_fixed_. I don't much like the fact that bugzilla calls it 'CLOSED/UPSTREAM'
rather than something like 'PENDING/UPSTREAM' which would be more like the
'NEEDINFO' state. But as long as it gets fixed somehow, it's fine.
Do we have it fixed in Fedora 9 yet, or is Evolution still corrupting mail?