Thanks.  I'm going to play with a few things here, and I'll probably give that a shot shortly.

Hi!

I'm performing a very massive transfer on an account into which new messages are also constantly arriving.  It seems I have one or more bad CNM files, but I'm not sure how to track them down.  The problem wasn't immediately apparent, and numerous copy batches have gone through and other new messages have arrived, so I can't just go in and delete the last CNM that came in to solve the issue.

Is there any way to actually determine which CNM files are bad?

Thanks! 

A zero byte one is bad for sure but I don't know of a way to easily identify one that is not zero bytes.

Thanks!  I figured that as well.  Too bad...

[quote user="Tim W Young"]

Is there any way to actually determine which CNM files are bad?

[/quote]

Can you tell us what you mean by 'bad'?

Do they have (some) headers but no other content? Are they missing parts of text? Missing attachments?

Is it not possible to pause delivery while you transfer the files?

I should say that I'm assuming there's a bad CNM file somewhere in there because there's an incredible amount of hanging and timing out when I try to do anything.  It's like Mercury is getting completely stuck.  I've used mbxmaint_ui but it doesn't find any errors.  I've heard a bad CNM file is often the cause of such behavior.

I'm a little bit confused. Mercury should not getting stuck due to a bad mail content since the opening and rendering is task of Pegasus' (or other mail client) and its HTML mail content renderer. In case Mercury getting problems it normally caused by wrong filter settings, mail loops or something like that. But we've made also the experience that Mercury (MercuryC) becomes slowlier and slowlier and finally getting stuck when the FORWARD file/function is in place and activated for too many local users which are receiving too many mails with really big attachments. That's why we deactivated this functionality and since then Mercury is running well again.

Further, when an email has been received by Mercury and dropped into the local user's mailbox, Mercury don't further care of this mail (cnm file). Why a cnm file should be influence Mercury for a longer time? Or did you receive certain mails, e.g. from certain senders, again and again that cause to that permanently Mercury problems?

I now think the problem may have to do with the number of messages in the account.  I have neither filters nor forwarding in place, and very few local users.  Once the account contains around 100000 messages (moved into it by about 5300 at a time) Thunderbird, K9, and Outlook all suddenly have trouble getting the server to respond.  The connection is there, but sometimes it's completely idle, and at other times it's just incredibly slow, or seemingly not fully working (e.g. it will download some of the headers but not the message bodies, and new mail headers will download, but only 1 per hour of historical messages will come through, and the message bodies from both new and old will have great difficulty downloading).  The total message counts also end up being very different in Outlook than TBird (by 1:5), and TBird will say it's downloading some small number like "1 of 7" when it's really downloading 5300.  Tbird also often says that the server reports that the folder is almost full based on a quota, but no quotas are set anywhere, neither within Windows, nor with Mercury (of course, since it doesn't support them).

Even though the messages are slowly, steadily added, the change in performance from everything working fine to not is very abrupt, not following the steady gradient one would expect if it were just the volume of messages alone.

Are there any possibly related limits in Mercury, specifically related to MercuryI?

I think the only solution is to put some of them in a sub-folder which then combines all the .cnm files into one file for each sub-folder created vs 1000's in the new mail or root folder.