Closed Bug 270014 Opened 20 years ago Closed 16 years ago

unable to download middle size and big size mail

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: rlamsfuss, Unassigned)

References

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 Mnenhy/0.6.0.104
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 Mnenhy/0.6.0.104

Whenever I try to download an email of about more than 400 kb TB will try to
download the first 200 kb but then ceases to do it. All my mail over that size
remains on the pop3 server. When I return to TB 0.8 there is no problem. Even
after creating a new profile, the problem remains. It applies to all the
accounts I have. 

Reproducible: Always
Steps to Reproduce:
1. shift from TB 0.8 to 0.9. 
2. receive big mail (>400 kb) on my POP3 server
3. Try to load it in Inbox of my TB 0.9 accounts

Actual Results:  
TB will try to download the first 200 kb but then ceases to do it. The
connection monitor does not indicate any activity. No download is taking place
after a few minutes and a download amount of about 200-300 kb.

Expected Results:  
It should have downloades the mail as TB 0.8 did.
are you on a dial-up connection? Have you limited the size of pop3 messages that
will get downloaded automatically, such that you're clicking on the partial
download link to download the message? 
(In reply to comment #1)
> are you on a dial-up connection?
Yes, 56 kbps

> Have you limited the size of pop3 messages that
> will get downloaded automatically, such that you're clicking on the partial
> download link to download the message? 

Not at all, the account setting had not been modified at switching from 0.8 to
0.9. To prevent profile interferences I created a profile from scratch, but the
problem persist, even after switching to 0.9+ nightly. (11-16-2004)
(In reply to comment #2)
> (In reply to comment #1)
> > are you on a dial-up connection?
> Yes, 56 kbps
> 
> > Have you limited the size of pop3 messages that
> > will get downloaded automatically, such that you're clicking on the partial
> > download link to download the message? 
> 
> Not at all, the account setting had not been modified at switching from 0.8 to
> 0.9. To prevent profile interferences I created a profile from scratch, but the
> problem persists, even after switching to 0.9+ nightly. (11-16-2004)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041115
Thunderbird/0.9+ Mnenhy/0.6.0.104

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040614 Firefox/0.9 Mnenhy/0.6.0.104
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040614 Firefox/0.9 Mnenhy/0.6.0.104
> 
> Whenever I try to download an email of about more than 400 kb TB will try to
> download the first 200 kb but then ceases to do it. All my mail over that size
> remains on the pop3 server. When I return to TB 0.8 there is no problem. Even
> after creating a new profile, the problem remains. It applies to all the
> accounts I have. 
> 
> Reproducible: Always
> Steps to Reproduce:
> 1. shift from TB 0.8 to 0.9. 
> 2. receive big mail (>400 kb) on my POP3 server
> 3. Try to load it in Inbox of my TB 0.9 accounts
> 
> Actual Results:  
> TB will try to download the first 200 kb but then ceases to do it. The
> connection monitor does not indicate any activity. No download is taking place
> after a few minutes and a download amount of about 200-300 kb.
> 
> Expected Results:  
> It should have downloades the mail as TB 0.8 did.

Severity: major → critical
(In reply to comment #2)
> (In reply to comment #1)
> > are you on a dial-up connection?
> Yes, 56 kbps
> 
> > Have you limited the size of pop3 messages that
> > will get downloaded automatically, such that you're clicking on the partial
> > download link to download the message? 
> 
> Not at all, the account setting had not been modified at switching from 0.8 to
> 0.9. To prevent profile interferences I created a profile from scratch, but the
> problem persist, even after switching to 0.9+ nightly. (11-16-2004)


The same happens with TB 1.0 see discussion on
http://forums.mozillazine.org/viewtopic.php?p=1043626#1043626
(In reply to comment #1)
> are you on a dial-up connection? Have you limited the size of pop3 messages that
> will get downloaded automatically, such that you're clicking on the partial
> download link to download the message? 

The same happens with TB 1.0, please see discussion on
http://forums.mozillazine.org/viewtopic.php?p=1043626#1043626
I would like to suggest looking into the pop3 response timeout setting. I had
very similar problem (TB silently not downloading mail) and the workaround is
posted at

http://forums.mozillazine.org/viewtopic.php?p=1043598#1043598

basically increase response timeout from the default of 45 sec. This seems to be
working for others too.
Sounds similar situation to Bug 273369.
 (1) New Thunderbird has timeout mechanism on receiving
 (2) Anti-virus software intersepts receiving data for virus checking
 (3) Then timeout occurs on new Thunderbird
Even if condition of (2) does not exist, timeout may occur on some
environment(eg. slow dial up line).

Get protocol log first and check what happens(timouout?).
See http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop for
protocol log.
Please do not forget to change 
 > set NSPR_LOG_MODULES=POP3:5 for POP3
 > set NSPR_LOG_MODULES=IMAP:5 for IMAP
Please also note that log file is overlayed on restart.

Second, see what happens when timeout value is changed.
See Bug 273369 Comment #22 for changing timeout value.
Following Comment #7, the attached logs were created, using different values
for the timeout(user_pref("mail.pop3_response_timeout", 600);) and keeping all
other parameters the same. When the timeout is set to the default value,
because of the _server's_ delay to reply, a timeout occurs at the client side
and the _client_ never completes the command. By the way, I know that this
particular mail server takes a long time to reply to AUTH when there is a large
mailbox, as in this case.

I believe that, at least, there should be a notification to the user when such
an event occurs, and possibly a way through the user interface to adjust this
timeout value. As the situation stands and under these circumstances, TB does
not retrieve email that should be retrieved and the user is not aware of this.
(In reply to comment #8)
> I know that this particular mail server takes a long time to reply to AUTH
> when there is a large mailbox, as in this case.

Your protocol log says ;
>***	log 1, timeout default
> 0[274540]: SEND: USER userxxx
> 0[274540]: RECV: +OK userxxx, your papers please.
> 0[274540]: Logging suppressed for this command
>           (it probably contained authentication information)
> 0[274540]: OnResponseTimeout: username=userxxx
>***	log 2, with timeout set to 600
> 0[274540]: SEND: USER userxxx
> 0[274540]: RECV: +OK userxxx, your papers please.
> 0[274540]: Logging suppressed for this command
>            (it probably contained authentication information)
> 0[274540]: RECV: +OK userxxx has 178 messages (65587559 octets).
> 0[274540]: SEND: STAT
> (Communication continues...)

Cause of timeout is delay in sending back of "+OK userxxx has 178 messages
(65587559 octets)" after successful authentication, as you say.  

> I believe that, at least, there should be a notification to the user when such
> an event occurs, and possibly a way through the user interface to adjust this
> timeout value.
I agree with you.
Enhancement of timeout notification is required.

Attachment #168446 - Attachment description: pop3 logfile → pop3 logfile showing the failure to download 714 k mail.
(In reply to comment #7)
> Sounds similar situation to Bug 273369.
Indeed, but I was first (2004-11-15 vs 2004-12-06) ;-)

> Get protocol log first and check what happens(timouout?).
Yes, it's a timeout
> See http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop for
> protocol log.
Thank you
>
> Second, see what happens when timeout value is changed.
Still have to do a few experiments with that
> See Bug 273369 Comment #22 for changing timeout value.
Ok, I just created a logfile for my problem

> I believe that, at least, there should be a notification to the user when such
> an event occurs, and possibly a way through the user interface to adjust this
> timeout value. 
So do I, keep in mind please, that we are end users (as to me, at least) and
laymen, not everbody likes to tinker with user.prefs and the average user could
get scared off TB by things like this.

As the situation stands and under these circumstances, TB does
> not retrieve email that should be retrieved and the user is not aware of this.
Of course, he only gets bothered and tainted to go back to OE
> 

Set Bug 127461 to "Depends on:" of this bug, because mail.pop3_response_timeout
was introduced by Bug 127461.
Depends on: 127461
I've opened Bug 277071.
Bug 277071 : Timeout by mail.pop3_response_timeout should be notified to user
Comfirming according to protocol log.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: front-end
Assignee: mscott → nobody
bug 277071 has been fixed, and I have successfully received large messages without problems -> RESO WFM.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: