Mozilla mail reports connection problems with MTA when MTA FIN's TCP connection

RESOLVED FIXED

Status

--
major
RESOLVED FIXED
15 years ago
9 years ago

People

(Reporter: gleisner, Assigned: ch.ey)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
User-Agent:       
Build Identifier: Mozilla 1.5 & Mozilla 1.6

The pop3 mail server recieves a message from Mozilla and sends a 250 message 
saying the email is deliverable.  Then the pop3 server immediately does a TCP 
FIN.

Mozilla sometimes displays "message sent" on the progress dialog and sometimes 
not.  But Mozilla always pops up an error dialog and says "connection failure".

[the Mozilla problem] Mozilla doesn't complete the email handling by marking 
the email as sent and placing a copy in the sent folder, even though Mozilla 
would have sent a QUIT if the connect remained open.

[optional] I realize that this isn't Mozilla's problem, but if there could be a 
setting to turn off the error message when Mozilla is set to send a QUIT and 
the server beats it to the punch with a TCP FIN, that would be nice.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




My ISP (SBC) will not assist in this problem because Outlook Express doesn't 
have an issue with the server's behavior.

Comment 1

15 years ago
Not a Bugzilla bug...
Assignee: myk → sspitzer
Component: User Interface → Networking: SMTP
Product: Bugzilla → MailNews
QA Contact: mattyt-bugzilla → nbaca
Version: unspecified → Trunk

Comment 2

15 years ago
similar to bug 212208 (in a totally different context)
(Assignee)

Comment 3

15 years ago
I wasn't that sure if a "250" response is sufficient or if an answer to "QUIT"
is necessary.
But RFC 2821, 6.1 says "When the receiver-SMTP accepts a piece of mail (by
sending a "250 OK" message in response to DATA), it is accepting responsibility
for delivering or relaying the message." So I think it's ok if we're tolerant here.
Assignee: sspitzer → ch.ey
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: PC → All
(Assignee)

Comment 4

15 years ago
Created attachment 140422 [details] [diff] [review]
proposed patch

This introduces m_sendDone as an indicator for correct sent message.
Disconnects with m_sendDone == PR_TRUE are considered to be not bad.

Comment 5

15 years ago
Comment on attachment 140422 [details] [diff] [review]
proposed patch

seems reasonable.
Attachment #140422 - Flags: review+

Updated

15 years ago
Attachment #140422 - Flags: superreview?(mscott)

Updated

15 years ago
Attachment #140422 - Flags: superreview?(mscott) → superreview+

Comment 6

15 years ago
I'll check this in.

Comment 7

15 years ago
patch fixed in, thx, Christian.

Comment 8

15 years ago
(In reply to comment #7)
> patch fixed in, thx, Christian.

I've downloaded and installed the 5-Feb-2004 build containing this patch. It
seems to be working fine; I'm no longer getting connection failure messages from
smtp.sbcglobal.net.

Comment 9

15 years ago
I'm going to port this to the tbird 0.5 branch since there is such a long thread
in mozillazine with testers running into this. Nice timing on the fix Christian :)

Fixed on the M4 branch.

P.S. Can we close this bug as fixed?
Blocks: 230700

Comment 10

15 years ago
fixed
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Assignee)

Comment 11

15 years ago
*** Bug 233363 has been marked as a duplicate of this bug. ***

Comment 12

15 years ago
Problem has reappeared when I try to send to 30 recipients through
mail.sbcglobal.net, but can be avoided by cutting down the number of recipients
to 25. Last I tested it, there is not supposed to be a limit on the number of
recipients in a single mesage of less than 50. Evidently, there is still some
kind of timeout going on, because there is a long delay in getting back an
indication that the send was successful, longer than similar messages with
similar numbers of recipients have taken in the past.

This is to request the bug be reopened.
(Assignee)

Comment 13

15 years ago
I don't believe that's the same problem.

> Evidently, there is still some kind of timeout going on,

SBC modified their system in the past weeks as they said. Maybe processing mails
to many recipients now take very long or something else.
I suggest to open a new bug, attach a log and I'll see.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.