If you send a text/plain message with body as .dsfgfdgfd .gfdsgsfdgfds .sgfdgfdgdsgfdgsd You end up receiving ..dsfgfdgfd ..gfdsgsfdgfds ..sgfdgfdgdsgfdgsd
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...
I can reproduce this on 6.0 & 6.01 RTM. This does not seem to be a regression.
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.
We don't write it anymore because we check for termination before we pass it to IncorporateWrite if ((line == '.') && ((line == CR) || (line == LF))) @@ -2429,6 +2425,25 @@ m_pop3ConData->msg_closure = 0;
How does that make IncorporateWrite not get called? I don't think the pop3 sink knows anything about the msg_closure.
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.
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
OK using apr4 commercial trunk build, win98.
Status: RESOLVED → VERIFIED
*** Bug 67971 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.