PC DB: Troubleshooting Mail When Messages Are Not Moving

MORE INFORMATION

Determine which direction mail is not moving. This step is critical. The MSMail for PC Networks version 3.x system uses separate postoffice mailbags to hold outbound mail destined to externally defined postoffices and a global mailbag for all inbound mail from externally defined postoffices. You will not be able to do any further troubleshooting if you cannot determine which way mail is not moving.

Below are suggestions for isolating the problem:

1. Send a message from the Admin Mail account on one postoffice to the Admin Mail account on another postoffice.
2. Verify the message is placed in the outbound queue by running ADMIN.EXE, QUEUE and selecting the network name and postoffice name of the destination postoffice.
3. Allow the EXTERNAL.EXE program to run twice.
4. Check the QUEUE to verify the status of the message. If the message is still present, mail is not moving out.
5. If the message has left the QUEUE, login to the Admin Mail account at the destination postoffice and verify the message has arrived. If it is not present, mail is not moving in. If this is the case, send a message from a different postoffice to the same admin account to confirm the analysis.

Additional troubleshooting steps once the problem has been isolated:

1. Restart the External program servicing the problem postoffices. Wait for two cycles and see if that clears up the problem. Watch the external screen for the Sending Mail message to see if this starts the mail moving.
2. At the postoffice from which mail is not moving (in or out), check the P1 subdirectory for files older than the time specified for the External program to poll the postoffices. This time setting can be verified by checking the -Nx (x in minutes) switch in the External command line string or the INTERVALREGULAR=x (x in minutes) in the EXTERNAL.INI file. If there is no entry, the default is 5 minutes.
   
   If there are messages older than the time specified, run a single instance of external against this postoffice. This will clear out any active P1 files.
   
   An alternative method of resolving the problem of stranded P1s is to move all old P1 files to a temporary directory and wait for another cycle of External. The problem with this method is that if any of the P1s are still current (there are headers associated with these P1 files in the INQUEUE3.MBG), then these messages will spawn NDRs and the mail will not be recoverable.
   
   Once mail is moving again satisfactorily it is safe to move out any old P1 files.
3. Check the MTAs user account (the account which the External computer is using to log into the postoffice with) rights on this directory. The MTA user account must have full rights to the P1 subdirectory.
4. Ensure files in the P1 subdirectory are not ownerless (Novell Servers Only).

Specific guidance if mail is not moving *out* of a specific postoffice:

1. Determine how much mail is in the outbound Queue by running ADMIN.EXE, QUEUE and selecting the network name and postoffice name of the destination postoffice.
2. Determine the oldest message in any queue. If there are messages older than today, delete or return the message(s).
3. If there are many old messages in the queue, consider returning all the mail. Send one message, verify that the message is in the queue, and run the External program to deliver the message.
   
   If the message leaves the queue, then there probably was a corrupted message in the queue. If the message does not leave the queue, then there probably is a corrupt outbound mailbag for the destination postoffice. You can reset these .KEY and .MBG files using MAILQ16.EXE that comes with the MSMail Resource Kit.
   
   You may want to contact Product Support Services for assistance and confirmation of your analysis.

Specific guidance if mail is not moving *into* a specific postoffice:

All inbound mail from externally defined postoffices (version 3.0 or later) is deposited into the INQUEUE3.KEY and INQUEUE3.MBG.

1. Determine the size of the INQUEUE3.KEY and INQUEUE3.MBG. Divide the INQUEUE3.MBG by 116. This *may* tell you the number of undelivered messages. (The most accurate way to determine the number of undelivered messages in the INQUEUE3 is to have all users logout from the postoffice, run ADMIN.EXE, Local-Admin, Storage, Compress, then divide the INQUEUE3.MBG by 116 or run MAILQ16.EXE that comes with the MSMail Resource Kit).
2. Determine the time and date stamp on INQUEUE3.KEY and INQUEUE3.MBG. If it is recent, the External program is writing to these files. If it is not recent, check the externals to make sure there is an instance accessing this postoffice. If the time is current, run a separate instance of the External program against this postoffice to determine if it can deliver messages to the recipients' mailbags. If the separate instance of External is successful in moving messages (this can be reliably verified by logging into mail as the recipient, because the size of the INQUEUE3 will not necessarily reflect a change), then the MailerDisable option may be enabled on the original external program that is servicing this postoffice.
   
   MailerDisable is disabled by default. To verify the state of this switch, look for "/MailerDisable" on the command line string or "MailerDisable" in the EXTERNAL.INI file. If this entry is present, MailerDisable is enabled.
3. If messages are still not being delivered from the INQUEUE3.MBG and INQUEUE3.KEY, reset these files. These files can be reset using the MAILQ16 utility. This utility is available with the Mail Resource Kit. Once these files are reset, send another test message. If mail transfer is successful, there was corruption in the INQUEUE3 files.
   
   In all cases of mail not moving if you are unsure of the steps to take please don't hesitate to place a support call.