158059 - Mozilla Pretends to Send Mail When Server Connection Fails

Status: RESOLVED FIXED

(MailNews Core :: Networking: SMTP, defect)

Description

[Jerry Baker]

2002071608 Trunk

When a mail server terminates a connection immediately upon connection without a
response, Mozilla happily pretends like it sent mail anyway. This situation
happens when a Microsoft mail server is configured to disallow access from
certain IP addresses. This is critical because no mail was sent at all even
though Mozilla acts like it successfully sent mail (putting a copy in the Sent
folder and everything). This cost me about 5 days worth of outgoing mail and I
didn't even know it.

NN4 under the same situation pops a dialog that says:

An error occured while sending mail: SMTP server error
The server responded:
(null)
Contact your mail administrator for assistance.

Comment 1

[Jerry Baker]

I'm not sure if this exactly qualifies for the dataloss keyword. I would argue
that it does, but if someone else wants to remove it I won't argue.

Pretending to send mail when none is sent, and giving the user the false
impression that the send operation was successful, seems to be a form of
dataloss to me. The user thinks that these emails are going out, and there is no
indication anywhere that they did not until some recipient asks why they haven't
received any mail a few days or weeks later.

Comment 2

[Ben Bucksch (:BenB)]

> I'm not sure if this exactly qualifies for the dataloss keyword.

It does.

Comment 3

[Jerry Baker]

From what I can gather, this is roughly what happens:

1) Mozilla sends a TCP connection request to the SMTP server.
2) The connection is answered (I don't know if there is an ACK).
3) The connection is closed by the server (connection left in TIME_WAIT state).
4) Mozilla doesn't know that the connection is no longer active and simply dumps
   the SMTP exchange into a non-existent connection. (Oddly Mozilla proceeds as
   if everything is fine even though it isn't getting responses to HELO/EHLO,
   AUTH LOGIN, RCPT TO, MAIL FROM, etc.)

It seems to me that the problem might be somewhere in that Mozilla seems to
assume that once a connection request is answered, that everything is OK. I
guess a little more state checking is in order before having a one-sided SMTP
conversation.

Comment 4

[Jerry Baker]

An interesting side-effect of not checking the SMTP responses is that you can
put in any network server that will answer a connection request for your SMTP
server and Mozilla just sits there with a progress dialog... "Sending mail". It
never throws an error.

Comment 5

[Jerry Baker]

For someone on a Windows 2000 Pro or XP Pro machine, you can set up the MS SMTP
server to verify this bug. First, make sure the SMTP server is installed under
Add or Remove Programs -> Add/Remove Windows Components -> Internet Information
Services (IIS) -> SMTP Service. To configure it to see this bug:

1) Open the Internet Information Services administration applet (in
   Administrative Tools).
2) Right-click on the SMTP server and select "Properties".
3) Select the "Access" tab.
4) Click the "Connection..." button and select "Only the list below" (make sure
   your IP is NOT in the list.
5) Now use Mozilla to send mail through that server.

The SMTP server will deny the connection, but Mozilla pretends to send the mail
anyway. I do not know if Sendmail or other mail tools deny connections in the
same manner as the MS SMTP server (by immediately terminating a connection after
the handshake).

Comment 6

[laurel]

*** Bug 137570 has been marked as a duplicate of this bug. ***

Comment 7

[Ant]

I am noticing this problem in v1.1 in Windows XP Professional and 2000 SP3. My
office computer's firewall started blocking SMTP port 25 (I can't even telnet
<mail server address> 25) recently. Mozilla never gave me an error and closes my
e-mail send dialog box.

Comment 8

[(not reading, please use [e-mail] instead)]

I don't have win2k pro.  is there another way to reproduce this?

does anyone have a smtp server I could trying this against?

Comment 9

[(not reading, please use [e-mail] instead)]

"An interesting side-effect of not checking the SMTP responses is that you can
put in any network server that will answer a connection request for your SMTP
server and Mozilla just sits there with a progress dialog... "Sending mail". It
never throws an error."

sounds similar to http://bugzilla.mozilla.org/show_bug.cgi?id=98399#c28

Comment 10

[Jerry Baker]

I can set mine up for you to test. It should work now. Server address supplied
via email.

Comment 11

[(not reading, please use [e-mail] instead)]

I've reproduced this, with jerry's help.

what I'm seeing is that we call OnStartRequest(), then OnStopRequest(), no 
error.

my guess is that 

I'm trying to debug nsSocketTransport to see why this is.

note, when I telnet to the server on the smtp port, I immediately get kicked 
off, with:

"Connection to host lost."

if I do http://jerry's server:jerry's port, I get the error "document contains 
no data".

so I wonder if the fix in this case will be similar, if we've read nothing 
that's an error.

I'll seek darin's advice.

Comment 12

[(not reading, please use [e-mail] instead)]

accepting.

I talked to darin, and he told me that this is a protocol specific error, which 
is why http does what it does with "no data".

I need to fix smtp so that if we open and close and no data is read, that's an 
error.  

Comment 13

[(not reading, please use [e-mail] instead)]

Attachment: patch

patch.	we now get a proper error dialog, and there is no silent dataloss.

Comment 14

[Cavin Song]

Comment on attachment 111218 [details] [diff] [review]
patch

r=cavin. Maybe we should change variable 'status' to 'bytesRead'.

Comment 15

[(not reading, please use [e-mail] instead)]

Attachment: patch, rename status, per cavin's review (over aim)

Comment 16

[Cavin Song]

Comment on attachment 111220 [details] [diff] [review]
patch, rename status, per cavin's review (over aim)

r=cavin.

Comment 17

[(not reading, please use [e-mail] instead)]

fixed.  this has sr=bienvenu (over aim).

thanks again to jerry and darin.

Comment 18

[(not reading, please use [e-mail] instead)]

I wonder if imap, nntp, and pop3 have this problem?

it's possible.  I'll log a spin off bug to investigate.

this fix might move from smtp into the msg base protocol (and into the imap 
protocol), if the same problem affects those pieces of code.

but for now, it's good to have this smtp dataloss bug fixed.

Comment 19

[(not reading, please use [e-mail] instead)]

spin off bug is bug #188569 

Comment 20

[(not reading, please use [e-mail] instead)]

*** Bug 180969 has been marked as a duplicate of this bug. ***

Comment 21

[Benedikt Kantus]

*** Bug 190431 has been marked as a duplicate of this bug. ***

Comment 22

[Patrick Fromberg]

Puh, I see, this very terrible bug is old! I just had posted a similar bug
report. The situation could be a bit different so it may be good to read it.

Please consider, that this bug will definitely have very serious mass
consequences in about one or two month.

PEOPLE WILL BE AUTOMATICALLY UNREGISTERED FROM smtprelay.t-online.de (because of
a change in usage conditions) and they will very problably run into this issue!
that server has many users and many of them have Mozilla and many versions of
Mozilla are affected.

Reading this thread I find, that the seriousness of this issue has not been
recognized! Some argued, that it is not a bug producing data loss. NONSENSE, its
not only about loss of data. Its even about unnoticed loss of data, which is
much more severe! I will also affect some, who know about the bug, and they can
not do anything about it. This is the most serious bug, that I can remember!

Regarding the developers question, you can try smtprelay.t-online.de as you are
probably not registered with it. 

Comment 23

[Ben Bucksch (:BenB)]

Patrick, if you read this very page, you'd see that it has been *fixed*
recently. The dup bug shows that you use either 1.3a or 1.2.x, both of which are
too old. How about trying out a nightly, to see, if it works for you?

Comment 24

[Patrick Fromberg]

> Patrick, if you read this very page, you'd see that it has been *fixed*
Hmm, that was the first thing I looked at. Now you now, why my smielies look
like this 8-) and not like this :-). To be accurate, they would have to look
like this o-), but nowbody understands that.

Maybe it is a good idea to mentione and emphasise this bug in the "new releases
note" so that people get aware and update their Browsers.