Bug 230765 - "!\n " randomly inserted into sent text
"!\n " randomly inserted into sent text
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
6
All Linux
low Severity urgent
: ---
: ---
Assigned To: Milan Crha
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-02 13:37 EST by Tim Waugh
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-08 08:12:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 484634 None None None Never

  None (edit)
Description Tim Waugh 2007-03-02 13:37:49 EST
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):
evolution-2.8.3-1.fc6
sendmail-8.13.8-2

How reproducible:
Frequently.
Comment 1 Milan Crha 2007-05-23 09:52:40 EDT
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 11:20:45 EDT
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 11:26:49 EDT
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 07:14:42 EDT
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 11:46:35 EDT
Milan, did we ever find a resolution for this or at least open a bug upstream?
Comment 6 Milan Crha 2007-10-08 04:42:45 EDT
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 04:55:43 EDT
I created bug upstream now, see
http://bugzilla.gnome.org/show_bug.cgi?id=484634
Comment 8 Matthew Barnes 2007-10-08 08:12:19 EDT
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.