SMTP fails when SMTP server replies with CRLF for a line not sent in same "packet" as line itself.

VERIFIED DUPLICATE of bug 198573

Status

MailNews Core
Networking: SMTP
VERIFIED DUPLICATE of bug 198573
15 years ago
9 years ago

People

(Reporter: Robert Jochemsen, Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
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

Comment 1

15 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).
yes, seems like a potential dup of bug #198573

ch.ey@gmx.net, what do you think?

Comment 3

15 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

15 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

15 years ago

*** This bug has been marked as a duplicate of 198573 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 6

15 years ago
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.