Closed Bug 228649 Opened 17 years ago Closed 13 years ago
Unable to download mail from pop3 server caused by junk email
7.43 KB, text/plain
8.99 KB, text/plain
222.00 KB, text/plain
5.60 KB, text/plain
930 bytes, text/plain
7.50 KB, text/plain
910 bytes, text/plain
2.39 KB, text/plain
628 bytes, text/plain
42.98 KB, text/plain
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.20 [en] Build Identifier: Mozilla Thunderbird 0.4 (20031205) Thunderbird is unable to download email from a pop3 server. A message box alerts the user that Using web access to the mail server I discovered that this is always caused by an email from:   subject: [no subject]. The body of the email is also empty. Using web access I can delete the email. This does not remedy the situation until Thunderbird is restarted. Reproducible: Always Steps to Reproduce: 1. Recieve mail from:   subject: [no subject] (don't know how to reproduct this 2. Thunderbird stops downloading mail on that account 3. Delete email from mail server 4. Restart Thunderbird 5. Emails on server begin to download again
Sorry - meant to say: When you hit the get mail button, a message box alerts the user that the 'Folder is currently being processed'. Leaving Thunderbird for some time had no effect and I had to restort to using Web access to the mail server to delete the email.
POP3 protocol log is probably required for problem analysis. See http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop Please do not forget to change NSPR_LOG_MODULES=IMAP:5 to NSPR_LOG_MODULES=IMAP:5.
this is the mail log for a message that can't be downloaded as described. If i delete this via webmail and restart tbird, it will download remaining messages. I can try to export the specific email if necessary This happens to me 2-3 times per week
how about trying 0.5 instead of 0.4?
According to help/about I'm running 0.5b -jeff (In reply to comment #4) > how about trying 0.5 instead of 0.4?
*** Bug 230622 has been marked as a duplicate of this bug. ***
Here is an example message that causes the problem (x's added for privacy): Return-Path: <Cruz@we3cdmeds.com> Delivered-To: firstname.lastname@example.org Received: (qmail 91050 invoked by uid 110); 24 Mar 2004 08:13:15 -0000 Delivered-To: email@example.com Received: (qmail 91046 invoked from network); 24 Mar 2004 08:13:14 -0000 Received: from sw59-120-157.adsl.seed.net.tw (18.104.22.168) by xxxxxx.xxxx.com with SMTP; 24 Mar 2004 08:13:14 -0000 X-Message-Info: 8a[3 The POP3 log is similar to the previously attached log, with the 419 octets of message 31 being the email above (exactly the same happens with both the 0.5 milestone and the 2004-03-28 nightly): //Previous log stuff snipped... //So far done AUTH, CAPA, LIST and UIDL... //Previous message (no messages downloaded yet) 0: SEND: DELE 30 <-----DELE? RETR 30 not done yet! 0: Entering NET_ProcessPop3 14 0: POP3: Entering state: 3 0: RECV: +OK Deleted. 0: POP3: Entering state: 21 0: POP3: Entering state: 15 0: POP3: Entering state: 18 //Offending message 0: SEND: RETR 31 //<------Why RETR now? 0: Entering NET_ProcessPop3 24 0: POP3: Entering state: 3 0: RECV: +OK 419 octets follow. 0: POP3: Entering state: 19 0: Opening message stream: MSG_IncorporateBegin 0: Done opening message stream! 0: RECV: (null) //End of download attempt (all 370 emails left in inbox)
Actually, ignore my DELE and RETR comments. I just realised that the first 30 emails were downloaded, but never get deleted because the session is never ended correctly with QUIT. For the record, Outlook 2000 also has a similar problem. So I am beginning to wonder whether it is the email server that is misbehaving (although webmail works ok).
Build Identifier: Mozilla Thunderbird 0.5 (20040207) I experience the same problem. It is always a spam message that will block me from downloading email from a pop3 account. I have no problem downloading email from other accounts or accessing already downloaded email on the blocked account. Leaving Thunderbird for a few minutes results in the following Alert: Unable to write the email to the mailbox. Make sure the file system allows you write privileges, and you have enough disk space to copy the mailbox. I do have the write privileges, and I do have more than enough disk space. The only solution i've found is this: 1 Logg onto the mailserver and access pop3 account with mutt 2 Delete all spam messages from inbox 3 Restart thunderbird 4 Get Mail now works properly again. This does seem related to bug 224878.
I have the same problem: All time when a collegue send an email to all people of my compagny, thunderbird 0.5 could not get this email by pop3 (I must use my corporate Lotus Notes for delete this email). This probleme is reproductible.
Same problem in ThunderBird 0.7. Seems to happen with any email with oddly-encoded characters. According to webmail, the last one that made TB fail had a subject line of "=?Windows-1251?B?0u7t6Ofo8PP++ejlIO/w7vLo4u725ev+6+jy7fvlIPju8PL7IFBPV0VSIEdZTQ==?=" The body text was rendered in webmail as " Рады предложить Вам наилучший и выигрышный путь преобразить свое тело, подтянуть мыжцы ног и ягодиц улучшить форму тела, попрощаться с целлюлитом ! Спецакция !! Бесплатная доставка по всей России!!! Узнайте подробнее на нашей странице:"
Same problem with 0.7 final. The message I had trouble with is attached below (source comes from webmail); maybe it's because the Subject line is missing? -- Return-Path: <Sergio@quintanaroo.com> Delivered-To: firstname.lastname@example.org Received: from cdm-208-180-253-224.bcst.cox-internet.com (cdm-208-180-253-224.bcst.cox-internet.com [22.214.171.124]) by mail1.dr.myx.net (mydomain.myx.net) with SMTP id 92EE5300B52 for <lucianf@xxxxxxxxxxx>; Mon, 21 Jun 2004 03:09:14 +0300 (EEST) X-Message-Info: 9[1 Message-Id: <20040621000914.92EE5300B52@mail1.dr.myx.net> Date: Mon, 21 Jun 2004 03:09:14 +0300 (EEST) From: Sergio@quintanaroo.com To: undisclosed-recipients:;
Windows 2000 SP4, thunderbird version 0.7.1 (20040626) Received an email message that resulted in similar message. 'Unable to write the email to the mailbox' Had 53 messages in inbox, first 23 were downloaded, 24th was problem message. It wouldn't download any more messages. And it didn't mark the first 23 as junk. They most likely would normally be marked as junk and moved. I'm going to add an attachment with the message.
Well replacing my inbox with the attached didn't seem to duplicate the problem. So I won't bother posting the POP3 log. Maybe the junk filtered learned it's way around it? Anyone else want to try my inbox full of 53 junk messages?
Happened again. Closing thunderbird and opening again caused it to download 1 of the remaining messages and then stop again. Closing thunderbird and opening again caused it to download the rest of the messages. So TB is definitely able to get around the instance I have been running into.
Does waiting for the RETR reply have a timeout? From what I can tell of this problem, the server is either dropping the connection or not fully replying with the body of the email, leaving Thunderbird waiting for the message it is never going to get. Timing out may be a simple way of flagging there is a problem.
http://kb.mozillazine.org/index.phtml?title=Thunderbird_:_Issues_:_Folder_Being_Processed This explains the why: because the message headers aren't complete or empty. In my Horde webmail, I get a lot of those from: [no subject] emails, and TB 0.7.2 chokes on this every time. Can't download, get the 'folder being processed' alert when trying to Get mail (the icon/logo at top right is inactive, showing no connection). Using winXP sp1.
All of these caused the issue for me that I kept. The output is from the web mail from my internet provider.
I also see this, but without any predictability with this version: version 0.7+ (20040813)
Hello, We still have the same problem with the last builds of Thunderbird (20040910) : http://forums.mozillazine.org/viewtopic.php?t=123102 This might be related to Qmail as POP server. A workaround I found is to use Thunderbird/Linux to download the blocking message. I now run into this bug several times per day (having about 9000 e-mails/day, 99% is spam).
[First ever bugzilla post, I have RTFM but may break netiquette anyway-sorry!] Platform: Windows 2000 Professional SP4 Build identifier: Mozilla Thunderbird 0.9 (20041103) Email server: Not under my control, this taken from email header, not sure how much is useful/relevant: qmail-scanner-1.22 (clamdscan: 0.74. Clear:RC:0(126.96.36.199) This is affecting me between one to five times a day, with about 50-100 emails a day, ~98% of it spam. Created an attachment (id=167752) https://bugzilla.mozilla.org/attachment.cgi?id=167752&action=view
Thanks for attaching the log (BTW, in general the log in libcap format would be even better). And the effect you see is that TB stops retrieving messages after receiving the last bytes of the mail in the log? It waits until stoped manually?
(In reply to comment #25) > Thanks for attaching the log (BTW, in general the log in libcap format would be > even better). OK cheers for the pointer. I figured there had been enough email/Thunderbird logs and this might be of additional help :-) I could try and get it in libcap format if you'd like. > And the effect you see is that TB stops retrieving messages after receiving the > last bytes of the mail in the log? It waits until stoped manually? I've had this happen so often, I am 98% sure that the below is how things happen. When it happens again I can come back and give you 100%. When it hits the last bytes, the "Stop" email button is greyed out and then once TB reaches it's timeout (45 seconds is it?) it will silently give up, not having saved any of the email from the server from that session. If you then ask TB to download messages, it will repeat. If you ask TB to download /before/ the timeout it informs you that the folder is still being processed. HTH Adam
dumb question - is the server not reporting the right number of bytes, so we're still waiting for data, even though we see the '.' <eol> ?
(In reply to comment #27) > dumb question - is the server not reporting the right number of bytes, so we're > still waiting for data, even though we see the '.' <eol> ? "+OK 672 octets follow" Assuming it means from the start of the next line, with "\r\n" as two bytes, then I count 675 bytes. I'd get several people to confirm the count though, I'll go nuts if I do it again.
(In reply to comment #27) > dumb question - is the server not reporting the right number of bytes, so > we're still waiting for data, even though we see the '.' <eol> ? No, it works that way: If we read as much bytes as the server said the message has, we'll stop as soon CRLF.CRLF is encountered. If CRLF.CRLF is encountered before we've read enough bytes we'll stop as soon ReadNextLine() returns with pauseForMoreData set. Besides that, Adam is right. 672 bytes are the exact count of the message (the final .CRLF doesn't count). And whatever the message content is (with or - like here - without a body), it won't affect the message retrieval itself. I tested this before and did a few minutes ago. My guess (and hope) is, that some filter or the Junk Mail Controls hang if they encounter a message like Adams. So Adam, it would be interesting if a) you're using filters and/or the JMC. b) all of the messages causing a hang are without a body.
thx. I'm not sure how happy the message parser itself will be without a message body, defined as some text after a blank line but I don't think it should stall message retrieval. I'll try to figure out a way to simulate this...
> My guess (and hope) is, that some filter or the Junk Mail Controls hang if they > encounter a message like Adams. > So Adam, it would be interesting if > a) you're using filters and/or the JMC. > b) all of the messages causing a hang are without a body. Argh, I can't believe the JMC *OR* filters didn't even occur to me! Bad, bad geek. I've switched off JMC and will see if it's still affected with filtering on. Then I'll put JMC on and filtering off etc. I'm pretty sure I've had blocking email that had a body and some that didn't. Will try to see if it makes a difference next time I get one.
(In reply to comment #30) > I'll try to figure out a way to simulate this... As I wrote I tested this with a server simulating script and had no problems. I just realized I even have JMC switched on for this account and even a filter set that inspects the body. That spells trouble for my theory. But another independent test can't be wrong.
Okay - since there are a few people actively watching this, I've got an email on the server atm that is causing this and can wait while we try some things. (I am checking email outside of TB so will get bug mails) It hasn't got a body and ends with a broken Message-ID header: Message-ID: <C[20\r\n I can post another tethereal dump but won't post a libpcap as I do not know how to remove my username and password without breaking it. If anyone can point me how to get tethereal to filter certain packets feel free if it'll help. I've turned off everything in JMC and adaptive filter for this account. I then manually unticked all the filters, quit and restarted TB - still blocking. Quit TB, renamed msgFilterRules.dat, tried again - still blocking. Next idea please! :-) Adam
> I've had this happen so often, I am 98% sure that the below is how things > happen. When it happens again I can come back and give you 100%. > > When it hits the last bytes, the "Stop" email button is greyed out and then > once TB reaches it's timeout (45 seconds is it?) it will silently give up, not > having saved any of the email from the server from that session. > > If you then ask TB to download messages, it will repeat. > If you ask TB to download /before/ the timeout it informs you that the folder is > still being processed. Just checked - this is exactly what is happening. Also, the "Stop" button doesn't get re-enabled.
Adam, can you try a pop3 protocol log so we can compare it to the others? http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop do you have pop3 leave on server set? I wonder if the issue is that there's no UIDL in the message.
(In reply to comment #35) > do you have pop3 leave on server set? I wonder if the issue is that there's no > UIDL in the message. It's set to delete from the server.
This has got a full dump of the last POP3 protocol packet and the other port 110 traffic [brief, not full dump] around then.
Christian, note that we never print out any RECV: data lines in the pop3 protocol log. So that means we never read any data from the packet, if I understand things correctly. Also, is this odd? +OK 582 octets follow.\r\n Response: +OK Response Arg: 582 octets follow. Return-Path: <ZNXXP@>\r\n specifically, the two lines Response: +OK, Response Arg:... In my protocol log, I see +OK XXX Octets followed by: RECV: Received: from C9ma... but I haven't done a packet trace...
Response: +OK Response Arg: 582 octets follow. this must be something ethereal does, right?
(In reply to comment #38) Right, I noted this also. In Mozillas own log we don't even see the first line of the message but tethereal gets it all. Just in case it is this again, do you have any AV software (Norton, McAfee a.s.o.) running on your machine? > this must be something ethereal does, right? Yes, normal Tethereal behaviour. In graphical Ethereal you've a toggle to show/hide the parsed response, Tethereal prints all.
yeah, good question, Christian. I suspect Mozilla is never seeing this data.
(In reply to comment #40) > Just in case it is this again, do you have any AV software (Norton, McAfee > a.s.o.) running on your machine? Bingo! Norton Antivirus 2002 8.07.71C Stopped NAVAPSVC.exe, killed NAVAPW32.EXE. Fired up Thunderbird and woosh all the email has come through fine. Unfortunately I can't test anymore till I get another email like that to see if it still goes OK with JMC and filters. Once again I shall kick myself for not thinking of that. Cannot believe how much of a sloppy troubleshoot I did of this!
(In reply to comment #42) > Norton Antivirus 2002 8.07.71C > > Stopped NAVAPSVC.exe, killed NAVAPW32.EXE. Fired up Thunderbird and woosh all > the email has come through fine. Hehe, they did it again. :-/ > Once again I shall kick myself for not thinking of that. Don't do that. I've seen more bugs caused by AV software but it always comes to my mind at last. Have a look at http://www.eyrich-net.org/mozilla/mozvsav.html, topics 3 and 4. If you can't find your problem matching one of these, I guess I've to update the page again.
(In reply to comment #43) > Have a look at http://www.eyrich-net.org/mozilla/mozvsav.html, > topics 3 and 4. If you can't find your problem matching one of these, I guess > I've to update the page again. "The corrupt mails...contain null bytes" don't think it's this. "These corrupt mails don't have CRLF (0x0d0a) as line terminators but only a LF (0x0a)." or this. I'd say that it's any header part of the email that is terminated unexpectedly, (maybe without a closing angle bracket > ) but haven't got the means available or the logs of enough problem email to test that theory ruggedly.
Relevant packet from tethereal. This as well as the other two I have attached are all terminated with: [<n>CRLF Where "n" is a one or two digit number. The [<n> have all been unexpected at the point which they're present. I'll post two more when I get them unless you've got enough or want more!
This is an older email I kept a copy of so couldn't have a look at it on the server to ensure the corruption was the same there, and not created on the way between it and my PC. It was not downloaded by Thunderbird...which you know as it has no X-Mozilla in it :-P Note this email differs slightly as the first line and ">rom:" line have the first and last characters corrupted, but I figured it was relevant to this bug.
Another broken Message-ID header: Message-ID: <V[20 Unless more samples are wanted I'll not submit any more.
Thanks so far. Though we can't help that problem by patching Mozilla, the logs and lowering down the cause will hopefully help other people running into this problem.
Just a note that when I experienced my problems, although I haven't seen it in quite a while, I was/am running NOD32 from Eset Software (http://www.eset.com/).
Christian, David, is Bug 253886 same problem as this bug?
*** Bug 253886 has been marked as a duplicate of this bug. ***
*** Bug 274429 has been marked as a duplicate of this bug. ***
*** Bug 253886 has been marked as a duplicate of this bug. ***
Set Bug 127461 to "Depends on:" of this bug, because of next. Bug 127461 introduced mail.pop3_response_timeout(default=45sec.) to resolve same problem(forever wait) on 2004-10-26. Then problem of this bug has been slightly improved after the fix, - "forever wait" is changed to "RETR error due to timeout"
Depends on: 127461
I reproducibly encounter this problem with messages that have this header: Return-Path: <> The error message I get is, Unable to write the email to the mailbox. Make sure the file system allows you write privileges, and you have enough disk space to copy the mailbox. This started when I received a bounce message from MAILER-DAEMON@hk.sina.com.hk with the Return-Path header out of order. To reproduce the problem, try sending a test message to this address: email@example.com This address was the one that bounced a spam message with my e-mail address forged in the From: header, and I tried sending a test message to the same address and received another bounce. Both caused the error and broke mail check in Thunderbird 1.0 and 20050131. Same bug?
(In reply to comment #55) > Unable to write the email to the mailbox. Make sure the file > system allows you write privileges, and you have enough disk > space to copy the mailbox. > > This started when I received a bounce message from MAILER-DAEMON@hk.sina.com.hk > with the Return-Path header out of order. The problem you're experiencing is most likely bug 166111. I know that sender and error message from one of the testaccounts I got for that bug. It's not the empty Return-Path but a bad combination of bytes at the end of the message that make us stumble.
*** Bug 280784 has been marked as a duplicate of this bug. ***
I have this problem on Thunderbird 1.0.2 Actually I have it every 2-3 days :( Somebody please fix this thing. Seems that there is something in the headers of some mails that Thunderbird does not like... Thats what sendmail logs said about all this ---- Apr 26 17:08:05 localhost ipop3d: Command stream end of file while reading line user=baltm03 host=my.host.name [my.ip.addres] --- I can login to mail mail box with popcorn or other mail program, after deleting few mails everything is Ok.
I have similar problems, I tracked the cause to be any file URL contained in an incoming e-mail. Steps I use to reproduce: 1) Compose a html format e-mail using Outlook. 2) Choose insert->hyperlink 3) Chose type file 4) Enter in URL file://D:/test.txt 5) Send the e-mail 6) Attempt to download using Thunderbird POP3 7) Download will fail and timeout Does not matter whether D:/test.txt exists or not.
Shouldn't there be a - in the blocking 1.1 field if it was -'ed?
Can you try a 1.1a build? We fixed a few issues in this area.
(In reply to comment #61) > Can you try a 1.1a build? We fixed a few issues in this area. Actually this problem just went away without making any changes to Thunderbird, I am still on 1.0.2 and one daty recently the e-mails taht previously could not be downloaded just downloaded ( and continue to do so) without any further difficulty. I noticed in some replies that NAV was pointed to as being in conflict with TB, In my corpiraete environment it is not possible for me to kill NAV, ( even if I try it restarts immediately), so I was unable to test if this was the problem. I can only assume now as a best guess it was a NAV conflict and some NAV update occurred that resolved the TB conflict?
(In reply to comment #61) > Can you try a 1.1a build? We fixed a few issues in this area. Of the recent reporters only Mike has responded but perhaps SkewerMZ will comment. (3 others have not responded to an email). FWIW, reporter address no longer valid. Perhaps fixed?
(In reply to comment #61) > Can you try a 1.1a build? We fixed a few issues in this area. Haven't seen this issue that I can remember lately, but then, how would we test it? If there wasn't a definite fix, maybe just leave the bug open with target as future.
My parents ran into a similar issue a while back using mozilla mail with Mozilla 1.7.x. I upgraded them to a 1.8 nightly and there were no more problems. I don't know how much code Mozilla mail and Thunderbird share, but I would expect that most of the backend code is the same, so it must have been fixed somewhere along the way.
(In reply to comment #64) > (In reply to comment #61) > > Can you try a 1.1a build? We fixed a few issues in this area. > > Haven't seen this issue that I can remember lately, but then, how would we test > it? I can send you from my webmail a message which still triggers the bug for me in T-Bird 1.0.6 -- though, except for sending this message to myself to test, I haven't run into the problem in a while either.
1.06 is not as interesting as 1.1a2 or the upcoming 1.5b (we decided to change the release version number to 1.5, so 1.5b is the beta and 1.1a2 was the second alpha of the same release.
(In reply to comment #67) > 1.06 is not as interesting as 1.1a2 or the upcoming 1.5b (we decided to change > the release version number to 1.5, so 1.5b is the beta and 1.1a2 was the second > alpha of the same release. Yes, but 1.0.6 is VERY VERY VERY important to end users, as that is the one recommended by Mozilla for installation in non-test environments. Until 1.5 is out and recommended, 1.0.6 is it.
let me try to put it another way - it's very very important for us to know if it's fixed in 1.5.
Forget 1.0.6. I responded to a message asking "how to test this" by offering to mail a problematic message. If anyone's interested, say so on the bug or mail me directly. I'm sorry, but I don't have the time to play with additional installations. I was just offering to help the ones who do.
Sure, send me the message. I doubt it will cause the problem, but it's worth a try. Do you have a virus checker installed? If so, have you tried downloading this message w/o the virus checker enabled?
(In reply to comment #70) > Forget 1.0.6. I responded to a message asking "how to test this" by offering to > mail a problematic message. If anyone's interested, say so on the bug or mail me > directly. Shai, was David able to test your message?
Version: unspecified → 1.0
(In reply to comment #72) > > Shai, was David able to test your message? > Yes. He received it with no problem, which, to me, ascertains that -- as claimed before -- the problem is with anti-virus checkers of different sorts (in my case, it is an organizational firewall I have no control over).
(In reply to comment #73) > Yes. He received it with no problem, which, to me, ascertains that -- as > claimed before -- the problem is with anti-virus checkers of different sorts > (in my case, it is an organizational firewall I have no control over). > I also do believe this problem/conflict is caused by NAV anti-virus software in my environment, as the problem has again returned (see comments 59 and 61 earlier from me), though now for different e-mails. Now any e-mails with html attachments cannot be downloaded and cause Tbird to hang. Outlook which is the e-mail that my company supports and wishes me to use and it does not encounter these problems ( one difference is Outlook is set up in IMAP mode where as Tbird is POP3). Even if NAV or some other software is the cause, it is not acceptable that Tbird hangs and the user has to move/delete the offending e-mail (by some other method) before re-starting Tbird. The worst that should happen is Tbird gives up on the offending e-mail and logs a warning
(In reply to comment #74) > Even if NAV or some other software is the cause, it is not acceptable that > Tbird hangs and the user has to move/delete the offending e-mail (by some other > method) before re-starting Tbird. > Hanging is unacceptable. Having to restart (in my experience, it is sometimes enough to go offline and back online, but that too) is unacceptable. However, > The worst that should happen is Tbird gives up on the offending e-mail and logs > a warning > TBird cannot tell the difference between this case and many other bad things that can happen to the communications channel (the mail server hanging, someone stepping on a communications cable and blocking the bits flow, whatever). Short of supporting a get-headers-only workmode, like mail programs used to do when client band-width was a real issue, I can't see how TBird could do anything reasonable about the offending message. It can, though, respond reasonably to the timeout on the connection, which 1.0.7 doesn't.
You are going to ship an email client which does not work? I don't know that this one should slip through the blocking channel. If it can't download email, that is the end of the road for this email client. One can only use PINE or www.mail2web.com to fix these issues for so long.
(In reply to comment #76) It's been a year since everyone said "it's the Anti-Virus"; nobody made any contradicting claim since then, and I can personally confirm now (which I couldn't back then) that in two installations (of 1.5) in different networks with different AV and firewalls, one suffers and one doesn't. While treatment of the situation has improved -- TBird now responds to what is essentially a timeout on the connection by quitting the download operation, rather than waiting forever -- it is still not perfect; when it quits, it fails to filter junk-mail and shoot up the new mail notification. It clearly aborts, rather than end, the download, and that's suboptimal. > You are going to ship an email client which does not work? > I still ask you read again the last 10-20 comments on this bug, and if you're short on time just comment #75, and reconsider your strong language. To my understanding, the developers have done almost all in their power to solve the problem.
Those earlier comments were on an earlier version. The later version(s) still do the same thing. I have yet to see a "warning" message anywhere.
is there anything here that is easily tested? I'm not seeing anything.
Assignee: mscott → nobody
Whiteboard: [sg:dos] → closeme 2008-02-05 [sg:dos]
Resolving closeme bugs that did not have any useful information provided since the last comment. -> incomplete. Please feel free to comment if the issue still occurs in the latest supported version 188.8.131.52 or trunk nightlies. Filter on ENDEAVOURLANDSATNIGHT123
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
based on comment 75 and others I'm changing the resolution to INVALID
Resolution: INCOMPLETE → INVALID
Whiteboard: closeme 2008-02-05 [sg:dos] → [antivirus:xxx][sg:dos]
You need to log in before you can comment on or make changes to this bug.