Extra dot appearing at the beginning of lines in the body

VERIFIED FIXED

Status

MailNews Core
Networking: POP
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: Navin Gupta, Assigned: Navin Gupta)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Assignee)

Description

17 years ago
If you send a text/plain message with body as

.dsfgfdgfd
.gfdsgsfdgfds
.sgfdgfdgdsgfdgsd

You end up receiving 

..dsfgfdgfd
..gfdsgsfdgfds
..sgfdgfdgdsgfdgsd
(Assignee)

Comment 1

17 years ago
Created attachment 29520 [details] [diff] [review]
proposed fix. Explanation in the patch
(Assignee)

Comment 2

17 years ago
Need r/sr

Comment 3

17 years ago
was this broken in 6.0? I thought it worked at some point. Your change looks OK,
but I'm worried that this regressed for some other reason...
(Assignee)

Comment 4

17 years ago
I can reproduce this on 6.0 & 6.01 RTM. This does not seem to be a regression.

Comment 5

17 years ago
ok sr=bienvenu
(Assignee)

Comment 6

17 years ago
Created attachment 29559 [details] [diff] [review]
revised patch

Comment 7

17 years ago
does the second patch avoid writing the terminal "."CRLF to the folder via
incorporate write? It looks to me like we do still write that terminal .CRLF.
And now that we don't handline it in IncorporateWrite, we need to not write it.
(Assignee)

Comment 8

17 years ago
We don't write it anymore because we check for termination before we pass it 
to IncorporateWrite

     if ((line[0] == '.') &&
         ((line[1] == CR) || (line[1] == LF)))
@@ -2429,6 +2425,25 @@
             m_pop3ConData->msg_closure = 0;

Comment 9

17 years ago
How does that make IncorporateWrite not get called? I don't think the pop3 sink
knows anything about the msg_closure.
(Assignee)

Comment 10

17 years ago
Created attachment 29566 [details] [diff] [review]
revised patch. Nice catch !!!

Comment 11

17 years ago
sr=bienvenu - before checking in, you should run a few tests and look at the
berkeley mailbox with a text editor to make sure the messages look OK - check
that .. lines from the server look like . in the folder, and that we don't have
a trailing "." line, and that we get all of the message when we have '.''s
escaped, e.g., try a message like
foo
.
.
.
.
bar

and make sure it is received correctly in the local berkeley mailbox.
(Assignee)

Comment 12

17 years ago
ested the above case and checked the berkeley mailbox (inbox) and there was
no extra . at the end. 

fix checked in
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 13

17 years ago
OK using apr4 commercial trunk build, win98.
Status: RESOLVED → VERIFIED
Product: MailNews → Core

Comment 14

12 years ago
*** Bug 67971 has been marked as a duplicate of this bug. ***
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.