Mozilla Build ID 2002053012. Windows 95b. When attempting to download email from a POP server to the inbox I recieve a message stating: "Unable to write the email to the mailbox. Make sure the file system allows you write priveleges, and you have enough disk space to copy the mailbox." Current inbox size is 1724KB with 6.45GB free space on this FAT32 partition. Have attempted deletion of .msf files with no change resulting. Also deleted popstate.dat file with no change resulting. Email is filtered through Norton Anti-Virus 2000 as it is downloaded.

Getting the same thing on Win XP Mozilla build 2002093010. Plenty of disk space and I am logged in with Administrator rights. I have gone so far as to delete all the files for that account. Mozilla recreates the mailboxes and still gives the error. No filtering prior to Mozilla happening here. Could it be a 'bad' email message that is causing the error?

I believe it to have been a bad email on the server. I was able to access the messages through an HTML interface and delete them one at a time until they would all download.

Same here, I deleted some spam off the server and was then able to download the rest of my mail. I guess the question is "What was wrong with the message that caused the error?" Unless it starts happening frequently it is probably pretty low priority but it would be nice if a malformed message didn't 'break' Mozilla. The error message implies that the problem is on the client and doesn't say which mailbox(s) is having the problem. Could use a bit o' tweaking there.

This problem just happened to me, though I'm running Netscape7 on Windows98. Each time I tried to "Get New Mail" just one message would come down (always the same one) and I'd get the Alert message "Unable to write the email to the mailbox. Make sure the file system allows you write priveleges, and you have enough disk space to copy the mailbox." Once I manually deleted the message from the POP3 server, everything was fine again. In case it helps I'm attaching the message header from the "bad" message. The message text was just a couple of screens of regular looking text.

I get this too. Happens every now and then (once every other day maybe). I dismiss the dialog and then the rest of my messages are dewnloaded on the next run (at least I hope all of them are being grabbed, and that I'm not losing a message each time it happens!) I have plenty of disk space. Possibly a locking issue on the mailbox files?

This email caused MozillaMail (Moz1.4 Win98; completely new install, profile kept) to say "Unable to write the email to the mailbox. Make sure the file system allows you write priveleges, and you have enough disk space to copy the mailbox." Of course there's enough diskspace and Win98 has no permission-management.

I had the same problem with Moz1.3 on Win98. I did a complete new install of Moz1.4 and kept the profile. This did not solve the problem. Thanks for people here pointing out that deleting emails (via ssh & pine in my case) could solve the problem. It did! I use Spambayes to filter my emails (if this is relevant). I made an attachment #127083 [details] of the critical email. It's some ISO-codec -- I was able to view it with pine (it's spam). OS should be changed Win95 is not appropriate. Change to "All" ? I think this bug is a realy bad one. If it becomes more public someone could attack MozillaMail users making their Mail-Client nearly useless. It's possible that some users aren't able to delete their with some additional mail-client.

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

Maybe the description and/or attachment of bug 212631 is helpful. Confirming this one.

I think this is partially due to the Server Software used for the POP server. When I use Popfile to route my mail these emails are processed by mozilla correctly. So when Popfile acts as a pop-server there is no problem (no spam filtering in takes place in Popfile, just routing the messages), but when my normal mailserver acts as a pop-server, we have this problem. So, the problem exists in my MailServer, wich is the latest version of Mercur Mail. You can download a free trial version at www.atrium.de Please do not close this bug saying that the bug lies is in the server software. Normal-everyday users cannot determine their own popserver software, as this is done by the ISP!

could it be a timing issue on the server side that at some point make mozilla return a uninitialized value on a stream read operation, thus fooling the browser to think the size of the message to read is really big? or something leading to similar problem? I've seen a similar bug fixed by Miguel in Mono last week. PS i know nothing of the code.

This was probably introduced by the patch fix for #62480, implementing one check too much. Since I don't have a development version set up, I can't determine which, but will continue looking into that. I have the same problem, querying a Zoe (sf.net/projects/zoe) Mail DB and POP server. Since Zoe does not implement deleting of emails yet, this is a showstopper for me. Pegasus Mail works, so I suspect that the "malformity" of the message must be recoverable.

I had a 9 MB mail I couldn't get out of my POP3 box with 2003-09-03 because of this error ("Unable to write the email to the mailbox. Make sure the file system allows you write priveleges, and you have enough disk space to copy the mailbox."). The mail was completely downloaded but not deleted on the server, hence blocking my box. So I tried with a debug build (~2003-09-03-13) and a different profile and it worked, so there may be a profile issue, too.

The bug appears when the mail contains the sequence : \n.\r (0x0A 0x2E 0x0D) and any other character except a \n (0x0A) just after, anywhere in the content. I coded a small fake POP3 server in order to be able to reproduce the bug. The ZIP file attached contains a Visual C++ 6.0 project, with the source code and the compiled version of that fake POP server. This fake pop server always returns a mail with the \n.\r* sequence, which makes the mailer the unexpected message, and make it block to get the remaining mails if some more are present. I actually tested it with Thunerbird 0.4 and Mozilla Mail. Without the \n.\r* sequence the mail is retrieved correctly by Thunderbird/Mozilla Mail. To use that fake POP server, create a mail account with Thunderbird/Mozilla Mail, with the POP server address set to your local computer : 127.0.0.1. Enter anything else for other fields. Launch the FakePopServer, and get mails from this new mail account. You will receive a message called « fake pop3 message » which content is "Hello World\n.\rblabla" (without the double quotes), and the message : « Unable to write the email to the mailbox. Make sure the filesystem allows you write privileges, and you have enough disk space to copy the mailbox. » will appear. This code is mainly intended to developers, I hope it will help to correct the bug.

Followup, particularly to comment #13. This is a showstopper here as well, for the same reason. Either Moz has to go or Zoë does, since once this error occurs with a Zoë-hosted mail database, one is basically completely hosed. In my case Zoë has to go, which seems a bit unfair since this is a Moz bug :-( FWIW, running the Moz 1.5 release here, under Windows XP (Home edition) (I started getting this error this morning; fortunately, I've only been running Zoë for a week or so as a test on some low-volume mail accounts, so the database I'm about to lose isn't too big.)

There must be more to it than this - I have the same problem right now on all my pop3 accounts - started with just one - then later all - I used mailwasher to remove all mails from the pop3 server - then deleted the .msf files - Then it started working for a couple of mails, but then it started complaining again - but this time I could detect no "bad" mails on the server... I'm actually close to switching to something else like OE (God Forbid) because I keep getting the same mails over and over and over again until I delete them from the mail server... Only to have it start on me again 20 minutes later... :( One of my friends switched clients already...

I just downloaded and install Mozilla 1.6 and this is still a problem. I can't use this untill this problem is fixed.

I think the severity should be set to major or critical, as this bug deals with the mail core engine. I receive complaints from people I recommended using Thunderbird. A lot of spam program do not send well formed e-mails so Thunderbird is unable to download them from a pop server.

#20 I couldn't agree more, this hurts the ones who have been advocating Mozilla/Thunderbird :(

The problem is not only with Mozilla. Mercur Mail (server) sowftware is now patched to version 4.2 SP4 and the poblem no longer occurs. So just ask your ISP to upgrade to the latest version (should take them no more than 5 minutes). Mercur 4.2 SP2 produced some **** that mozilla inteprets correctly as ****. Mozilla stops getting your mail and produces some error where Outlook simply ignores it. The problem is that Mozilla stops getting any mail beyond the corrupted spam email because of the error. If you get your mail in Mozilla through Popfile Mozilla says "Dele command unsuccesfull" when it hits the corrupted email. But it will get your mail beyond the corrupted email and it deletes the corrupted mail from the server. So Mercur 4.2 SP2 probably produces some **** about it not being able to dele the corrupted email when in fact it just has deleted it. Strange thing is that if you get your mail directly in Mozilla (without popfile) the error message changes to "Unable to write the email to the mailbox. Make sure the file system allows you write priveleges, and you have enough disk space to copy the mailbox." and you won't be able to get mail beyond the corrupted mail.

#22 That is not acceptable... We cannot ask the people to whom we advocated Mozilla/Thunderbird, that they should get their ISPs to upgrade/change pop3 servers. It should just work! Mozilla should either * leave the message and continue * delete it * ask what action to take... Besides, I have the problem on two servers, one of which is an InterMail server (serving thousands of clients), the other I don't know (but they serve an equal amount). Right now, people are forced to use other clients than Mozilla/Thunderbird. If they are not so techy that they use programs like mailwasher or the like. I actually had to edit my mailbox file and remove a corrupt mail yesterday. We shouldn't have to do that... I haven't heard anyone with similar problems with IMAP...

#22 says: If you get your mail in Mozilla through Popfile Mozilla says "Dele command unsuccesfull" when it hits the corrupted email. But it will get your mail beyond the corrupted email and it deletes the corrupted mail from the server. Um... I was using Popfile and I wasn't using Mercur (I was using Zoë). And most emphatically once I hit this bug there was no way to proceed past this point, no matter how many times I tried, restarted, rebooted or whatever. I spent the better part of a morning trying to get around the problem, and eventually gave up. If I had been willing to mess with the Zoë source code, I could probably have deleted the bad e-mail from the Zoë database; but as far as I could see, there was no other way to gte past this bug. So I have to agree with #23. This really loooks like it needs to be fixed so that Moz is more graceful. Pointing a finger at some other bad piece of software isn't going to work in the real world, regardless of whether the fault really lies with the other software.

#")/!)#"¤ I have just helped most of the people that I pushed to thunderbird to migrate away from it. I suspect none of them will ever use it again. I can see that this bug has existed for over FOUR months, how come it wasn't fixed? This bug is of critical severity, not normal as it was filed. Now that I have helped my friends, I'm going on the net to find another mail client.

I thought this problem only occurs with Mercur Mailserver for Windows, but it doesn't. Getting end users to conact their ISP's is indeed not a solution. Please fix this bug... change it to critical. This problem renders Mozilla Mail useless since 1 in about every 100 spam mails has this problem. I would recommend Mozilla Mail for its good spam filtering, but this problem renders it useless if you get spam. Because of this bug, Mozilla Mail is useless for anyone with an ISP that runs affected Mailserver software. I can understand the frustration: If you finally get people so far as to actually leave Outlook Express, just to see them return to it because Mozilla Mail has this bug.

This is serious. Affects Thunderbird clients running most or all versions of Windows. Prevents downloading of new mail until faulty email is removed from account via webmail You need to update the "OS" and "Severity" properties for this bug. Needs fixing. See http://forums.mozillazine.org/viewtopic.php?t=44570 for more comments.

Critical loss of functionality. Not our fault, but we have to clean up their mess.

"Windows 95" OS property is incorrect. Please change to: "Windows - All versions". This issue affects a large number of users. I would think that the Priority should be set to 2, at least. Thank you!

> "Windows 95" OS property is incorrect. > Please change to: > "Windows - All versions". Yes! I forgot to mention that! I, for one, am using Windows XP, and I'm guessing that the bug is for all windows versions...

taking - perhaps we think the server is telling us about the end of the message...

Does thunderbird have some sort of "logging" for mail activity? I'm actually still using thunderbird at home, don't ask why. But I've deleted all the "bad" mail from the pop3 server. And I've deleted all the "bad" mails from the inbox file that I could identify, but there seems to be some left - So is there a way to see what it chokes on?

(In reply to comment #32) > Does thunderbird have some sort of "logging" for mail activity? > I'm actually still using thunderbird at home, don't ask why. But I've deleted > all the "bad" mail from the pop3 server. And I've deleted all the "bad" mails > from the inbox file that I could identify, but there seems to be some left - So > is there a way to see what it chokes on? plase see: http://mozilla.org/quality/mailnews/mail-troubleshoot.html

renominate for 1.7a if we get a good diagnosis and patch in the next few days

Christian, would you like a crack at this?

I was playing around with my Perl written pop server and can reproduce the problem. There seem to be not just one prloblem here. Having very short mails the terminating period (\n\r.\n\r) of the message retrieve always shows up in the message itself. Mozilla's message retrieve code was always a horror to me, but I'll have another look at it.

Ok, some further debugging and I know where and what happens. But I've no clue how to do it better. First let me say the error occurs with a dot between a CR or LF on the one and CR or LF on the other side. So it doesn't need to be a \n.\r as written in comment #16. It also occurs with \r\n.\r\n. This is the first bug. According to RFC 2821, 4.1.1.4, *only* \r\n.\r\n must be treated as end of message, nothing else. Bug number two is, that we throw an alert and disconnect if something more than one \r\n follows a single dot on a line. Even \r\n.\r\n\r\n at the end of an otherwise full conformant message triggers this. That the error message is greatly missleading is another problem. Ok, where does all this happen? The loop in nsPop3Protocol.cpp#2826 and following lines reads a full input line (which is defined to end with \n by default) and calls BufferInput() in nsMsgLineBuffer.cpp#123. This function in turn separates the line at any \r or \n (bug 1) and calls ConvertAndSendBuffer() which in turn calls HandleLine() (nsPop3Protocol.cpp#2967). HandleLine() tests for !m_pop3ConData->msg_closure at begin and returns error if it's true (bug 2). This is the case for any line read in after a single dot on a line. See #2995 resp. #3018 for the if and the set. I'm aware that a single dot on a line within the mail is illegal, but our reaction is wrong. Locally we only save the data before the dot, that's ok. But throwing the (wrong) error and just disconnect from the server is not ok.

thinking as I type, re the second problem, could we check for data available after the '.' - if there is, read it and throw it away, but don't drop the connection? Mabye put up an error w/o dropping the connection?

Of course we can read data after the dot. And in most cases this shouldn't be more than some CR and/or LF (at least I can't find a single dot in the attached example files here so it must be something invisible at the end). But I'm always think if another 5, 10 or more lines follow - we don't know when the server has send everything he wanted to send. Waiting a fixed time for more data is ugly. I don't think throwing an alert is necessary at all. But it shouldn't hurt if we do - as long as the text is more correct than the current.

I was thinking that in most cases, all the data would be there. However, if we don't drop the connection, but just read the data, and then we issue a new command but data still comes from the previous command, odd things could happen. When the server does this, is it returning more data than it should? Or is the msg size correct?

I don't know, I guess both is possible. We shouldn't count on the server only sends as much data as he advertised. Hm, taking further message lines as answer to our next command(s) would give us wrong results. But our problem that the user gets the same message again and again because it isn't deleted could be solved. Getting garbage in respond to "DELE 1" could make us end the mail get, but the message would be deleted on the server. Also setting the mail as done in popstate.dat for messages to be left on server should be possible. But that's nothing than a workaround.

This patch makes two changes. After having read the terminating dot, no calls to BufferInput() are done anymore. We just loop over ReadNextLine() to empty the buffer until there's no full line in it. This doesn't mean the server has sent everything in his pipeline, with slow servers or slow connections data can arrive after we finished the do-while loop. But I think it's the best we can doo. Second change is made to not interpret manually added lineendings (e.g. BufferInput(MSG_LINEBREAK, MSG_LINEBREAK_LEN) in RetrResponse()) when reading input. Since BufferInput() is also used when reading local files (nsParseMailbox.cpp#296, nsNewsFolder.cpp#1052) where the CR/LF have to be interpreted, that's quite tricky. But I hope I found a useable way. If m_inspectBufferForCRorLF (no final name, please make a proposal) is set, everything works like before. nsPop3Protocol sets this var to false and so we're not looping through the net_buffer. We only take CR/LF's as line end if they're the only char (or the only 2 in case of CRLF) in the buffer. This combination survived all legal and illegal mails I simulated. If some message data arrives after we finished the above loop, we'll interpret it as response to the next command (DELE for the message, RETR to get the next message or QUIT), with the consequences I outlined in comment #41. I did some tests with KMail and from the results it seems it is doing the same. One thing we should additionally change is sending a QUIT after failure. Without it, the server wouldn't expunge the message even after a successful DELE. We could do this as general behaviour in POP3_ERROR_DONE, or change the error condition in DeleResponse() to if(!m_pop3ConData->command_succeeded) { Error(POP3_DELE_FAILURE); m_pop3ConData->next_state = POP3_DELE_RESPONSE; return 0; }

This patch I meant ...

I just have a small question. POP3 servers inform the client of the byte size of the message, so why don't we just download the number of bytes specified by the server and forget any remaining data ?

First the size reported in the LIST response has proven to be not reliable. And second, the problem of more data beeing received than awaited would persist if more data sent than advertised. There is no fixed amount of data from where we can take the message in the reported size and forget the rest. There can be 1 Byte or 1 KB more data still on the wire.

David, any thoughts about the patch?

I'm monitoring this thread: http://forums.mozillazine.org/viewtopic.php?t=44570&start=15 In connection with this bug, I quote post 404653: "The issue has to do with invalid Message-Id header fields. If messages have an incomplete Message-Id, usually of the form "<O[20", retrieving the message fails. Apparently, this incomplete Message-Id is a trick used by spammers, because Outlook keeps retrieving such messages, but is unable to delete them from the server. Mozilla should be more forgiving when it encounters such messages, but the real solution would be to make your SMTP server drop such invalid messages." Is this true? The . is not the only thing making TB unusable on windows? It's also malformed headers from spammers etc?

Lars, I can't see what an incomplete Message-Id has to do with this bug. If a message with this incomplete Id is encountered, what does Mozilla? Also throwing the error discussed here?

sorry, I was on vacation... Can you do a -uw diff so I can ignore the whitespace changes? nsPop3Protocol inherits from nsMsgLineBuffer, so you don't need a new method to set that flag - you can just set it by poking the member variable in nsPop3Protocol::nsPopProtocol.cpp. And I think it might be better to switch the sense of it and call it m_ignoreCRLFs, since that's the special case. In fact, you could just do the following: + mIgnoreCRLFs = PR_TRUE; + PRInt32 res = BufferInput(line, buffer_size); + if (res < 0) return(Error(POP3_MESSAGE_WRITE_ERROR)); + // BufferInput(CRLF, 2); + mIgnoreCRLFs = PR_FALSE; + res = BufferInput(MSG_LINEBREAK, MSG_LINEBREAK_LEN); + if (res < 0) return(Error(POP3_MESSAGE_WRITE_ERROR)); and remove the special case code you added for just CRLF in BufferInput, when m_lookingForCRLF was false. Does m_lineStreamBuffer->ReadNextLine do what we want already? I.e., return correctly formed lines? Or do we sometimes get a partial line, with aPauseForMoreData set to true? It seems odd that we ignore what ReadNextLine tells us for the most part, in RetrResponse, and treat anything returned by ReadNextLine as a fully formed line. Is that a potential problem?

I'm worried this proposed fix might affect the problem in bug 220225 - if the headers aren't correctly line terminated, then I'm worried Mozilla won't parse them correctly, if I understand your fix correctly. Have you tried your fix with messages that have some headers with just <LF's>? Does Mozilla parse the headers correctly? I realize it's hard to deal with servers that are broken in different ways...

I did add a new function because m_lookingForCRLF has also its own one. But if you say it's unneccessary, I don't mind. You're right, setting m_ignoreCRLFs to the state needed before calling BufferInput() is much better than my else case. This new patch has the same effect like the old one, but is much smarter. I also tested it with messages containing LF instead of CRLF line endings. As far as I know, m_lineStreamBuffer->ReadNextLine() already does what we expect. The buffer always holds a full line, if aPauseForMoreData is set, the buffer is empty. Ok, as full line is treated one with a LF, not neccessarily CRLF. That's wrong but should actually prevend problems with incorrectly terminated header lins like in bug 220225. But it makes us vulnerable to lines containing or ending with \n.\n resp. \n.\r\n Here the remark from RFC 2821 suits perfectly: "The custom of accepting lines ending only in <LF>, as a concession to non-conforming behavior on the part of some UNIX systems, has proven to cause more interoperability problems than it solves". Well, we don't stop right at the first single period. Without having m_pop3ConData->pop3_size (see HandleLine()) bytes read or pausing for more data, we go on. But I nevertheless dislike interpreting single LF.

Comment on attachment 142954 [details] [diff] [review] patch v2 this looks good.

fix checked in.

Great work! Can't wait for a new build with this fix :) Thank you!

No problem. But I want to say it (again) in advance. This patch won't help for really broken messages/servers with much text behind the actual end of message. And it won't help for "\n.\n". I think about filing a bug to change the line endings recognized by ReadNextLine() to \r\n only.

Uhm. As far as I can tell, the only thing that has been fixed here, is that the annoying message no longer is shown. (My about says: Mozilla Thunderbird M6 (20040308) - Downloaded from here: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/ - I assume that the fix is in this?) Let me explain. After a few emails, random of course ;P, it just stops getting my mail and retrieves the same email message over and over and over again filling my inbox if I leave my machine alone. It doesn't get the new messages that arrived since that mail. I have to use a separate program to delete the mail on the server that it keeps retrieving, in order to retrieve the rest (sometimes I need to repeat the process several times). This is the exact behaviour of before, except for the strange "Unable to write email to the mailbox" message... Is it possible that I need to do something?

Hm, it should have the fix in it if the time is PST. I think what happens is what I wrote about in comment #41 and last paragraph of comment #42. To be sure another log would be nice.

Piggybacking on #56 somewhat -- if I understand the postings correctly, what has happened is that one possible cause of this problem has been fixed, but at least one cause still exists. And arguably the situation is actually now worse than originally, in that before one would at least get an error message and be unable to proceed, but now it sounds like Moz just keeps retrying for ever. It seems to me (easy for me to say, I know) that it should be a fundamental design criterion that it be absolutely impossible to concoct any sequence of octets that Moz could receive and cause it to do either of these things. No matter what garbage it receives, it should do something reasonably sensible (even if that "something sensible" is something as primitive as deleting the offending message from the server and creating a dummy message (for the user to view) that says "Malformed message could not be downloaded" and provides whatever further information it can). I guess that what I'm trying to say is that "RESOLVED FIXED" doesn't seem like a reasonable reflection of the true status. Or maybe I am completely misunderstanding, and the problem really has been fixed? (He says, hoping...)

I don't see why the situation is now worse than before. Before the user got a missleading error and the same message again and again for two situations. Now he only gets the message again and again and as a side effect only in one situation. So I think it's ok to handle this bug but as resolved. As noted earlier, there are situations left that can be a problem, but they should be handled in new bugs. To be sure what our situation is, I'll need to see a log from Lars. To resolve the complex of erroneous interpretation of message terminator it's necessary to only interpret CRLF as line ending. This will lead to problems like that from bug 98650 that led to interpret LF as line ending like now. This problem will be only better in one point, the RFC is with us. And the other one is what to do when the server continues to send data after real message terminator received? We need at least to send QUIT after DELE command when receiving a negative answer (which is in fact the rest of the mail).

In regard to whether things are better or worse now: well, maybe I am misunderstanding the situation described by #56. Before, I believe that Moz gave an error message and stopped downloading (at least, that's what happened here). I understood #56 to be saying that Moz can now fill the disk by retrying for ever. That's why I said that the new behaviour is arguably worse than the earlier behaviour. Neither is good, but on balance I would actually prefer a single error message and an inability to proceed as compared to a silent filling of my disk.

It fills the disk when left alone and autochecks in an intervall - one mail for every check. Lars wrote: "This is the exact behaviour of before, except for the strange "Unable to write email to the mailbox" message..." I can't say why this happens as I don't know what the communication on Lars's computer looks like. I only know the situation I described a few times. Mozilla retrieves one mail until the terminator. Moz issues DELE, the server continues to send the rest of the mail and Moz recognize this as DELE failed (throws an error about this fact) and disconnects. While the DELE command in fact succeeded, the mail isn't deleted on the server, because the message gets really deleted while the update status after QUIT is received by the server. This is why I wrote, we should issue QUIT in any case. *But*, after receiving the mail, the mails UID is noted in the popstate.dat until we get a positive answer to DELE. We don't, so it stays in the file. On the next connect Mozilla sees the UID in the file, issues a DELE command (which should succeed this time) and continues with the following messages. Quite the same when Mozilla is configured to leave message on the server. In this case not the DELE but the RETR command for the next message fails, Moz exits. Upon next message get the buggy message is ignored because it's in the popstate.dat. At least that's what I get in my tests. But apparently reality is different from the simulations. :-/

Lars, in addition to a log of such a failing message retrieve, a log of the subsequent retrieve could also be enlighting (just keep issue two gets and attach the log). Also the popstate.date after the first failing get and the information if you have checked "Leave messages on server". Thank you.

Ok, update here. I'm now using the official nightly "Mozilla Thunderbird 0.5+ (20040309)" and have had it running since I installed it earlier today, while I've been away. I've also studied what mails came with "Mailwasher". To me it *seems* like the bug has disappeared. BUT! At some point TB stopped getting the new mails. I restarted it, and the mails poured in... I'm sorry if I've had you on a wild goose chase, but right now I'm not completely sure. I will keep running it for a few days, and go back to using it at work and see if I run into this again. #58 - You might have misread. To me it looked like they did the same thing, but earlier it had a completely out-in-the-woods error message. I "leave messages on the server", and it also just kept retrieving the same message with the old one. I don't agree that this is worse (if indeed there is still a problem) - I read the description of Christian's patch and it sounds ok to me. A lot better than before at any rate! Christian, if I find that I still get this behaviour, I will make a log and attach popstate.dat too. Thanks a lot for your time and effort!

Ok, as far as I can tell this bug is indeed Resolved-Fixed! The first build I used must not have had the entire fix in (it didn't display the error message but displayed the same symptoms). The http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2004-03-09-00-trunk/ was the solution for me! Many thanks! You guys rock!

reopening to reassign to me

remarking fixed

Thank you for your good work - and unpaid, too! Where do we users go to get the "fix" for our email client? I'm using Thuneerbird 4.0. Thanks again Bruce

> I'm using Thuneerbird 4.0. Thunderbird 0.4? No way, you've to get TB 0.5+ (20040309 or newer).

Installed Mozilla Thunderbird 0.5+ (20040312) Still having the problem. I don't currently have source code of the fault- causing email, as I can only get at the non-downloaded emails via web mail. There were quite a few there, so I don't know which is or was the problem. Likely will need to be reopened.

Bruce, sure you can reope this bug if you still see this problem. If you can get the mails source code via web mail that could help too. But the real bytes going over the wire are much more helpful. You're really getting this "Unable to write the email to the mailbox." message?

I have downloaded a recent Thunderbird nightly (20040320) and retried POP with my Zoe setup. The original text message does not appear anymore, nor does it start retrieving the same email over and over. It does hang after a while though; and once this happens, it won't start downloading again. I set TB to log its POP attempts, and the file was empty (TB didn't even try). Restarting didn't help. I'm not sure this is the same problem, but it looks related. I cannot provide a suspect mail because I can't make out on which mail TB chokes.

if the log is empty, something very different is going wrong. Either you haven't set up the logging correctly, or we're just failing to connect to the server at all. It could be that something's messed up in your profile, but I can't think what that would be...

After downloading 1150 messages successfully, the programs hangs here -- I had to press stop.

After restarting Thunderbird (configured to check for new mail, but not to download), I get this output, after I press "Get Mail". Now the hang becomes obvous at the end of the output...

I can't see a misconduct on Mozilla's side. The server answers in response to our request for msg 1151 "+OK Message follows" and delivers -ERR as first line of the message content. Then it stops sending and Mozilla keeps on waiting. The interesting part is, that the first message line is "-ERR", the negative response of a POP3 server. If it's a mozilla bug, I don't think, it's this one. Please try connecting via telnet ("telnet servername 110") to your server and and login using USER axel PASS yourpassword and then RETR 1151 What is the response?

(In reply to comment #75) Sorry for the late answer, but better late than never: > The interesting part is, that the first message line is "-ERR", the negative > response of a POP3 server. > If it's a mozilla bug, I don't think, it's this one. > > Please try connecting via telnet ("telnet servername 110") to your server and > and login using > USER axel > PASS yourpassword > and then > RETR 1151 > > What is the response? You were right: this also resulted in "-ERR", and the server hung -- so thunderbird was not guilty at all. I have since rebuilt Zoe's mail database, and the error vanished. Importing the email store into Thunderbird worked almost flawlessly: one (of a couple thousand) was obviously malformed (it was an HTML mail) and caused t-bird to choke, but the error could be acknowledged, and the rest was imported ok again. Thanks a lot for your help and great work!

I am using 1.7RC1 on WinXP and I still have these problems. Now 3 users in the company have corrupted mailboxes. I need a solution FAST!!!

What do you mean with corrupted? Not readable? Mail lost? And you're getting exactly the error in the summary? Since when? Is your Mozilla installation new or did you just upgrade from a older Mozilla? Please provide us some info like a mozilla log (see comment #33) and if possible a tcpdump log.

The error message i get is "Unable to write the email to the mailbox. Make sure the file system allows you write priveleges, and you have enough disk space to copy the mailbox." On one of the machines Moz1.7b is a brand new installation. - here the inbox can be read but not manipulated in any way (write, move) Another is upgraded from 1.4 prior to the "crash" - at first the mailbox could be read, but after trying to fix things using the methods supplied in the bug description the mailbox can now no longer be read. The third crashed spontaniously. It was running 1.6. Tried to delete the mails from the server, which apparently worked. Moz didn't show any error messages. But everytime a new mail arrived the problem came back. Now a fourth machine has these problems. Also here it was a complete spontanous crash.

http://sillydog.org/forum/viewtopic.php?t=1853 This bug (i.e. "Unable to write the email to the mailbox...") still persists, please reopen, and change OS to all! More attention must be put into this. Thunderbird is unusable until all variations of this bug are fixed, and the alert message is more informative. I stress that the alert message must be fixed because if you fail to fix the bug the message must be made more helpful in the debugging process. If better logging is required to fix all aspects of this bug then you must add a reference to the log in the "Unable to write the email to the mailbox" Alert so that as people continue to encounter this bug they can provide details. No discussion of server faults are relevant, Thunderbird must gracefully handle poorly formed messages. If any mail program can handle the issue then Thunderbird must handle the issue. It appears that this bug has gone on for years; the damage done to the public perception of the reliability of open source projects is severe. Due to the persistence of this bug, it may be time to reevaluate the core parser and be willing to consider a more radical approach. Such as using flex/byson, or some other standard parser, or simply approach the problem of parsing form a new point of view. Clearly the parser needs to address the issue in general of fault recovery.

> Thunderbird is unusable until all variations of this bug are fixed, and the > alert message is more informative. Oh yes, of course, TB is unusable crap with this bug. You guys shouldn't stress the word "unusable" to much. > I stress that the alert message must be fixed because if you fail to fix the > bug the message must be made more helpful in the debugging process. If better > logging is required to fix all aspects of this bug then you must add a > reference to the log in the "Unable to write the email to the mailbox" Alert > so that as people continue to encounter this bug they can provide details. Oh, should "please create a log" suffice? People shall use Bugzilla and read the according bugs. > No discussion of server faults are relevant, Thunderbird must gracefully > handle poorly formed messages. If any mail program can handle the issue then > Thunderbird must handle the issue. It appears that this bug has gone on for > years; Tell me how or even just a reproducable situation with test data and we can talk about it. But not again any general blabla.

> Oh yes, of course, TB is unusable **** with this bug. You guys shouldn't > stress the word "unusable" to much. I'm sorry, let me be more clear. I define unusable (per our own in house development guidelines) as: "application stops functioning, or functions erratically, with no work around." This is the case here. Once the bug is encountered, there are no further options, simply TB is unusable. TB is not a piece of ****, and may remain usable to people who do not encounter this problem, but as mentioned before (nearly two years ago) it is a show stopper once encountered. Please don't take personal offense, this is an accurate and honest assessment of the severity of this bug. > Oh, should "please create a log" suffice? People shall use Bugzilla and read > the according bugs. Surly we can agree that: "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. is not appropriate response to this error? (by the way, this bug report was very hard to find, I fond it from a reference on a forum but a search on bugzilla does not bring up this bug report, not that it’s helpful once you find it.) > Tell me how or even just a reproducable situation with test data and we can > talk about it. Precisely my point people who reach this point, and are less industrious then I will simply uninstall the software. Clearly this is a problem that is difficult to reproduce, otherwise I'm sure the programmers would have solved it by now. Throwing your hands up because a bug is hard to track down is not productive. I'm proposing that the Alert message be fixed so that when the error is encountered details that will help solve the problem are recorded, a link to the files is provided in the alert message, perhaps along with a web link to post the files. > But not again any general blabla. Nonsense, please follow the link provided in my earlier post. And again please don't take my constructive criticism personally. I have no investment here; I am simply a user trying to actually help fix a problem with the software.

(In reply to comment #82) > > Oh yes, of course, TB is unusable **** with this bug. You guys shouldn't > > stress the word "unusable" to much. Yes, it's a show-stopper, but I was able to resolve it by downloading and installing a newer version (I'm using Win 2K). I did have the problem twice since installing Mozilla TB 0.5+ (20040312), which is OK for me. I'm still using this ver. I suspect the current version might be somewhat improved.

I was using version 0.7 (20040616).

> "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. > > is not appropriate response Well, it is appropriate for what it was introduced. But it has been triggered in some other situations too. > to this error? What is *this* error? > by the way, this bug report was very hard to find, Depends on the search term. But you're right if you've searched for the error text as whole string. One "the" is missing in the summary - corrected now. > I'm proposing that the Alert message be fixed so that when the error is > encountered details that will help solve the problem are recorded, a link to > the files is provided in the alert message, perhaps along with a web link to > post the files. We don't continuously log the traffic, but that's what is needed. And I also can't write a new alert message since I don't know what lead to the problem. > please follow the link provided in my earlier post. I did yesterday. But I only saw users with NS 7.0 or 7.1, noone who had the problem with a build including this builds patch. Did you self experience the problem? I'll try today to simulate some possible causes again. But I really can't guarantee anything.

Maybe I'm unimaginative regarding the situations that can emerge. All I can say that I did quite extensive tests now and was unable to willingly create the subjects error message with any test input. Again, I need either some ideas how the data stream can be composed or any real data leading to this problem.

> What is *this* error? I started TB to check my mail, I received an alert as in the title of this bug, and was unable to download. I have tried cleaning out the server with outlook, and restarting TB, occasionally it will launch with out immediately hitting the error, but as soon as there is mail on the server it will show the message again. Also a symptom was that I could not view any of the messages already in the effected account. However I can read and download messages to a different account still. As of this moment TB is still locked up. > Depends on the search term. But you're right if you've searched for the error > text as whole string. One "the" is missing in the summary - corrected now. If I type in “Unable to write the email to the mailbox” on the Query page in bugzilla, I get no bug listing. If I narrow the search to ThunderBird I also get no listing. In fact I still can find now combination of search terms that brings up this bug. But this is an issue with bugzilla not thunderbird, so I don’t really care. But I think you might find a lot more hits on this bug if people could find it. Perhaps it will start showing up in google now. > We don't continuously log the traffic, but that's what is needed. And > I also can't write a new alert message since I don't know what lead > to the problem. Well that is a problem then. I would say that unobfuscating the code that leads to any call of this alert message would be a good place to start. Is there a read buffer? Perhaps that can be dumped into a text file (that can be checked by the user for sensitive information) and sent to bugzilla. If you can’t write the text file because of space our permissions then that would go a log way to confirming the alert is valid. > please follow the link provided in my earlier post. > I did yesterday. But I only saw users with NS 7.0 or 7.1, no one who > had the problem with a build including this builds patch. Interesting. > Did you self experience the problem? Yes. > I'll try today to simulate some possible causes again. But I really > can't guarantee anything. Thanks for the help, but it’s your software project, not mine, I don’t need a guarantee I’ve already moved back to outlook. Two hours is too long for a typical user to get a broken piece of software to work, two years is right out (sorry couldn’t resist). In any case if there is any additional information that I can provide I would be happy to if you give me instructions.

> I started TB to check my mail, I received an alert as in the title of this > bug, and was unable to download. [...] but as soon as there is mail on the > server it will show the message again. Hm, do you think (from when it happens or/and what the status line shows) it happens right when asking the server whether there are messages, or not before actually downloading a message? Or the other way, did it ever survive at least downloading one message before error? > Also a symptom was that I could not view any of the messages already in the > effected account. Once you received the error in the same session? Or even if you're trying to read local mails directly after startup? I'm not good if it comes to the whole database in the back. But if you can't access already downloaded messages without you've tried to retriev messages, it must be a deeper problem. > If I type in “Unable to write the email to the mailbox” on the Query page in > bugzilla, I get no bug listing. http://bugzilla.mozilla.org/query.cgi or http://bugzilla.mozilla.org ? The later doesn't search for closed bugs and in the former you've to choose the right status from the list or better remove any selection. > I would say that unobfuscating the code that leads to any call of this alert > message would be a good place to start. Is there a read buffer? There is a read buffer (one in the necko and one linebuffer in the protocol handler). But when encountering the problem this buffer doesn't hold the problematic line anymore. At least that was the case for the cause of the problem fixed by my patch (and it really fixed *that* cause). > Thanks for the help, but it’s your software project Ha, really not much more than yours. I'm just Joe Everybody who stumbled in last year. > Two hours is too long for a typical user to get a broken piece of software to > work, Yes, I agree. But the problem is mostly that the guys with the problems aren't the coders and vice versa. So without help from the users I can't help too. Maybe it's my insufficiency but I can't see any real coder paying attention. > In any case if there is any additional information that I can provide I would > be happy to if you give me instructions. If you could reanimate TB and still experience the problem, that could be of really big help. Without this only the questions in my first paragraph are left.

>Hm, do you think (from when it happens or/and what the status line shows) it >happens right when asking the server whether there are messages, or not before >actually downloading a message? Or the other way, did it ever survive at least >downloading one message before error? In general this software has worked, downloading mail normally for two weeks on the account in question. When the alert appears I have "Connect: Host contacted, sending login information..." in the status line. If I hit "OK", then try to read any of the messages in the inbox the "delete" and "junk" icons become active, but the message window does not change from "Welcome to Mozilla Thunderbird!". If I then go to an inbox for a different account, downloads and work normally, and I can read any message... > Once you received the error in the same session? Or even if you're trying to > read local mails directly after startup? The alert appears directly after startup, but I was able to create a session that didn't have the error, by downloading all my mail in outlook first, before downloading I still am not able to see the body of any message in that account. > I'm not good if it comes to the whole database in the back. But if you can't > access already downloaded messages without you've tried to retriev messages, > it must be a deeper problem. Perhaps this is the case. > http://bugzilla.mozilla.org/query.cgi or http://bugzilla.mozilla.org ? The > later doesn't search for closed bugs and in the former you've to choose the > right status from the list or better remove any selection. One has to know the status to find a bug? Does that strike anyone else as just silly? Apparently you need to know a great deal about how the bug you are searching for to find it. Perhaps because the bug is classified as MailNews not TB. Perhaps I should resubmit the bug under TB, since bugzilla thinks they are so different. Here is the URL that my search generates and returns no result: http://bugzilla.mozilla.org/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=Unable+to+write+the+email+to+the+mailbox&product=Thunderbird&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=---&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= > There is a read buffer (one in the necko and one linebuffer in the protocol > handler). But when encountering the problem this buffer doesn't hold the > problematic line anymore. At least that was the case for the cause of the > problem fixed by my patch (and it really fixed *that* cause). And yet some other part of the code calls this Alert. Finding out what part that is could be useful. > Yes, I agree. But the problem is mostly that the guys with the problems aren't > the coders and vice versa. So without help from the users I can't help too. > Maybe it's my insufficiency but I can't see any real coder paying attention. This is why I'm suggesting better fault logging, and tolerance. Parsers that have been around for 20-30 years have enough fault tolerance to recover from most syntax errors. Not that the parser is the problem in this case, but does TB use a parser generator such as flex/bison or pccts? > If you could reanimate TB and still experience the problem, that could be of > really big help. Without this only the questions in my first paragraph are > left. Reanimate?

> One has to know the status to find a bug? Does that strike anyone else as > just silly? For the advanced search (query.cgi) it's good to have the choice and IMHO the default is ok too. But for the standard search on the Bugzilla main page I always had the opinion that it's bad to not search closed bugs. I guess this behaviour is the cause for not few dupes. > Apparently you need to know a great deal about how the bug you are > searching for to find it. In general no. Besides the limitation to closed bugs the standard search is done for substrings in for different fields and all combined by Or. So you don't even know the full word to search or the exact phrase. The drawback are many results if you use silly strings. > Perhaps because the bug is classified as MailNews not TB. Yep, one shouldn't file a bug with Product TB unless it's very likely a TB only bug. Since TB and Mozilla Mail share most of the code, this is seldom the case. And for searching one shouldn't use only TB, either no Product selected or at least Thunderbird and MailNews. Also Status and Resolution should not be selected unless you know what you're doing. > And yet some other part of the code calls this Alert. Finding out what part > that is could be useful. Oh, this isn't difficult to find out and I already did: http://lxr.mozilla.org/seamonkey/search?string=POP3_MESSAGE_WRITE_ERROR Most of them should (as far as I can see) only be triggered by direct write errors caused only by the things mentioned in the alert. I'm currently suspect the both in 1763&1766. But although if I knew which of them is called, I wouldn't directly know why. There are functions that call functions that call func... And from any of them the response code that triggers the error can bubble up. > Not that the parser is the problem in this case, but does TB use a parser generator > such as flex/bison or pccts? I nearly don't know anything about them. But no, no parser generator is used. The problem (again at least for the one patched and for the existing I know of but not triggering that error) isn't the parsing or that the protocol handler couldn't be made tolerant. But each tolerance (e.g. not only accepting CRLF.CRLF as message terminator) creates another problem that could or does cause vulnerabilities. > Reanimate? You wrote you went back to Outlook. Didn't you remove TB? With reanimate I meant reinstall and use it again (at least for a few runs to generate logs).

> I nearly don't know anything about them. But no, no parser generator > is used. The problem (again at least for the one patched and for the > existing I know of but not triggering that error) isn't the parsing > or that the protocol handler couldn't be made tolerant. But each > tolerance (e.g. not only accepting CRLF.CRLF as message terminator) > creates another problem that could or does cause vulnerabilities. Perhaps, but other mail readers have this behavior, and mail servers don’t enforce it, so if it is a danger it is beyond the scope of TB. Parser generators provide a concise location where all parsing related issues are addressed. Vulnerabilities/Errors in the grammar are easy to find, and the resulting parser has consistent string usage, so you don’t risk the random programmer introducing buffer overflows. Also, parser generators produce lexers that are almost definitely faster then one could hand code. And general rules can be applied to unhandled parsing events, such as simply consuming unexpected input to a point were valid input is received (as happens with a syntax error in a compiler), or shunting it to a log etc. In general parser generators are very cool, and I recommend you check them out just for the fun of it. > You wrote you went back to Outlook. Didn't you remove TB? > With reanimate I meant reinstall and use it again (at least for a few > runs to generate logs). I reinstalled it (7.1), and get the same error. Not sure how to create logs, but it’s clear to me that this bug can not be declared fixed. If there is something I can do to generate more information tell me, but I strongly urge you to reopen this bug. Thanks, j

And the Bug strikes again. I am running XP Pro, Thunderbird 0.7.2(20040707)after a friend recommended it to me. Well just as I was starting to love it... No more email capability. I am amazed that this problem after this long is still an issue, is there a way to REOPEN this case and change the FIXED status? Also I am hesitant to try and delete any of my inbox or sent folders (or delete offending email from server) in order to fix this since they may contain valuble info for a more knowledgable CODER as to what REALLY is causing this problem.... If there is anyone who can help me retrieve any info, log, or email that caused Thunderbird to generate the message "Unable to write the email to the mailbox. Make sure the file system allows you write priveleges, and you have enough disk space to copy the mailbox." please contact me - Dave at dvd021@rogers.com .... If there isn't anything that would be helpful in my emails... can someone walk me through the PROPER FIX for this problem because it is not that clear in this bug report nor is it vlear in the linked forums.... so why does it say that the bug is FIXED... perhaps it is if you are an above average computer user but for the casual user that is getting turned on to alternative software.... only for them to recieve an error message so misleading.... this is very disapointing....REOPEN the BUG PLEASE!!!

Dave, you could try generating a pop3 protocol log http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop and attaching it or e-mailing it to me or Christian to see if anything stands out there. One other possibility is to change your pop3 account server settings to just fetch headers only, and see if you still get the error. If you do not, you can probably find the message that's causing the problem and delete it, though it might involve a bit of trial and error. Do you leave your pop3 messages on the server? I believe the header only download feature is in 0.7, but if not, it's in the nightly builds...

I'm trying to recreate this problem, so that I can show my ISP the issue- how can I send this offending email to myself?

Message | Edit Message as New, then change the To: address. But there's no guarantee that that will cause the problem to occur, since I suspect the mail delivery agent has to do bad things to get the server confused, and Mozilla probably won't do those things.

Newbie here- Just registered to post that I have a client running mozilla 1.7.3 on MAC OS X 10.3.5. He recently began getting the "Unable to write..." errors. On his old mac running netscape 4.7 on OS 9.2 checking the same email account he does not get the error. So he sends email from OSx and checks it on a mac running OS9. Same mailserver, same account, old netscape works fine. I've read everything I can find but there seems to be no real fix. I have to agree with Joshua in #80 that this appears to be a real show-stopper. I'm going to try to do the POP3 protocol log and email it to (someone??) here. Any other suggestions are appreciated. - Keep up the great work. (In reply to comment #93) > Dave, you could try generating a pop3 protocol log > > http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop > > and attaching it or e-mailing it to me or Christian to see if anything stands > out there. > > One other possibility is to change your pop3 account server settings to just > fetch headers only, and see if you still get the error. If you do not, you can > probably find the message that's causing the problem and delete it, though it > might involve a bit of trial and error. Do you leave your pop3 messages on the > server? I believe the header only download feature is in 0.7, but if not, it's > in the nightly builds...

I have an instance of this bug. So far as I can tell the problem is not fixed. It is claimed to have been fixed by ch.ey@gmx.net on 2004-03-12, but is subsequently seen again at 2004-07-19 in Thunderbird 0.7.2(20040707) One of the earliest comments was 'Unless it starts happening frequently it is probably pretty low priority.' No - it's not a low priority - it's a bug that's probably fairly trivial to fix. - there's a BIG difference. Any user of less than developer-level who gets a mail that causes the problem will never be able to retrieve any more mails - potentially critical to their life/business, will end up using another client, dump the Mozilla client and badmouth it forever. Since I got this I can no longer recommend my customers to install a Mozilla mail client. A bug which is easy to fix and causes users to quit using the product is critical & high priority. This bug was first seen in September 2002, more than 2 years ago, it has been claimed to have been fixed 3 times. I've no experience with the Moz. development environment, but I'm prepared to have a shot at this problem, if I can get some guidance where to look

(In reply to comment #97) > A bug which is easy to fix and causes users to quit using the product is > critical & high priority. How can you state it's easy to fix? Well, maybe it's easy to fix *if* the problem is reproducible and located. But as long as you don't know for sure please don't say it is. > I've no experience with the Moz. development environment, but I'm prepared to > have a shot at this problem, if I can get some guidance where to look If I'd know where to look, I'd do it. See my comment #90 for how to see where the error is called. Executing Mozilla in debugger and backtrace from the point the error is issued should work. I'd to it mayself but can't since I don't have access to mails/a mail account that triggers the problem.

I'm getting this same error message with Thuderbird v0.9 and I have over 3 gigs of free disk space. This is a show stopper; please re-open it.

(In reply to comment #98) > (In reply to comment #97) > > > A bug which is easy to fix and causes users to quit using the product is > > critical & high priority. > > How can you state it's easy to fix? Well, maybe it's easy to fix *if* the > problem is reproducible and located. But as long as you don't know for sure > please don't say it is. Fair comment. I can't - and I hadn't read the thread properly <:-( Nevertheless it IS critical and it IS 2 years old and apparently still not fixed judging by #99, and a parsing problem doesn't have to stop mail collection. That's what I'm really saying. If there's a problem with a particular mail then after a suitable wait (of need be) just mark it as bad in the 'read mails' list, put up a message and get the next. If the bug's not fixed it's status should be correctly marked - this one's obviously not fixed till no more reports for a few months. - or we believe in the parser. I've read the thread now. Thanks to Christian for all your work which has obviously reduced the incidence. It's a tricky problem handling reponses from non-conforming servers, so it may not be trivial to fix the parsing - on the other hand there are things that can be done. Two immediate areas to alleviate the problem. 1/ Ensuring that no matter what the server says the mail client goes on collecting mails 2/ Improved logging. Specifically putting the bad mail id in the message would allow mails to be retrieved from the server in question for testing - or deleted from a telnet session for that matter. I think the suggestions about parser generators are a very good idea - but I know zip about them myself - anyone feel like trying ?

Reopening because of many requests to do it. But this won't change anything unless someone comes up with a new idea or a testaccount (I asked users experiencing the issue before but without success).

(In reply to comment #101) > or a testaccount (I asked users experiencing the issue before but without > success). Or at least a log (see comment #93) so I can maybe see at which stage the program stops.

I'm afraid I wasn't able to figure out which email was causing my problem. I ended up installing the Eudora Lite mailreader and it had no problems downloading the email. It is a pop account and I forgot to check the "Leave mail on server" checkbox, so all the mail got pulled out of the account. I thought this might fix the problem with ThunderBird not being able to pull mail from the account, but I still get the same error message every time I start TB, so perhaps the problem is with one of the emails that TB already downloaded. Also, a further thing I noticed is that no matter which email in my email box I click on (the emails that had been previously downloaded), the same (different) email message is displayed in the lower panel. It's almost like TB is "stuck" on this email message but this was an email message I downloaded over a month ago. I tried searching for it so I could delete it but it doesn't seem to be in my box anymore. I'm beginning to think my TB email file or index or something is corrupt (I don't know how TB stores emails).

Ok so maybe we can improve the logging. What about making the retrieval more robust after encountering the problem I looked at the discussion of when DELE gets sent & acted on, but some of it went over my head. - Sounded like this should have solved the problem. Can't work out the logic now, but it seems to depend on : Whether we are deleting mails after retrieval Whether we issue a QUIT Whether the mail is in popstate.dat - which I take it is the record of which mails we have already retrieved. I guess that the functionality we want is : If we find a bad mail we want to do our best to get it, and then never to try to retrieve it again - so that it might take a restart, but then we should be back to fetching emails - which is what this is all about after all.

(In reply to comment #104) > Ok so maybe we can improve the logging. > What about making the retrieval more robust after encountering the problem > I looked at the discussion of when DELE gets sent & acted on, but some of it > went over my head. This is all good and ok. But I think the discussion about making retrieval more robust and when writing/issuing something should go to bug 263142. Seperating issues and different things to do into different bugs is necessary in order to keep bugs and discussions concisely. So this bug should only be about fixing a parsing bug in Mozilla and don't throwing wrong errors. I really think this can be done within few days if we've a reproducible case.

In my case, I am fairly well convinced now that the reason I am seeing the error message ""Unable to write the email to the mailbox. Make sure the file system allows you write priveleges, and you have enough disk space to copy the mailbox" is because my Inbox mbox file is 2.1 gigs in size. If I move the Inbox file aside, TB starts and runs fine. But if I put the Inbox file back, I get the error message. I tried deleting half of my emails and compressing the folder from within TB but the operation seems to fail with no error message given; the file size just does not decrease. I have also tried removing the Inbox.msf file but that has also had no effect.

darn, I fixed it so we could handle folders up to 4GB. That sounds like it has regressed.

It might be nice to try to warn the user when his mailbox is approaching the file size limit, and tell him to try compacting the mailbox. I have been using TB for a many months and I didn't know compacting the mailbox was even an option. Maybe TB could automatically compact the mailbox periodically too?

(In reply to comment #108) > Maybe TB could automatically compact the mailbox periodically too? There is an option for this under Tools/Options/Advanced/Offline Settings/Disk Space.

I'm being hit by this showstopper on Thunderbird version 0.9 (20041103) and Windows 98. I've checked all the permissions, have plenty of disk space, and tried to create a log but it came up empty. So far, the tests I've done show the following: If there are zero or one mails, it works properly. If there are more than one, I get the alert several times in a row. Doesn't matter what the other mails are. Any help would be appreciated.

I was incorrect in my last comment. It's now failing on a single message that I sent myself. It seems to download the header, display the subject, but nothing will appear in the body window.

I've lost email access three times this week because of people sending me badly formed spam. I can't be the only person suffering this. This bug was opened eight months ago and is marked as "critical". What's going on?

My bad, make that "this bug was opened in 2002 and is marked as critical"...

If you're writing what all write, I'll write what I always write: Create a usefull log and attach it here. And since it looks you know what mail is causing the problem, it could be usefull to also attach it here.

(In reply to comment #110) > I'm being hit by this showstopper on Thunderbird version 0.9 (20041103) and > Windows 98. I've checked all the permissions, have plenty of disk space, and > tried to create a log but it came up empty. If you looked at http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#protocol and did set NSPR_LOG_MODULES=protocol:5 set NSPR_LOG_FILE=%TEMP%\log.txt then the log will come up empty. Replace protocol with "POP3"

Thunderbird version 0.6+ (20041115) pop3 re: above 2 attachments, sorry this isn't a reduced test case. Note: 1. the log represents *2* attempts at downloading the mail message. 2. attachment 169919 [details] is not an *exact* replica of the offending message - I was only able to get the message after first forwarding it to another mail account. Turning on "download headers only" eliminates the error message. Christian, contact me offline for access to a test account.

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

Three interesting posts: http://forums.mozillazine.org/viewtopic.php?p=1112266#1112266 http://forums.mozillazine.org/viewtopic.php?p=1115144#1115144 and next one

(In reply to comment #120) > Three interesting posts: They're about files over 2GB in size or their mailbox resp. folder is write protected. In comment #106 John reported the size problem too. So those threads don't say something new, but confirm that this causes aren't that seldom.

But I guess that "file over 2Gb" and "file is write protected" and "received message is malformed as sent mostly by MAILER-DAEMON@yahoo.*" (see attachments to bug 252697) probably ought to be 3 different bugs (and possibly five 3 different error messages and not the same generic one). [yes I'm sure I've got write access to the files and they are way smaller than 2Gb, no anvitirus at all, and the only messages that gave me problems are from yahoo.*]

Using Windows 2000. This problem began @ 2 weeks ago and has increased in frequency. I have created new mail accounts (I have three). The "Admin...Disk Space" error continues to appear after mail server authentication and the messages begin to download. With my Web Mail via my ISP home page, there is no problem. Suggestions for obtaining my mail using T'bird? White Elk

Chris, I'm using tbird 1.0, and, as I'm sure you're aware, the bug still occurs. I use a Maildir style server, and have a growing corpus of emails which can cause the bug. I would be more than happy to give you a pop3 account for your debug. Reply privately. Cheers

Ok, thanks to Brent's account I'm now able to reproduce a problem leading to the error message (can't say for sure that's the only bug) on Windows but not on Linux. The bad input is the following line: ..\r\r\n This is extracted as one line by ReadNextLine(), "\r\n" is stripped off and the rest is handed to nsMsgLineBuffer::BufferInput(). So far it's treated as a normal line. Then BufferInput() is called as BufferInput(MSG_LINEBREAK, MSG_LINEBREAK_LEN) where the following code detects something unwanted (see the comment). if (m_bufferPos > 0 && m_buffer && m_buffer[m_bufferPos - 1] == nsCRT::CR && net_buffer_size > 0 && net_buffer[0] != nsCRT::LF) { /* The last buffer ended with a CR. The new buffer does not start with a LF. This old buffer should be shipped out and discarded. */ Normally the MSG_LINEBREAK is tacked onto the buffer from the prior call (here "..\r") and handed over to HandleLine(), but now the buffer is first handed over to HandleLine() and then the separate "\r\n" afterwards. And here in HandleLine() our line content runs into if (line[0] == '.' && line_length == 1 + MSG_LINEBREAK_LEN) which is true (MSG_LINEBREAK_LEN is 2 since MSG_LINEBREAK is \r\n). Since we've already read more bytes than the server reported as available, the dot is seen as message terminator and m_pop3ConData->msg_closure set to 0. In the first patch I've done some work to prevent calling BufferInput() by preventing calls to HandleLine() from RetrResponse() if m_pop3ConData->msg_closure == 0. But in this situation there's another call to HandleLine() waiting inside of BufferInput(): the single "\r\n" normally tacked onto the line. And since calling that routine after msg_closure is unset creates the error message, we get it. This bug is triggered by single line containing three bytes where the first position is a dot and the last a \r followed by a \r\n, i.e. ".*\r\r\n". It's not by ".*\r\n", ".*\n\r\n", ".*\r\r\r\n" or others. And it's only triggered on Windows and MacOS since only there the manually called BufferInput(MSG_LINEBREAK, MSG_LINEBREAK_LEN) doesn't start with \n so the above if is true. The third condition for triggering the bug is that the server must have reported fewer bytes for the message than it actually contains. So what to do? I made it work by extending the if for termination byte detection to that: if (line[0] == '.' && line_length == 1 + MSG_LINEBREAK_LEN && (line[1] == nsCRT::CR || line[1] == nsCRT::LF)) But I must say that a line like ".\r\r\r\n" would still cause a problem. So I think best would be to prevent shipping out the old buffer separately from the new. So we wouldn't first create a problem to work around it afterwards. BUT that might create other problems since BufferInput() is used by several functions. Maybe David can help me here.

good work, Christian. I believe that the two news users of BufferInput shouldn't be affected, since those are used for hostinfo.dat, and the newsrc file, which should have fairly predictable line endings. But I can't really say about the mailbox parser use of it. I can't say I'm following completely what you're proposing, but could you special case this in BufferInput by adding a param to the call, or setting some state in the nsMsgLineBuffer so that it behaves as you want in the case you're concerned about, but its behaviour won't change for the old callers? Either that or just change it and then make sure that generating .msf files for mailboxes with odd combinations of line endings works...

(In reply to comment #126) > I can't say I'm following completely what you're proposing, but could you > special case this in BufferInput by adding a param to the call, Yes, that was one on my ideas. The other is replacing the two calls to BufferInput() in RetrResponse() by one direct call of nsPop3Protocol::HandleLine(). That would also save the round trip through a lot of (in this case) unnecessary code. The problem here is how to get the MSG_LINEBREAK at the end of line. nsNNTPProtocol::DisplayArticle() does it that way char *line = m_lineStreamBuffer->ReadNextLine(...); ... mDisplayOutputStream->Write(line, PL_strlen(line), &count); mDisplayOutputStream->Write(MSG_LINEBREAK, PL_strlen(MSG_LINEBREAK), &count); Unfortunately the analogue m_nsIPop3Sink->IncorporateWrite(line, line_length); m_nsIPop3Sink->IncorporateWrite(MSG_LINEBREAK, MSG_LINEBREAK_LEN); doesn't work in HandleLine() because some code (I guess the one for msf) doesn't get the header lines then though the mail itself is written ok. I'll attach a patch to show what I mean.

I's just a draft but works here well. The nsCAutoString isn't really nice but surely better (nicer and faster) than everything GrowBuffer/BufferInput/ConvertAndSendBuffer does. But comments are welcome.

seems OK, but you can't call the var "x" :-) Actually, while looking at what to call "x", it occurred to me that this could be simpler, if I'm understanding the code correctly: + else if (line_length > 1 && line[0] == '.' && line[1] == '.' ) + x = 1; + + nsCAutoString myline(line+x); + myline.Append(MSG_LINEBREAK); + + rv = m_nsIPop3Sink->IncorporateWrite(myline.get(), myline.Length()); + else if (line_length > 1 && line[0] == '.' && line[1] == '.' ) { line++; line_length--; } rv = m_nsIPop3Sink->IncorporateWrite(line, line_length);

whoops, forgot the appending of the LINEBREAK part... would it work to add this? + rv = m_nsIPop3Sink->IncorporateWrite(MSG_LINEBREAK, MSG_LINEBREAK_LEN);

or does IncorporateWrite require a full line in one go? I guess it does. We probably should add some comments to the effect that HandleLine is getting called with a line w/o the LINEBREAK, and we're adding that... so I guess it could be: + /* Check if the line begins with the termination octet. If so and + if another termination octet follows, we step over the + first occurence of it. */ + else if (line_length > 1 && line[0] == '.' && line[1] == '.' ) + line++; + + nsCAutoString myline(line); + myline.Append(MSG_LINEBREAK); + + rv = m_nsIPop3Sink->IncorporateWrite(myline.get(), myline.Length()); it would be really nice to figure out a way to avoid copying the line. If we're no longer calling BufferInput, then is there any reason for us to be inheriting from nsMsgLineBuffer, since we're not using it anymore?

(In reply to comment #131) >+ rv = m_nsIPop3Sink->IncorporateWrite(MSG_LINEBREAK, MSG_LINEBREAK_LEN); > or does IncorporateWrite require a full line in one go? I guess it does. The above would be the nicest. But as I mentioned in comment #127, the header line won't be recognized than. > line++; Oh yes, we're just addjust our local var. > it would be really nice to figure out a way to avoid copying the line. I must admit I don't understand what nsDependentCString is so far. But sometimes I had the impression an assigned buffer wouldn't get copied. > If we're no longer calling BufferInput, then is there any reason for us to be > inheriting from nsMsgLineBuffer, since we're not using it anymore? That's true, I also thought about that. We could also remove m_ignoreCRLFs introduced in the last patch from the class.

(In reply to comment #131) > it would be really nice to figure out a way to avoid copying the line. Here's one. It's not the straight way but easy. Allocate additional characters for line break in ReadNextLine(): - char* newLine = (char*) PR_CALLOC(aNumBytesInLine+1); + char* newLine = (char*) PR_CALLOC(aNumBytesInLine+MSG_LINEBREAK_LEN+1); And then tacking the line break at line in HandleLine(): else if (line_length > 1 && line[0] == '.' && line[1] == '.' ) { line++; line_length--; } memcpy(line+line_length, MSG_LINEBREAK, MSG_LINEBREAK_LEN); rv = m_nsIPop3Sink->IncorporateWrite(line, line_length + MSG_LINEBREAK_LEN); That copies the linebreak at the end of line where we now have enough room. "Drawback" would be allocation of (laughable) 1 to 2 bytes that will be never used if ReadNextLine() is called for other purposes. But the modification could also be used to save one call to mDisplayOutputStream->Write in nsNNTPProtocol::DisplayArticle().

From bug 228649: 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: christy_888@sinagirl.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.

I had a thought - what about adding a new default parameter to ReadNextLine, PRBool addLineTerminator = PR_FALSE, Then, callers who want to have CRLF or MSG_LINEBREAK (whichever it is...) appended to the allocated buffer can tell ReadNextLine to do it, and then maybe we can avoid some of the hoops we have to jump through...on the surface, that seems cleaner than making ReadNextLine add room to the allocated buffer for a CRLF - that's a strange contract.

(In reply to comment #135) > I had a thought - what about adding a new default parameter to ReadNextLine, > PRBool addLineTerminator = PR_FALSE While HandleLine() would be a bit nicer for me when receiving line without linebreak, your way is admittedly the cleaner one. The new patch implements that and also includes the mentioned changes to nsNNTPProtocol.cpp.

Comment on attachment 173178 [details] [diff] [review] patch v3 this looks good; thx for doing it. A couple nits: PRInt32 nsPop3Protocol::HandleLine(char *line, PRUint32 line_length) { - nsresult rv; + nsresult rv = 0; should be rv = NS_OK, I think. Should HandleLine return an nsresult? We should be consistent in any case (I know this problem existed before your patch but let's clean it up while we're in here...) also, memcpy(newLine, startOfLine, aNumBytesInLine); // copy the string into the new line buffer + if (addLineTerminator) { + memcpy(newLine + aNumBytesInLine, MSG_LINEBREAK, MSG_LINEBREAK_LEN); need to use non K&R braces style.

(In reply to comment #137) I fixed the other remarks > Should HandleLine return an nsresult? We should be consistent in any case (I > know this problem existed before your patch but let's clean it up while we're > in here...) Before it only returned 0 and -1 (Error()). I can modify the current path by rv = m_nsIPop3Sink->IncorporateWrite(line, line_length); +if(NS_FAILED(rv)) + return -1; -return rv; +return 0; Or what's your point.

my point is just that HandleLine is declared to return a PRInt32, but it returns an nsresult, since rv is an nsresult. I know they're the same, but I just want it to be consistent...it's no big deal.

(In reply to comment #139) > my point is just that HandleLine is declared to return a PRInt32, but it > returns an nsresult, since rv is an nsresult. I know they're the same, but I > just want it to be consistent...it's no big deal. Ah ok. So I'll declare it as nsresult and also won't return -1 in the first if - is NS_ERROR_FAILURE instead ok for you? Additionally I just realized that HandleLine() can now move from public to private and it doesn't need to be virtual since nsPop3Protocol doesn't inherit from nsMsgLineBuffer anymore.

how about NS_ERROR_NULL_POINTER?

Patch addressing comments #138 to #140.

Comment on attachment 173221 [details] [diff] [review] patch v4 looks good, thx a lot. one last nit: rv = m_nsIPop3Sink->IncorporateWrite(line, line_length); - if(NS_FAILED(rv)) - return(Error(POP3_MESSAGE_WRITE_ERROR)); - return 0; + return rv; this can just be return m_nsIPop3Sink->IncorporateWrite...

(In reply to comment #143) > this can just be return m_nsIPop3Sink->IncorporateWrite... Of course - done. Who wants to do the review?

Comment on attachment 173221 [details] [diff] [review] patch v4 Scott should have some cycles now. If not, then we can try Neil.

fix checked in, thx Christian!

For me this problem seems to have started right after the checkin. I do not see this error with Seamonkey 20050201 and earlier but with every build after this date. I run into this problem every time I want to receive more than one mail. Mozilla fetches one mail and shows the error box. Afterwards I can retrieve one mail after the other by clicking OK and starting "get new messages" for each single mail again. BTW: I guess bug 274126 is a dupe of this one.

this was checked in on 02/04 so only builds from 02/05 would show any regressions from the checkin. What build did this start happening to you?

Oops... Sorry, I messed up patch creation and checkin... I checked this once again with some older trunk builds. The bug occured the first time for me with build 2005020204 (WinXP). Build 2005020108 is still okay.

(In reply to comment #149) > Oops... Sorry, I messed up patch creation and checkin... > I checked this once again with some older trunk builds. The bug occured the > first time for me with build 2005020204 (WinXP). Build 2005020108 is still > okay. I'm sorry about that. Besides my tests with my the developement Mozilla, I just did one with nightly 20040205 on Win2K. I had no problems, neither with my inbox (42 messages) nor Brent's mailbox full with 12 buggy messages. I've absolutely no idea what now *creates* that problem. So I can only ask for a) a Mozilla log and b) a windump/ethereal log.

Sven mailed me the logs. And really, Mozilla enters POP3_ERROR_DONE when receiving the first bytes of the second message. SEND: RETR 2 Entering NET_ProcessPop3 17 POP3: Entering state: 3 RECV: +OK 1187 octets POP3: Entering state: 19 Opening message stream: MSG_IncorporateBegin Done opening message stream! POP3: Entering state: 24 POP3: Entering state: 25 But I can't say why. I also retrieved the exactly same messages via my POP server script and had no problems.

David, I just discovered a flaw in my last patch. The first ReadNextLine() above the loop in RetrResponse() isn't with addLineTerminator=true. So the first line won't have a linebreak. Additionally we still increase the bytecounters by buffer_size+2 though buffer_size now already contains those two bytes. I'd post a small addendum to the patch. Before I'd like to know if the code you added through the patch for bug 116443 return (Error((rv == NS_MSG_ERROR_COPYING_FROM_TMP_DOWNLOAD) ? POP3_TMP_DOWNLOAD_FAILED : POP3_MESSAGE_WRITE_ERROR)); to HandleLine() should also be added to the very same piece of code in nsPop3Protocol.cpp#3069. If yes, I would include that in the mentioned addendum. The flaws mentioned above *may* cause Svens problems under strange circumstances but I doubt since I did the mentioned tests with the official nightly.

Thanks for your investigations Christian. But I do not think that the problem depends on your patch as the bug appeared before the checkin.

(In reply to comment #153) > Thanks for your investigations Christian. But I do not think that the problem > depends on your patch as the bug appeared before the checkin. Oh yes, I misread your comment (while the addendum is still necessary). Looking at the protocol code again it looks rv = m_nsIPop3Sink->IncorporateBegin(uidl, m_url, flags, &m_pop3ConData->msg_closure); returns rv<0 and/or m_pop3ConData->msg_closure=false (nsPop3Protocol.cpp#2993). From that and the time the bug appeared, I guess patch for bug 116443 is the culprit. It was checked in 2005-02-01 09:29.

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

Christian this was a good hint. The problem is bug 116443 and not this one. I have tried the new pref from 116443 which seems to cause this error message. Reverting the pref to false solves my problem.

That's the addendum I wrote about in comment #152.

Comment on attachment 173658 [details] [diff] [review] patch v5 thx, Christian, looks reasonable.

Definitely fixed my sina problem, WinXP.

(In reply to comment #159) > Definitely fixed my sina problem, WinXP. Good to know. Thanks for the positive feedback.

ok, last patch checked in.

I have had to completely destroy and re-create the profile to get around this issue. I was previously using Mozilla Mail (SeaMonkey), then I installed TB1.02 with no avail. After trying the suggestions in this long-winded bug report, I finally attempted to delete the entire profile and begin again from the start. This allowed me to download the emails. I believe that it might have been a suspect email, however, deleting suspect emails, the .msf files and popstate.dat did not change the situation. I have found that the issue lies within a different file in the profile that maintains this annoying persistance. All the best nutting this one out.

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

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

It's a pity this was not fixed in the 1.0.x branch. I just ran into it in 1.0.2, which is the latest supported version available for download on mozilla.org. This means that unsuspecting folks are still downloading versions with this "showstopper". I had to grab a trunk nightly to download the mails.

Reopening for landing on 1.0.x branch.

we don't re-open to land on other branches. "Open" means the bug exists on the trunk. Use keywords or status flags or even the status whiteboard for landing on other branches.

(In reply to comment #167) > we don't re-open to land on other branches. "Open" means the bug exists on the > trunk. Use keywords or status flags or even the status whiteboard for landing on > other branches. I thought it was the other way around, with "fixed-aviary" flag, but leave it open on the trunk. That is how it seems at least. Is there a "fixed-trunk" flag I'm missing somewhere?

> Is there a "fixed-trunk" flag I'm missing somewhere? No, that's what resolved: fixed means. Fixed on the trunk.

if we want this fix, we'll need the fixes for Bug 282010, which was fallout from this change.

If we're going to take this on the stable branches we need to land early in a release cycle. Moving nomination to 1.0.6

I just got this error (Win XP SP2). I was running Thunderbird 1.0.3 and got the message: "Unable to write the email to the mailbox. Make sure the file system allows you write priveleges, and you have enough disk space to copy the mailbox." Oddly, Thunderbird under counted the number of emails for download; the server had one more email message than Thunderbird was saying it was trying to download (e.g. Thunderbird says "downloading 1 of 2775" when there were 2776 messages on the server). I immediately disabled Norton A/V scanning; no help. I upgraded to Thunderbird 1.0.6; no help. I logged into my mail server and deleted some spam; that worked! I tried to delete the spam methodically so i could determine which message was the problem, but there were just too many of them and it was taking too much time.

Thunderbird .9 through 1.06 Windows XP pro "Unable to write the email to the mailbox. Make sure the file system allows you write priveleges, and you have enough disk space to copy the mailbox." We are sstill getting this on a few high volumn accounts from groups such as yahpp, coollists, gmail groups. All of a sudden the above message appears. I have discovered a work around. I move all messages from the in box to a new folder. Then go in and look at the size of the inbox. It is still huge 2 million plus kb!! . I delete the empty inbox and create another one through renaming another box. Immediatly the new inbox starts working. I thought some others might try this workaround.

(In reply to comment #173) > Thunderbird .9 through 1.06 Windows XP pro > "Unable to write the email to the mailbox. Make sure the file system allows you > write priveleges, and you have enough disk space to copy the mailbox." > We are sstill getting this on a few high volumn accounts from groups such as > yahpp, coollists, gmail groups. All of a sudden the above message appears. I > have discovered a work around. I move all messages from the in box to a new > folder. Then go in and look at the size of the inbox. It is still huge 2 million > plus kb!! . I delete the empty inbox and create another one through renaming > another box. Immediatly the new inbox starts working. I thought some others > might try this workaround. Hi I just had the same problem mentioned above by many uses on a Mac running OSX 10.4.3 and thunderbird 1.07. Deleting mail DIDNT help - I eneded up deleting all of my mail off the server (after backing it up elsewhere) and all to no joy. What did work was the fix above - I moved all of my 2000 messages within thunderbird from the inbox to a new folder i created. Then closing thunderbird i went to where the profiles and mail are stored in osx - i looked at the file size of the inbox document and it was 2GB - knowing there was nothing in teh inbox i deleted this file. When i reopened thunderbird it had recreated the inbox for me - and presto! my mail was flowing freely again!!! cheers lachlan@ivistra.com

1.5rc1 does not have the 2GB limit, and gives you an error message when your mailbox approaches the new limit (4GB)

Quick questions - I'm running Tbird 1.7 for OSX - is this 1.5rc1? Also after moving all of my messages from the inbox (inbox should have negiligble file size I would have thought?) the inbox file in my mail directory was still enormous - deleting this file fixed the problem. Are you saying the problem was caused by my inbox reaching its capacity? because I also deleted about 500 MB of email as soon as i started recieving the error - to no avail. Cheers Lachlan (In reply to comment #175) > 1.5rc1 does not have the 2GB limit, and gives you an error message when your > mailbox approaches the new limit (4GB) >

I suspect you mean you're running 1.07, and no, that's not 1.5 - 1.07 is a security point release, based on 1.0 - 1.5 has a lot of new features, improvements, etc, along with the security fixes. You need to do a file | compact folders or context menu | compact this folder in order to get back the disk space. Because of the mailbox format we use, deleting a message doesn't reduce the size of the file until the folder is compacted. Under tools | options |advanced | offline and disk space, you can also tell thunderbird to automatically compact folders when it will save XX KB.

thanks - i understand now.

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

As a complete neophyte, I am completely baffled by (almost) the whole thread here, but I don't think it's the whole problem. I'm running Thunderbird 1.5.0.2 (20060308) on windows XP SP2 on 2 machines, home and office. Since this version has come out long after the patches discussed on this thread appeared, I imagine they have been integrated into this most recent version I can find. But I still get this message. I've been getting this error continuously for about a week now on my home machine whenever I start Thunderbird, and although I can clear all of the mail of the server and have the message go away, it seems to come back as soon as I get any new mail whatsoever (including CERTA advisories), not just ill-formed spam or whatever. Also (I need to triple check this), for some strange reason, I seem to be able to download my messages onto my office machine, which never got the offending "Unable to write" message and resides on the same domain as the POP3 server even though my office machine has 3 years of archived messages in various mailboxes while my home one only has 6 months (and no folder sizezs over 1MB). I generated a log according to the suggestions in http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html which I'm attaching. After this, the message appears, I shut down thunderbird and open my web based e-mail client so I can keep working. I sure hope somebody can fix this (it looks like Christian is the most competent person for the job) since it's unbelievably demoralizing for those of us who have been converted to the Mozilla project and would like to keep with it (I came over from Eudora after Outlook and I'd love to avoid having to try to convert all of my saved Thunderbird folders into Eudora ones - I'm not desperate enough to go to Outlook yet). Please help. (In reply to comment #177) > I suspect you mean you're running 1.07, and no, that's not 1.5 - 1.07 is a > security point release, based on 1.0 - 1.5 has a lot of new features, > improvements, etc, along with the security fixes. > > You need to do a file | compact folders or context menu | compact this folder > in order to get back the disk space. Because of the mailbox format we use, > deleting a message doesn't reduce the size of the file until the folder is > compacted. Under tools | options |advanced | offline and disk space, you can > also tell thunderbird to automatically compact folders when it will save XX KB. > (In reply to comment #177) > I suspect you mean you're running 1.07, and no, that's not 1.5 - 1.07 is a > security point release, based on 1.0 - 1.5 has a lot of new features, > improvements, etc, along with the security fixes. > > You need to do a file | compact folders or context menu | compact this folder > in order to get back the disk space. Because of the mailbox format we use, > deleting a message doesn't reduce the size of the file until the folder is > compacted. Under tools | options |advanced | offline and disk space, you can > also tell thunderbird to automatically compact folders when it will save XX KB. >

David, do you have any virus checkers installed, and how large is the Inbox file?

(In reply to comment #182) > David, do you have any virus checkers installed, and how large is the Inbox > file? > Actually, I just got the same problem today. I run version version 1.0.7 (20050923) for several months on a Win XP machine. After finding a first page raising this issue (back in 2002!), I compatced the mailbox, closed TB, re-open... and the same problem again! I then found this bug track. Then reading the last comment, I simply stopped my anti-virus (avast!), and was able to get all the mails from the server... I now have re-activated the anti-virus and it works fine again... Strange, but I wanted to mention, since it might help find the origin of the problem. Xavier

(In reply to comment #183) I just saw the same problem - worked around it by downloading the offending e-mail into another e-mail program to unstick Thunderbird. Bug is still alive in Thunderbird 1.07 on WinXP w/latest updates.

It doesn't help complaining about this bug in 1.0.x versions of TB. That ones based on the 1.7 branch which doesn't contain the fix. You've to switch to TB >= 1.5 to benefit from the patches posted here.

Hello, I had this problem today with Thunderbird 2.0.0.16 on Ubuntu 8.04. My profile folder is on a ntfs mount, and I never had problems before. I share my profile with Windows XP and the problem did not occur on this system. Thunderbird asked me if I wanted to ignore a message (this was spam), because it couldn't be retrieved and this was possibly a virus. This is a problem described at http://kb.mozillazine.org/Unable_to_write_the_email_to_the_mailbox (and that's how I discovered this bug). What's more, I lost trace of mail I sent from Ubuntu and I couldn't apply filters on messages because Thunderbird didn't manage to write to my mail folders. Anyway, it managed to download new messages. I fixed the problem by moving the profile folder on my linux mount and moving it back to the ntfs mount. I hope this could help...

Using Thunderbird 3.1.7 (latest)on Windows 98 SE w/earthlink POP ISP email working just fine. but, for unknown reasons, computer was slow so I did a hard shutdown (power off and on) while email open. Restarted computer. re-opened Thunderbird. Tried to download new email and got the "unable to write the email to the inbox" error. Tried to fix by compacting inbox, repairing inbox, compacting all folders, by creating a new folder and replacing inbox' contents with it (i.e. the "Real Fix" from http://kb.mozillazine.org/Compacting_folders) all failed. tried to download the email to earthlink webmail then delete it from webmail then retry downloading future new messages from thunderbird. still no success. downloaded email to thunderbird on other computer, that worked, so ruled out ISP issue. but tried again on computer w/the issue and and it still failed w/subject error message. Finally worked around by 1)creating a brand new profile with empty Inbox 2)copying all email folders from old profile to the new profile, including a separate folder containing messages from the corrupted inbox 2a)also copied over address book (2 and 2a done to save all my folders from the corrupted "profile". 3)restarted thunderbird with this new profile and emails download just fine successfully, and all past inbox messages are available - I even moved them from the separate folder to the real Inbox and downloads continued to work observations: -creating and deleting and allowing a new Inbox folder to be created, even a new empty one that is left empty, does not fix the problem in all cases. In my case there must have been some other corrupted information somewhere in the profile directory that is not purged unless a whole new profile is created -copying folders from old profile to new profile works well - no messages were lost -this bug, technically, is not resolved nor fixed --may be important: when early in the process I copied my Inbox containing "10" messages to a backup folder, when the copy completed it actually said it copied "18" messages. so somehow the message counter was getting updated even though the "unable to write email to inbox" message was displaying bottom line - -this bug, technically, is not resolved nor fixed ... would like to have at least a more detailed error message explaining what is the real reason the mail was not retrievable -would like a built-in recovery procedure to avoid need to make a whole new profile

guess I have to quit thunderbird after what, 10 years? this is RIDICULOUS!!!!!!!!!! I run a small business with 20 accounts of thunerdird, as well as another 40 email accounts for virtual hosts..... THIS IS A SAD DAY TO HAVE TO QUIT THUNDERBIRD CUS OF A STUPID FAULT LIKE THIS FOLKS!!!!!!!!!!!!!!!!!!!!!!11

(In reply to yorlik from comment #190) > guess I have to quit thunderbird after what, 10 years? this is > RIDICULOUS!!!!!!!!!! > > I run a small business with 20 accounts of thunerdird, as well as another 40 > email accounts for virtual hosts..... THIS IS A SAD DAY TO HAVE TO QUIT > THUNDERBIRD CUS OF A STUPID FAULT LIKE THIS FOLKS!!!!!!!!!!!!!!!!!!!!!!11 Yorlik, I'm sorry you're having issues. We can't reproduce your problem, so we can't fix it. You haven't put any details about your configuration or problem that I can see, so it's a bit hard to help.

ok. not enough info. I think there is enough info in all the post above mine about this error. I spent hours trying to gain prevfideldges again to use thunderbird and write to my own hard drive, but since the error is not really mine, but thunderbirds, i cannot fix it without rewriting the bad thunderbird code. Each new thunderbird build has gotten slower and slower folks; you need to consider this. Earlybird is slowest, with each older version faster and faster. I have imported my thunderbird into a thunderbird offshoot called emclient and it is like 1000x faster than thunderbird wtih about all the same features. Thanks for 10 yrs but you are going off the deep end guys with adding stuff to slow it down to point of death. bye

using version 14 I'm getting this periodically as well. Shutting down and restarting doesn't solve. Usually seems to resolve itself after an hour (!) but sometimes requires reboot. Crazy. jt