today's build (062208) unser Mac OS9. set up an IMAP account, smoketested fine. set up POP acct, read mail. Sent test mail to bad email address and it was returned. went to read return transcript got Alert unknown error. tried to read other messages got alert unknown error. restarted and tried again. same result. note, after dismissing alert dialog, that part of the message pane is not repainted. IMAP account still works fine. can read and send messages.

adding smoketest keyword. does anyone else see this?

updating OS to ALL as blake sees this too in today's win32 (Win ME) moz bits

jeff, can you investigate this smoketest blocker?

So in order to get this state, you had to read a bounced error message from the server? I don't believe this should be listed as a blocker. If reading any message got you in that state then maybe. But I don't believe this is.

I don't have this problem using Mac OS 9.0 with today's commercial build.

Blake was able to get to this state on win32 without reading abounced message. I will reinstall and try again but I don't think the bounced message was the culprit, just included that as details of my process in arriving at the problem.

Investigating...

This is working fine with me with new pop account on Win NT. I don't think this is a blocker. Clear out smoketest

Linux is fine too.

QA assignee got wiped out somehow. Set to me.

This is fine on Mac too.

Asa, could you try builds after this morning's respin? I don't seem able to reproduce the problem.

OK unabel to reproduce after re-installing. Will check with Blake before Resolving.

wfm on a later build.

mark verified wfm

OK, I see this again and can easily reproduce it on Mac 071908 mozilla bits. Steps to reproduce: 1. install mac mozilla 2. launch mozilla messenger 3. set up POP account 4. set POP account to leave messages on server (not sure if it's necessary but I'm not trying it without this) 5. select inbox of pop account 6. click on the Get Msg button 7. hit stop after only a few messages have downloaded. 8. read a message or tow 9. click on Get Msg button again 10.hit stop after a few more messages have downloaded. 11.read messages from the second set. actual results: I get an Alert "unknown error" when attempting to read any messages that were not downloaded in the first attempt. expected behavior: I should be able to read all POP messages. additional information. debug output on the way. the Protocol Log described on http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html does not seem to work for POP (another bug?).

This is specific to POP and should probably be moved to Networking POP. Updating component.

I can reproduce this with 2000-07-19-12 commercial build on mac OS 9.0. Thanks for the clear steps, Asa! Also, to clarify the results: You can not read these messages even after exit, relaunch and another Get Msg with successful login! They continue to get the "unknown error" and are inaccessible. nominating nsbeta3 (at least)

I don't see the problem with NT 4.0 or linux rh6.0, so I'm adding pp keyword.

updating Platform from ALL to Macintosh. I also am unable to repro on win32 NT or 98

hmm, being unable to read these POP messages again is serious. I'm nominating for nsbeta2. POP protocol is fairly popular. I'm not quite sure how many people may stop a POP download, but the problem is that the 2nd set of messages gotten after pressing Get Msgs again can never be read.

I'd probably argue against fixing this for beta2. I don't think I'd pull it off the wire if it's mac only and you have to interrupt the original pop download to see it. My two cents anyway....but your right PDT should have a chance to make this call.

Putting on [nsbeta2-] radar. Not critical to beta2.

laurel, add to relnote2 on this.

+ per mail triage

If this is mac only, I won't be able to help much.

If this is mac only, I bet the problem is that we're not closing the inbox file, so that when we try to open it for write the second time, it fails. I can look at that part of it, but I won't be able to verify anything because I don't have a mac at home.

I have no mac at home either but perhaps we can get a build going at work on tuesday, (since my mac is actually talking to the network :))

As I thought, we're not closing the inbox file, because the stop notification is never getting through to the pop3 protocol. I have a fix in hand.

sweet!

I can't test this on the mac, but if my theory is right, it should be fixed.

This works now. Thanks bienvenu. Verified with 081404 Mac mozilla build on OS9. I tested this quite a few times and all seems well. Verified!

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