Undeliverable messages are probably either not being dequeued from the IMTA, being saved in .HELD file because it is looping between another server or channel, or it is stuck at another server. This section describes various message queue problems.
If the IMTA stops processing messages in a queue, enter the following command as root for the queue that appears jammed:
# /opt/SUNWmail/sbin/imta run <channel name>
where <channel name> is specified in imta.cnf
If a message is not being delivered and remains in the message queue, it may be that it's not being processed by the master program for that channel. Try this:
| 1. | Check whether the path of the *_master program is correctly set in /etc/opt/SUNWmail/imta/job_controller.cnf |
|
| 2. | Check whether inetmail has the permission to run the *_master program | |
| 3. | Check whether inetmail can find all the libraries it needs to run the master program, by running |
| % ldd <master_program_name> |
| 4. | For more information, look at /var/log/syslog | |
| 5. | If you still have problems, set debug to 1 in job_controller.cnf, and run # imta restart job_controller. Resend the message and look at the newly created job_controller log file in /var/opt/SUNWmail/imta/log. |
If the IMTA detects a mail loop, that is, messages that bounce between servers/channels (this occurs because each server/channel thinks the other is responsible for delivery to an address), delivery is halted and the messages are stored in a file with the suffix .HELD in /var/opt/SUNWmail/imta/queue/<channel>. The message will be ignored by the IMTA and no further delivery will be attempted. Look at the headers in the message to determine which server/channel is bouncing the message. Fix the entry as needed and run the command:
% imta queue -retry_delivery <channel-name>