Rebuild mailbox every day!

Removed TOC file and it still wants to rebuild mailbox. Removed Eud. and Re-installed Eud, no help. Been doing this for months now.
I see these files are created; IN.MBX.001 and .002. Same thing with the TOC files. Where did they come from?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Brevity, whilst being a virtue, can be taken to extremes. Which version of Eudora, is it on Windows or Mac? I guess that you mean that you removed or renamed the .toc file, Eudora rebuilt it, but then claimed it was out of date the next time you started Eudora. Under normal operation Eudora does not "rebuild" the mailbox (but see below regarding compression). I presume you have already followed Qualcomm's advice which is:

"If you’re having trouble with your mailboxes (especially with repeated requests to rebuild a mailbox’s table of contents), quit Eudora and find the mailbox’s .toc file in the Eudora directory. Change the .toc extension to .000, then open Eudora and see if the problem persists.". (It really means "Eudora will then rebuild the .toc" - but you already know that).

Perhaps just a little more detail might help your would-be helpers.

This is the position as far as I know.
1. Eudora wishes to rebuild a .toc file when it believes that the TOC is not in sync with the MBX of the same file. I do not know all of the techniques used to discover this, but at least one is the time/datestamp of the files. Assuming for one moment that you are using version 6.1 of Eudora, here is an excerpt from page 438 of the Eudora 6.1 manual (Copyright © 2004 by QUALCOMM Incorporated, but freely downloadable) regarding the .ini file control of the permitted leeway between the timestamps of the mbx and toc files:

"TocDateLeeway default=10 is the Number of seconds that the date on a mailbox .TOC file can be behind the .MBX file that Eudora will not flag as being out of date. Helpful for network file systems, especially Windows NT Server which seems to have problems correctly time/date stamping files.

You can set this time window wider if you wish in the .ini file. However, before running Eudora next time, compare the timestamps of the toc and mbx files and see if you can see a difference. If Eudora was the last to touch them, you should not. If it is enormous (e.g. greater then 30seconds) then you need to be seeking another application that is fiddling with the files (backup, virus scan).  Not knowing the operating system, nor the file system, I cannot tell whether or not you have access privilege problems as a result of downgrading your operating system using the latest Windows XP service pack. I suspect that there are other techniques to determine whether they are in sync based on the content of the TOC and MBX files themselves. Are you sure that there is no other application fiddling with them?

2. You asked about the .001, 002 files.   As far as I can tell they are only created when a "special", "compact mailboxes" command is issued (if you are running older Eudora or MAC Eudora your mileage may vary). This seems only to be done for in and out mailboxes and their respective TOCs. Under normal operation, Eudora seems only to extend or truncate the mbx files. The only time that they are extensively re-written is during the compaction process. Perhaps the 001 and 002 are some form of safeguard against crashes during compaction or interferance between the asynchronous receiving and sending of mails during a compaction. No mention is made of them in any Qualcomm supplied docs that I have in my hands.

Usual disclaimers apply, this information is based on experimental observation - your mileage may vary.
treanfearAuthor Commented:
I'm using Win98 2nd ed. Eudora
My IN.MBX and IN.TOC files are as much as 4 hours off on the time stamp. They don't stay sychronized very long.
I changed the delay in EUDORA.ini to 1000 and no help. Maybe If I change it to 50,000 seconds????
   Same thing with OUT and TRASH mailboxes at times.
Even installed Eudora on secondary hardisk and same problem. Maybe the EUDORA.INI file always goes to the C: drive?

I have an email problem that might be the trouble. I originally mailed the message to the wrong username and have been getting  several of these bounce messages every day about it since May, from.......

From: Mail Delivery Subsystem <>
To: <(my username)>
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
The original message was received at Wed, 5 May 2004 08:23:28 -0700
from unverified []

   ----- The following addresses had permanent fatal errors
    (expanded from: <>)
   ----- Transcript of session follows -----
mail.local: unknown name: john
550 <>... User unknown
My ISP (Lanset) says it must be a virus on someone's puter sending it. They have no way to stop them they say.

OK, well, you at least know the reason why the toc is being complained about - the question is "which application is the culprit in changing the date modified time on either inbox or toc?".
First, are you running a virus checker in the directory which Eudora keeps its mail files? If you are, please disable just that directory in the virus scanner and see if the problem persists. Maybe Eudora is not being permitted to write an updated toc file.
If you are sure that there is no other program interfering in that directory will you carry out the following test. (in all the tests below please record the "date modified" of both mbx and toc if they are different and report)
1. Change the configuration of Eudora so that it does not automatically download mail. (i.e. go to "tools", "personalities", right click on each personality, then "properties", then uncheck the box labelled "check mail" at the bottom of "Generic properties" window. Now your inbox will only be changed when YOU change it.
2. rename (or delete) in.toc without Eudora running.
3. Start Eudora, let it rebuild the toc.
4. Stop Eudora, check the "date modified"  timestamps on the .mbx and .toc files. They should be the same.
5. Leave overnight (or some time that you think will trigger the problem). Check the timestamps again. Have they changed? If so, stop and report - it isn't Eudora.
6. Run Eudora again  WITHOUT downloading mail and see if it complains about toc. Did it?
7. Close Eudora, check the date modified timestamps. Nothing should have changed.
8. Wait until you are fairly sure that there will be some mail awaiting you then run Eudora (did it complain about toc?) and do one mail download by right clicking personality, and doing "check mail".
9. Quit Eudora and re-check timestamps.

One of those should have triggered the problem. Which one, and which file did not have a "modified" timestamp at the expected time (i.e. when you did the download mail.).

You asked about the Eudora.ini file and whether it is always on the C: drive. The answer is "no", you can put the .ini file where you like by creating a shortcut and putting information on the run command line of Eudora. See the section "name and location of the .ini file" in the Eudora 6.1 user manual on which also explains how the .ini file is found.

I cannot imagine why your irritating bounced message would have any effect on your toc files. It is just another mail message after all. Your ISP could be correct that it is a virus, but it certainly is a very odd one - why bother simply fabricating a bounce message? It seems that the recipient is also on the same ISP as you. Expand headers for the bounce (press the blah blah button) and post the first few lines of the bounce here (although this is not a Eudora problem and maybe other people would be able to answer better than I).

Please report and I will try to assist further.
Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

treanfearAuthor Commented:
SANKTWO, I thank you for your helping me to find the source of my problem. You are very nice to spend your time on this.

In answer to your last post;
My virus program only checks system files on bootup unless I manually execute a scan of other folders. Of course it (AVG) always tests for viruses that come in as email attachments.

1. My mail does not automatically download. I click on the GET MAIL button to download.

2. I deleted all .TOC files with EUDORA turned off.
3. Opened Eud.
4. Closed it, and 6 of my 14 TOCs were restored with present time stamp.
The .MBX files retained time of their last activity.

The ones not restored are ones I seldom use so I suppose that's why they were not restored. These files may be days or months from being same time as their MBX file.
Opened EUD. and opened each of 14 mailboxes. Closed each one.
All TOCs were then restored with present time stamp. Their MBX timestamp does not change from last time the mailbox had a message put in it. It retains old timestamp and doesn't match rebuilt TOC date & time. If I put a message in a mailbox it gets the present time stamp on the MBX file.

 Opened Eudora when the IN mailbox was EMPTY and timestamps matched on MBX and TOC, and it still said Mailbox IN needed rebuild.
I then turned it off and the MBX timestamp was current time and TOC was 5 mins. earlier.                                                  

Regarding the daily MAILER-DAEMON bounce messages, They appear in my INBOX upon opening EUD., even before I download new mail. Box was empty when I had shut it off beforehand.
How can they possibly get into my mailbox when I don't download my mail????

Daily bounce message, since May;  Here is the header info you asked for.
Received: from (unverified []) by
 (Vircom SMTPRS 5.1.202) with SMTP id <> for
 Wed, 5 May 2004 08:24:18 -0700
Date: Wed, 5 May 2004 08:23:28 -0700
From: Mail Delivery Subsystem <>
Message-Id: <>
To: <>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)

The original message was received at Wed, 5 May 2004 08:23:28 -0700
from unverified []
Tranfear, you have an interesting problem, but I think there are some hints as to what it might be.
Let us treat the easiest problem first - your re-appearing bounce message. You are not receiving new copies of this mail, you are simply not getting rid of the first copy. The delivery date in the first "from" line gives the clue as does your comment regarding it arriving before download!
This re-appearance is a direct result of the TOC being rebuilt. When you move a mail message into trash, Eudora does NOT remove it from the original mailbox. It remembers (in the TOC file) that it has been deleted. (at least most of the time - I think that if it is the last email in the box, it might truncate the original mailbox, but I am not certain). Anyway, you are NOT receiving this bounce frequently, it is not being compacted out of the IN box and it re-appears every time the TOC is rebuilt.

I am suspicious that there is something in the IN box which is causing Eudora to wish to reconstruct the TOC (although you still say "Mailbox IN needed rebuild" - but I hope that it is only the TOC).   The fact that you complained about in.mbx.001 etc indicates that you DO "Special", then "compact mailboxes" reasonably frequently. If that is the case and you HAVE been trying to delete your irritating bounce message, then it looks like there is a problem with in.mbx causing Eudora to fail to compress deleted mail out of it and, at the same time, requiring a .toc rebuild. I have seen problems with generating .toc files if the mailboxes are HUGE, but then you would complain that thousands of messages were re-appearing, not one.

So, I want you to conduct another experiment. This time close Eudora and RENAME the file in.mbx to myoldin.mbx. You will not lose anything because a new mailbox will appear called "myoldin" and Eudora will reconstruct a new IN box the next time you start Eudora.  All deleted mail remaining in your in box will re-appear in "myoldin". Then conduct your experiments to see if the in.toc survives getting mail, shutting down Eudora etc. If it does, then the problem may well have shifted to the "myoldin" box which you will simply have to empty by dragging mails to some other mailbox and deleting myoldin.

Please report results.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
treanfearAuthor Commented:
I deleted IN.MBX and IN.TOC files.
Opened EUD. and INbox was empty. Did not do a mail download.
Closed EUD.
Looked at the IN.MBX file and that bounce message was in it!

 I know I didn't download it so it had to be coming from my hardisk somewhere.

I did a text search of the entire EUDORA folder and erased every bounce message I found. There were copies of it in TRASH.MBX, RESERVE.MBX, VIRUS.MBX, HISTORY.LST, EUDORALOG.OLD.
I again deleted IN .MBX and  .TOC.

I opened EUD. again and IN box was still empty.
I looked at the IN.MBX file and the bounce msg. was in there AGAIN!

This time I did the text search on all the sub folders of EUD. and I found the message in \EUDORA\SPOOL\12C73707.RCV.
I renamed that file and opened EUD. again. IN box was still empty and now the IN.MBX file was empty.

Now I'll wait see if that fixed it............................
Treanfear, ah, I had forgotten about the spool directory. You have done a great job of experimenting. Congratulations on finding the spool file copy of the bounce. At least you will solve THAT problem.

The spool directory is a good candidate to cause problems.  The fact that the bounce was in the IN box but you could not see it inside indicates a real problem in processing the message from the spool directory. If renaming the spool file fixes the problem it sounds like a candidate to send to Qualcomm for them to investigate as a bug in Eudora.

Normally the spool file is used to keep downloaded messages to permit the attachments to be decoded etc. until you have finished working with the mailboxes. Something seems to block it from emptying in this case.

I hope that this finally fixes your problem - sounds like it might.
treanfearAuthor Commented:
YEAH!!! Apparently all fixed.  No more problems for 2 days now.
The \SPOOL folder had two bounced messages in it that I had addressed to wrong Edresses. Bounced back by my ISP and were in text format in that folder.

Thank you very much for your helping me with this.
Treanfear, no problem, glad you are up and running with the best mail client!
However, I am still baffled as to why a bounce message in the spool directory causes this behaviour in Eudora - if you are inclined, it might be nice to post it to - no help to you, but maybe by doing that, you can help the next victim of this problem! Anyway, enjoy email with Eudora - I do.
I would recommend that to avoid this problem in the future that you set up a filter that initially transfers all email out of the In box to another box, say _in that is NOT the system IN box. Part of the problem is that for some reason, Eudora doesn't deal well with a large number of messages in the real system IN box. I've found that just by transferring them with the first filter into another non system email box, it can save a lot of grief. You can continue to run other filters, just don't put a Stop command in that first filter.

I agree Eudora is currently the best email client on the planet... perhaps some day a better one will come along.

I have certainly met people with problems caused by very large IN boxes in Eudora, but since about version 4 those with problems have had VERY large inboxes (in the gigabytes range). I do accept that it is NOT GOOD PRACTICE to keep all your mail in the IN box and that Kellycoinguy's recommendation is worth following.
It might be that  Treanfear's problem was originally caused by something such as an enormous inbox (we do not know), but eventually having a ZERO sized inbox did not solve the problem.

It seems that the problem Treanfear eventually experienced is a residual bug in Eudora. The bug is that it is possible to get something in the spool directory (by whatever original cause) which Eudora is unable to empty into the IN box, even if the IN box is completely empty  What Eudora seems to do is, when it starts up, it checks the validity of the .toc files and rebuilds them if necessary, then it tries to empty anything in the spool directory into the IN box in case it was closed down before it finished processing the last time it ran. This to avoid losing mail. However, the single message, "the bounce message" in Treanfear's spool directory, caused Eudora to transfer this message into the IN box and then to a) fail remove it from the spool directory, and b) fail to update the toc file. Thus each time Treanfear started Eudora, it a) complained about the .toc file being wrong and b) started the transfer from the spool directory again. Thus the offending mail re-appeared after each deletion leading to very confusing symptoms.

Whatever the cause of the original problem, Eudora should not fail in this way. It would be easy enough for Eudora to keep a count of how many attempts had been made to empty the spool directory and simply nuke the spool files after X attempts (or more cleverly, ask the user to send in the spool file for examination). In terms of Qualcomm actually fixing the problem that Eudora could not empty the spool directory, only Treanfear knows EXACTLY what was the state of the spool directory so it is over to Treanfear if s/he wishes to advise Qualcomm so that they can fix it.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Email Clients

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.