Closed Bug 166111 Opened 22 years ago Closed 19 years ago

Unable to write the email to the mailbox

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Platform:
x86
Windows 95
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: scorpio, Assigned: ch.ey)

References

(Depends on 1 open bug)

Details

(Whiteboard: [sg:dos]bienvenu assessing branch risk)

Attachments

(13 files, 3 obsolete files)

Mail header
2.01 KB, text/plain
Details
Email causing that trouble on my PC
2.09 KB, text/plain
Details
Example Email that causes the problem
2.78 KB, text/plain
Details
Another example that breaks mozilla
5.08 KB, text/plain
Details
Windows Fake POP Server source code and executable to reproduce the bug and help debugging
10.66 KB, application/octet-stream
Details
patch v2
3.07 KB, patch
Bienvenu
: review+
mscott
: superreview+
Details | Diff | Splinter Review
End of debug output of first run that hangs
601 bytes, text/plain
Details
Debug output of second run
115.14 KB, application/x-zip-compressed
Details
message causing error
6.78 KB, text/plain
Details
Log for message causing error
27.23 KB, text/plain
Details
patch v4
13.30 KB, patch
mscott
: review+
Bienvenu
: superreview+
Details | Diff | Splinter Review
patch v5
2.74 KB, patch
Bienvenu
: review+
mscott
: superreview+
Details | Diff | Splinter Review
Log of failed mail receive
2.14 KB, text/plain
Details 
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.
QA Contact: gayatri → esther
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.
Attached file Mail header — 
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Severity: normal → critical
Flags: blocking1.7a?
"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...
Assignee: mscott → bienvenu
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
Flags: blocking1.7b?
Flags: blocking1.7a?
Flags: blocking1.7a-
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;
  }
Attached patch example patch (obsolete) — — Splinter Review 
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?
Attachment #141745 - Flags: review?(bienvenu)
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...
Attached patch patch v2 — — Splinter Review 
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.
Attachment #141745 - Attachment is obsolete: true
Attachment #141745 - Flags: review?(bienvenu)
Comment on attachment 142954 [details] [diff] [review]
patch v2

this looks good.
Attachment #142954 - Flags: review+
Attachment #142954 - Flags: superreview?(mscott)
Attachment #142954 - Flags: superreview?(mscott) → superreview+
fix checked in.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.
Flags: blocking1.7b?
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: bienvenu → ch.ey
Status: REOPENED → NEW
remarking fixed
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → 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.
Summary: Unable to write email to the mailbox. → Unable to write the email to the mailbox
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).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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.
Depends on: 263142
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"...
Product: MailNews → Core
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. ***
(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.
Attached patch draft of new patch (obsolete) — — Splinter Review 
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.
Attached patch patch v3 (obsolete) — — Splinter Review 
(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.
Attachment #172095 - Attachment is obsolete: true
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.
Attachment #173178 - Flags: superreview+
(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?
Attached patch patch v4 — — Splinter Review 
Patch addressing comments #138 to #140.
Attachment #173178 - Attachment is obsolete: true
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...
Attachment #173221 - Flags: superreview+
(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.
Attachment #173221 - Flags: review?(mscott)
Attachment #173221 - Flags: review?(mscott) → review+
fix checked in, thx Christian!
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
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.
Attachment #173221 - Attachment description: patvh v4 → patch v4
Attached patch patch v5 — — Splinter Review 
That's the addendum I wrote about in comment #152.
Attachment #173658 - Flags: review?(bienvenu)
Comment on attachment 173658 [details] [diff] [review]
patch v5

thx, Christian, looks reasonable.
Attachment #173658 - Flags: superreview?(mscott)
Attachment #173658 - Flags: review?(bienvenu)
Attachment #173658 - Flags: review+
Attachment #173658 - Flags: superreview?(mscott) → superreview+
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.
Flags: blocking-aviary1.0.5?
Flags: blocking-aviary1.0.4?
Reopening for landing on 1.0.x branch.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → FIXED
Flags: blocking-aviary1.0.4? → blocking1.7.9?
Flags: blocking-aviary1.1?
(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?
Whiteboard: [sg:dos]bienvenu assessing branch risk
> 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.
Depends on: 282010
Flags: blocking-aviary1.1?
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
Flags: blocking1.7.9?
Flags: blocking1.7.9-
Flags: blocking1.7.10?
Flags: blocking-aviary1.0.6?
Flags: blocking-aviary1.0.5?
Flags: blocking-aviary1.0.5-
Flags: blocking1.7.11? → blocking1.7.11-
Flags: blocking1.7.12?
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.
Flags: blocking1.7.13?
Flags: blocking1.7.13-
Flags: blocking-aviary1.0.8?
Flags: blocking-aviary1.0.8-
*** 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.
Product: Core → MailNews Core
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: