Messages not being dequeued from tcp_local channel
Hi all, i have a problem in a messaging server environment in which messages are being enqueued into the tcp_local channel but not being dequeued.
What i have is the following:
A relay/gateway server running iPlanet Messaging Server 5.2 Patch 2
A message store server running iPlanet Messaging Server 5.2 Patch 2
Both servers are using a JES Directory server
Both the relay and message store servers have been configured to communicate with each other and the directory server.
This is my problem. When an email is sent to a message server user, the message is enqueued on the relay/gateway server on the tcp_local channel but not dequeued from the tcp_local channel. Here is a snippet from the mail.log_current file showing this:
24-Aug-2006 13:11:35.98 6a55.8.13 tcp_localtcp_localE 1 s.mclean@student.curtin.edu.au rfc822;c.ashford@student.curtin.edu.au @ms-zone.curtin.edu.au:c.ashford@student.curtin.edu.au /usr/sunone/messaging/msg-gw-zone/imta/queue/tcp_local/016/ZZ0J4H00L0LL3B05.00 <3b58423b.423b3b58@student.curtin.edu.au> soms student.curtin.edu.au (ms-zone.curtin.edu.au [1.2.3.4])
24-Aug-2006 13:11:35.99 6a90.3.5 tcp_localQ 1 s.mclean@student.curtin.edu.au rfc822;c.ashford@student.curtin.edu.au @ms-zone.curtin.edu.au:c.ashford@student.curtin.edu.au /usr/sunone/messaging/msg-gw-zone/imta/queue/tcp_local/016/ZZ0J4H00L0LL3B05.00 <3b58423b.423b3b58@student.curtin.edu.au> soms Failed MX lookup; try again later
As u can see the message is enqueue but not dequeued. The message should be dequeued from tcp_local on the relay server and enqueued on the message store server on the ims-ms channel. This is what i dont get.
MX lookups shouldn't be done as the mail is for a local recipent. This problem also happens if a local user sends an email to another local user.
Any help would be greatly appreciated,
Stewart
[1920 byte] By [
salsastew] at [2007-11-26 9:42:28]
# 1
Several things come to my attention, here.
1. If this is a "new" install, why 5.2? 6.2 has been out a long time, now, and 5.2 is on the road to End Of Life.
2. Why these messages are being placed into tcp_local? Your internal ip addresses (especially your store system) should be included in the "internal_ip" table in the mappings file. That would make the channel, "tcp_intranet".
3. The error message: Failed MX lookup. Means that Messaging can't locate the server to send it to. If you don't have a MX record, you at least need it in your /etc/hosts file.
# 2
The reason for creating a 5.2 messaging environment is that we currently have a production 5.2 messaging environment that we are going to upgrade to 6.2. I've created the 5.2 environement so that we can practice upgrading it to 6.2.
In our production environment, which Sun set up, when a message is sent from one local user to another local user the message arrives from the tcp_local and is enqueued on the tcp_intranet channel. The message is then dequeued from the tcp_intranet channel on the relay/gateway server. On the message store server the same message arrives from the tcp_local channel and is enqueued on the ims-ms channel. It is then dequeued from the ims-ms channel. This is not happening on the test 5.2 environment that i've set up.
# 3
Hi,
The logs you provided indicate that the routing is occuring fine its just that your DNS setup isn't configured correctly. The error message "Failed MX lookup; try again later" means that the gateway system is attempting to do an MX lookup for the hostname "ms-zone.curtin.edu.au" and this is failing causing the message to be queued.
The _default_ behaviour for the tcp_local channel is to do an MX lookup first, and if there is no MX record, do an A record search.
What do you get when you run the following on the gateway system?
host -t mx ms-zone.curtin.edu.au
To fix this issue you have two options:
1. Fix the DNS server to report back nothing for an MX record for ms-zone.curtin.edu.au (assuming this is the issue, it may be something deeper in the resolver)
2. Create a channel and rewrite rule to avoid the MX lookup altogether e.g. (add this to the GATEWAY system):
! rewrite rule for ms-zone.curtin.edu.au
ms-zone.curtin.edu.au $U%$D@tcp_mszone-daemon
!
! tcp_mszone
tcp_mszone smtp nomx single_sys subdirs 20 pool SMTP_POOL maxjobs 7
tcp_mszone-daemon
Hope this helps,
Shane.
