259564 - Thunderbird does not escape lines containing a single dot - pop message was truncated at period

Status: RESOLVED DUPLICATE of bug 166111

(Thunderbird :: General, defect)

Description

[Reed Hedges]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8
Build Identifier: Mozilla Thunderbird 0.5 (20040306)

If a message contains a new line with a single dot ("."), then the message is
truncated at that point when sending. In other words, Thunderbird does not
"escape" the dot, and it ends up serving as the end of message signal rather
than a part of the message. 


Reproducible: Always
Steps to Reproduce:
1. Compose a new message with any subject and recipient, with the following in
the body field:

foo
.
bar


2. Send the message
3. The message recieved will be:

foo



Actual Results:  

The message was truncated at the dot:

foo



Expected Results:  
A space character could be inserted into the message before the dot.  There is
no good way AFAIK to deal with this problem with SMTP and preserve the message
body exactly as written.  But this would have been fairly close to the original
message:

foo
 . 
bar

Comment 1

[Mike Cowperthwaite]

I can't reproduce this problem with TB 0.8, Win2K.  It may be a Linux problem, 
or it may be an issue with your SMTP server.  Is the message in the Sent folder 
also truncated?

As for a way to get by this, if TB used quoted-printable and escaped the dot as
=2E, that would do the trick.  That technique would also provide a solution for 
bug 121946 and bug 194382.

Comment 2

[Reed Hedges]

The message is how I wrote it, in the sent mail folder:

foo
.
bar


Maybe it was fixed in 0.8, or maybe it doesn't apply to Windows for some reason.
I am using a remote SMTP server (not localhost).

The QP idea might work but it would be nice not to use QP unless neccesary (ie,
only use it for messages that need it)

Comment 3

[Mike Cowperthwaite]

(In reply to comment #2)
> Maybe it was fixed in 0.8

I didn't notice before, but: you really shouldn't be filing bugs against old 
versions.  Please check whether 0.8 fixes this problem on your system.

Comment 4

[Reed Hedges]

I know. 0.5 is what is in Debian/Testing.  The best field in Bugzilla for the
version number I could find was "Build Information", where I put what the About
box says. 

I searched Bugzilla for bugs (both open and closed) and keywords "dot", "period"
and "line" but did not find anything.

If I have a chance in the near future to use 0.8 I'll check that version.

Comment 5

[Mike Cowperthwaite]

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

Comment 6

[Mike Cowperthwaite]

Updating platform, and confirming, based on dupe -- but I still can't reproduce 
this.

From bug 263597 comment 2:
I assume this is a pop3 issue - because pop3 indicates the end of a message by a
".", i.e. ".<CRLF> , the pop3 server has to escape a real line with just a
".CRLF>" by adding a extra "." - the pop3 message download code is supposed to
strip out the extra ".". and I thought it did...

In the case of an attachment (as in bug 263597) there are other instances of 
escaped text not being unescaped; see bug 194382.

Comment 7

[Reed Hedges]

I see the same problem with 0.9.
And I'm not so sure it's POP3, since sending it to a remote server and viewing
it directly (in my local mail spool, not via POP3), I see the same truncation.

Comment 8

[Jimbo]

Using TB 1.5.0.2 on WinXP I sent the following message:

Foo
.
Bar

The outgoing SMTP server was Postfix 2.2.5 (also the incoming server).

The message showed up in my maildir folder like this:

Foo
.
Bar

The last version that was tested looks to be .9, so either this was fixed since then, or this doesn't affect Windows.

Comment 9

[Christopher Sahnwaldt]

Works fine for me with version 1.5.0.4 (20060516) on Windows XP. Sent mail to SMTP hosts of two mail providers. Works like a charm, either with a single dot in a line in the mailbody or in an attachment. 

Comment 10

[Wayne Mery (:wsmwk)]

yes, i believe this was bug 166111 which checked in on trunk 2005-02-05 and was fixed afaict with along with 282010 on 1.0.6 and 1.5.0.4ish