Closed
Bug 205009
Opened 21 years ago
Closed 21 years ago
SMTP fails when SMTP server replies with CRLF for a line not sent in same "packet" as line itself.
Categories
(MailNews Core :: Networking: SMTP, defect)
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 198573
People
(Reporter: RobertJochemsen, Assigned: sspitzer)
Details
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 I have written a two-way mail relay utility in VC++6/MFC. It worked ok with all Mozilla/other clients, until recently (according to one of my friends up to 1.2.1). From then on, Mozilla reported an error as soon as connection was made to my server (at the welcome message). After analysis it turned out that the way the replies are sent matters a lot. My original sending code did not work together with Mozilla mail anymore: void CSMTPHandler::WriteLn(CString text) { // i.e. sending a line m_Socket->Send(text.GetBuffer(0), text.GetLength()); // and the CRLF separately m_Socket->Send("\r\n", 2); } However, the following code works, and Mozilla interacts properly with my server. void CSMTPHandler::WriteLn(CString text) { // i.e. sending the text and CRLF together in one "packet" CString extext = text + "\r\n"; m_Socket->Send(extext.GetBuffer(0), extext.GetLength()); } As far as I know the protocols, this should not matter, and for any other client, and older Mozilla mail clients, it does indeed not matter. Even for the current Mozilla mail POP3 (retrieval) part there is no difference between the two. The behaviour just arises with SMTP. In the mean time I have updated my server, but i.m.o., this is still a bug. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Updated•21 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 1•21 years ago
|
||
This seems related to bug 198573, which was checked in on the 8th. To me it looks like it might solve your problem, because the path replaced the entire ReadLine function (not just for the EHLO). Reporter, can you try again with the latest trunk build (the fix isn't present in Mozilla 1.4b).
Assignee | ||
Comment 2•21 years ago
|
||
yes, seems like a potential dup of bug #198573 ch.ey@gmx.net, what do you think?
Comment 3•21 years ago
|
||
I was observing this bug for over a week just waiting for the reporters comment. I think it's a dupe.
Reporter | ||
Comment 4•21 years ago
|
||
As the original submitter, I think that it is indeed a dupe (sorry for that, really did try to find out before submitting). I haven't been able to find time to test against the trunk containing the fix for bug 198573, but my gut feeling is that it was indeed this bug that caused the behaviour I saw. I therefore propose to declare my submission as a duplicate. Thanks for your help, Robert
Comment 5•21 years ago
|
||
*** This bug has been marked as a duplicate of 198573 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Product: MailNews → Core
Updated•15 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•