Well in gest here is my problem mainly.

I have migrated from mbox format to Maildir format in the last week. I used the utility mb2md.pl to convert all of our existing emails from one system to the next. I then modified my /etc/procmailrc file by putting this at the top:
MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/

This way procmail is forced to deliver to the new format as well.

For the most part all of this is working perfectly. Procmail is delivering emails to their new proper folder and even extended rules in users own ~/.procmailrc are working well once the folder path was changed from $MAILDIR/whatever to $MAILDIR/.whatever/. Works great.

I am using Dovecot 1.0.1 to deliver our email through the IMAP protocol and with the clients we support (Thunderbird and Outlook) things are working very well for us.

So now to my problem. We also use Usermin for our users to access their email when they don't have a supported client available to them. When users look at their email with Usermin their emails are out of order regardless of weather I have Usermin's "Read Mail" module user IMAP to get mail or have it read the users Maildir directly. Sorts are just all jacked up. Soemtimes if users then click the "Date" button to sort by date it snaps to; sometimes it don't. I currently have multiple posts on the Webmin/Usermin mailing list about this problem and it really seems to point back to the naming scheme of our emails now.

All emails which were converted have the classic maildir format. UnixTime.PID.Server...
1183737827.002379.mbox:2,RS
1183737827.002388.mbox:2,RS
1183737827.002392.mbox:2,RSa
1183737827.002394.mbox:2,RS

However, all the email that is delivered after the fact is different. They all look like this:
_oTH.XqwlGB.gator:2,RS
_p2F.qjVlGB.gator:2,RS
_qQF.2mpjGB.gator:2,Sa
_sK.8mTlGB.gator:2,RSa
_uOG.gCtjGB.gator:2,RS
_uxG.a6lkGB.gator:2,RS
_vnF.n-2lGB.gator:2,
_x9H.llckGB.gator:2,
_z3G.k8klGB.gator:2,S
_z5G.kAilGB.gator:2,RS

I have been searching the net for a few hours and reading various documentation here and there and I haven't been able to find anything that tells me why my mail is being named this way or how to fix it. I can say that my test box which also runs 10.2 slamd also delivers this exact same way....

Any suggestions anyone?:>
-Smillie

I really don't know, so this is just a guess.

When I converted emails or copied email archives from one machine to another one, I sometimes forgot to take care of time and date information. Time and date is very important in email management. If, eg, the script/program you used for converting existing emails put a new timestamp on each message, this may cause trouble of the type you describe.

But I have no idea, why the sort order is defunct for new mails.

gargamel

I'm still waiting to hear back from the Usermin guys, but my main concern at this time is why are my new email names different then the standard Maildir names.

Time stamps on the mail which was converted appears to be good enough we'll say at this point. They are not the real date the email was actually sent, but they are atleast in the order which they were delivered into the original MBOXs so that should be good enough.

Well it turns out that its the package of procmail that came with Slamd 10.2 which was version 3.15.2. I DLed the latest slackbuild scripts (procmail version 3.22.5) and so forth from Slamd_Current, made the package, upgraded the package and now the new emails names are being saved properly.

I also ended up just hacking together a script to rename the currently bad named emails from their existing weird form to something more compatible using the naming scheme that the mb2md.pl script uses as a template.

I'm fix. Nevermind:> I thought about doing this when I first saw the problem, but I really hate to just update things without a good reason....
-Smillie

That was a weird bug, then:
- easy to observe, so that anyone testing it should have seen it
- strange, because there's no obvious reason to change the naming scheme
- mysterious, because nothing else seemed to be wrong

All the better, that you were able to fix it!

gargamel