Closed Bug 397659 Opened 18 years ago Closed 17 years ago

Two sends work, then 15-minute wait required to send third message

Categories

(Thunderbird :: General, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: stusarah, Unassigned)

Details

Attachments

(3 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 Build Identifier: 2.0.0.6 (20070728) After successfully connecting, downloading incoming mail, and sending two messages, a third send will fail on an apparent SMTP timeout. A 15-minute wait must transpire before the send will succeed. Following this, only one email can be sent every 15 minutes. Platform is a WinXP SP2 desktop (Intel P3, 933 MHz) with all Microsoft updates, 56K dialup connection. Reproducible: Always Steps to Reproduce: 1. Connect to ISP. Receive incoming mail, if any. (receives work OK) 2. Compose and send one email. Briefly see "Connecting to mail.telerama.com" (maybe a half second) then "Connected to mail.telerama.com" (maybe 5-10 seconds) then "Delivering mail" (time varies with size of outgoing message), then "Mail sent successfully" (very brief). 3. Within a minute or so, compose and send second email. Usually the same messages appear. 4. Compose and try to send a third message. This time, it will show "Connecting" for 20 seconds (or will skip that and go to "Connected to" for 20 seconds"). Actual Results: 5. Send will fail with the following message: "Send Message Error Sending of message failed. The message could not be sent because connecting to SMTP server mail.telerama.com failed. The server may be unavailable or is refusing SMTP connections. Please verify that your SMTP server setting is correct and try again, or else contact your network administrator." 6. Retry as often as desired for < 15 minutes; it will fail the same way. 7. Just after 15 minutes after the prior email was sent, the send of this mail will succeed. 8. From here on out, only one email every 15 minutes may be sent. Expected Results: Every manually composed and sent email should go out without delay. 1. Connection is over 56k dialup. 2. Problem has existed for some time, at least Tb 1.5, possibly earlier. 3. All Add-ons have been disabled; problem occurs whether they are there or not. 4. Norton AntiVirus 2004 installed but disabled; problem occurs whether it was there or not. 5. Norton AV was uninstalled and reinstalled. Again, no difference. 6. Have reported this to ISP. They do not believe the problem is at their end. 7. ISP had a major configuration change in March-April 2007, but the problem definitely predates this, without significant difference. 8. The bug shows similarities to Bug 373101, Bug 320389, Bug 348040, and especially Bug 366938, but does not appear to be identical. 9. Bug is irrespective of content; it could be one line of text, or lots of text, or have attachments. No difference. 10. I have not meddled with the Windows Firewall, as I am not comfortable in doing so without detailed instructions (which I lack). I have a couple of trace logs which I will attach.
Timestamp on log was 9/26/2007 @ 11:11 AM.
Timestamp on file was 9/26/2007 @ 11:16 AM. File is only a couple of lines long.
The successful send was around 11:10; the unsuccessful send was around 11:15. Most of the other activity around this time was researching Bugzilla.
Sounds due to "POP before SMTP". (Q1) Will "Get Msgs then mail send" be workaround? (Q2) Do you setup SMTP server setting to use useris/password? Or your SMTP server doesn't support SMTP AUTH(use of userid/password)? Note: Following page refers to POP3 userid/password only. http://www.telerama.com/support/documentation/config_settings.php3 So it looks no SMTP AUTH support, forcing "POP before SMTP" instead.
Attachment #282416 - Attachment mime type: application/octet-stream → text/plain
Attachment #282415 - Attachment mime type: application/octet-stream → text/plain
Attachment #282417 - Attachment mime type: application/octet-stream → text/plain
It appears that the server has switched its authentication scheme by now. Probing the server mail.telerama.com shows an "AUTH LOGIN CRAM-MD5 PLAIN" response, indicating that user/password authentication should work now. Is this still an issue or was that fixed by the server changes then?
No response from reporter after 4 weeks since my reminder, thus assuming that this was a server/configuration issue and has been resolved by now. Please feel free to reopen if you have further information to add. -> INVALID (by all information provided, apparently not a bug in Thunderbird)
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: