Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 230765 - "!\n " randomly inserted into sent text
Summary: "!\n " randomly inserted into sent text
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Milan Crha
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-02 18:37 UTC by Tim Waugh
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-10-08 12:12:19 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
GNOME Bugzilla 484634 None None None Never

Description Tim Waugh 2007-03-02 18:37:49 UTC
Description of problem:
I have seen several emails sent from evolution (evolution-2.8.3-1.fc6 on x86_64)
where the message is in HTML, but the HTML portion of the received message
contains "!\n " (exclamation mark, newline, and space) inserted in random places.

It doesn't appear in the text/plain portion of the received message, and the
message that got copied to the Sent folder on the sending machine does not
include the extra exclamations either!

The messages are being given to sendmail (sendmail-8.13.8-2) on the same
machine, and the SMTP host is running postfix (postfix-2.2.10-1.RHEL4.2).  I've
had reports of the same thing with another (non-postfix-hosted) recipient as well.

So why are these extra things getting inserted into the message?

Version-Release number of selected component (if applicable):

How reproducible:

Comment 1 Milan Crha 2007-05-23 13:52:40 UTC
I think this is a sendmail "feature". I did test it today, I can reproduce it on
sendmail-8.14.1-2 on x86_64 Rawhide, but the information from evolution is
"clear" of those characters. Futhermore, I found in sendmail sources sequences
where they put exactly these characters on output, it's in
sendmail/util.c:putxline function, and something similar, but without that last
space, is at sendmail/deliver.c:putbody function. I don't know what does that
code do and why, I don't know sendmail either, it only looks for me that
evolution didn't do this.

Comment 2 Tim Waugh 2007-05-23 15:20:45 UTC
Seems to be when the line length has been reached.

Is evolution sending the mail as one long line?

Comment 3 Milan Crha 2007-05-23 15:26:49 UTC
No, it isn't. I think, it's based on composer, how long lines are. (I paste one
page from firefox and there was only few lines too long for sendmail (even in
text editor there are couple of long lines, but not so much).)

Comment 4 Milan Crha 2007-06-13 11:14:42 UTC
I was looking into this more deeply and it looks like that GtkHtml exports text
from component in HTML with "\n" with almost all tags inside it, but only not
with Anchors, so with a long URLS it could exceed line limit (about 996 or 998
characters) or when there are more anchors on one line. I wasn't sure if it's
safe to make enters right after end of Anchor tag (like "<A ...>\n"), I only
know that there was some kind of problem with "\n" inside tables with IE, but
could not remember it exactly. My second thought was to place it one character
before this end (like "<A ...\n>"), but I remembered a ">From " problem and keep
it as is.

We need to either get an advice from upstream or somebody who knows HTML better
than me, or something completely else.

Comment 5 Matthew Barnes 2007-10-05 15:46:35 UTC
Milan, did we ever find a resolution for this or at least open a bug upstream?

Comment 6 Milan Crha 2007-10-08 08:42:45 UTC
There is nothing better than I mentioned in comment #4 above. Also, you've
right, I didn't move this upstream yet.

Comment 7 Milan Crha 2007-10-08 08:55:43 UTC
I created bug upstream now, see

Comment 8 Matthew Barnes 2007-10-08 12:12:19 UTC
Moving this upstream so we only have to track the problem in one place.
See the above link for further updates.

Note You need to log in before you can comment on or make changes to this bug.