How do I reinject .msg files

Question

Good afternoon:
After a slight imta config issue, one the email servers here currently is experiencing some backlog problems. I have approximately 17000 .msg files sitting in the user directories, and I am uncertain how to get those messages reinjected into their accounts.
From what I understand, the server translates the names of accounts from an old server (ie: joecool_xmail.com) to it's matching name on the new server (ie [email protected]). The imta config issue altered the translation somehow... at least from what I have been told.
Question: Is there a way to re-inject all 17000 .msg files to their appropriate user accounts? The message files are actually in the user directories (ie: /opt/sun/popmail.server.com/store/partition/primary/=user/##/##/=joecool@xmail%dcom/01/), but are not downloadable to a client or viewable in the webmail interface.
Ideas? Very green at this, so pardon if I have mis-worded things, or approached the wrong forum.
-Matt Zulawski

Answer 1

Thanks for the advice so far. Apologies about not
being able to provide valid problem descriptions.
Again, this is all very new. I'm just attempting to
assist with this hiccup while the staff member who
supports this server is out of the office.
The mass reconstruct ran through all of the
directories, but still didn't queue up the mail as I
would have hoped.We should be looking at the mail.log_current, to see what the actual goings on with incoming messages are, not guessing. . .
>
Background Info:
I know that these accounts were transitioned from an
iplanet server to the new server running the Sun
Messaging software. When the new server was brought
online, it just contained empty inboxes, but all of
them had valid names. Eventually stored messages
(around 7 days worth) were transitioned from the old
server to the new one. This injected worked just
fine, and everyone received their stored messages.
Today:
In the early afternoon (actually, this might have
been done before the weekend), the imta.cnf file was
altered so that the following was active:
! Rules to select local users
$* $U_$H@ims-ms-daemonThis rule does not appear valid.
The normal rule for JES Messaging Server looks like this:
.ims-ms-daemon $U%$H.ims-ms-daemon@ims-ms-daemon
the above is all on one line.
changing it without real reason can cause your server to stop delivering to mailboxes properly.
>
This was repaired, and our users reported that mail
was functioning again. During the time that this was
active, the server logged the following similar
alerts about 1700 times, for varying accounts of
course:
[14/Mar/2005:15:55:04 -0500] popmail
ims_master[15299]: General Notice: delivery for
[email protected]_ims-ms-daemon failed: Mailbox does
not exist
Assumptions I'm making
- the messages with the "_ims-ms-daemon" logged
errors are actually associated with .msg files in the
users directoriesunlikely to be true.
If you get an error that says, "mail was not delivered", or words to that effect, do not assume that the mail was in fact delivered. Most likely it was not. . .
The mail could have been either returned or deferred, depending on the error. If you note the mail.log_current entries for such messages, they can be reQueued or Returned, based on the letter shown.
If they were requeued, then they will be retried on server restart. If they were returned, then the sender will have to send them again.
- each .msg file counts towards the mailbox count
shown when I execute "mboxutil -l"That kind of depends. . . .
If you use a normal "fat" client, such as Mozilla to "delete" a message, you really aren't deleting anything. You're marking a file "to be deleted", and creating a copy in the trash folder.
Later, when you "compress" the folder, then the server is allowed to erase the files. You can also use the expiration subsystem to remove "to be deleted" files, otherwise they never go away.
You should examine some of the files. They're just text files, so you can see what's in 'em.
>
For instance,
/opt/sun/popmail.server.com/store/partition/primary/=u
ser/44/66/=joecool@xmail%dcom/01/ will contain the
following:
drwx------ 2 mailsrv mail 4096 Mar 14
17:53 .
drwx------ 6 mailsrv mail 4096 Mar 14
16:48 ..
-rw------- 1 mailsrv mail 4089 Mar 11
19:01 159.msg
-rw------- 1 mailsrv mail 14924 Mar 11
20:17 160.msg
-rw------- 1 mailsrv mail 91985 Mar 14
16:37 182.msg
-rw------- 1 mailsrv mail 7486 Mar 14
17:53 183.msg
About 20 messages, right? But when I execute
"mboxutil -l|grep joecool":
1 7 2005/03/14 17:53 primary no quota
quota user/[email protected]/INBOX
0 0 - - primary -
- user/[email protected]/Drafts
0 0 - - primary -
- user/[email protected]/Sent
0 0 - - primary -
- user/[email protected]/Trash
The numbers don't seem to be matching up as I'd
expect, and therefore I think I have about 1700
orphaned messages sitting in user directories.
Any other advice you could provide?Reconstruct -r will cause any messages that are valid (and not deleted) to show up. The fact that they're not appearing to mboxutil likely means that either the files are not valid message files, or that they are deleted. The server only removes such files in the overnight processing, even if the folder has been compressed (the expunge command has been given). If you see a "store.exp" file, then that will contain a list of files to be deleted.