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)

x86
Windows 2000
defect
Not set
normal

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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).
yes, seems like a potential dup of bug #198573

ch.ey@gmx.net, what do you think?
I was observing this bug for over a week just waiting for the reporters comment.
I think it's a dupe.
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

*** This bug has been marked as a duplicate of 198573 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Verified duplicate.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.