To Collect Debug Data on a Messaging Server Routing Problem

Use this task to collect data when Messaging Server is experiencing a routing problem.

A Messaging Server routing problem is defined as the inability of the system to correctly route a message. For example, a message might be ending up in the wrong Message Store, might be sent to the wrong channel, might be delivered to the wrong user, and so on.

1. Collect the general system information as explained in To Collect Required Debug Data for Any Messaging Server Problem.

2. Provide a detailed explanation of what do you want to obtain.

3. Get the output of the following command.

   • Sun Java System Messaging Server (Messaging Server 6):

     UNIX and Linux

     cd server-root/sbin./imsimta test -rewrite -debug=level=5 mailaddress

     Windows

     cd server-root\sbinimsimta.exe test -rewrite -debug=level=5 mailaddress

   • iPlanet Messaging Server (Messaging Server 5):

     UNIX and Linux

     cd server-root/msg-identifier./imsimta test -rewrite -debug=level=5 mailaddress

     Windows

     cd server-root\msg-identifierimsimta.exe test -rewrite -debug=level=5 mailaddress

   ---

   Note –

   When the problem is about Sieve filters, add the option -filter to the above command.

   The -noimage qualifier to the imsimta test -rewrite -debug command enables you to test changes made to the configuration file prior to recompiling the new MTA configuration.

   If possible, use the -source_channel=source_channel option to specify the incoming channel. This is sometimes necessary for testing the interactions with the mapping tables and the antirelay rules. By default, Internet mail arrives on the tcp_local channel whereas internal mail arrives on the tcp_intranet channel. If the connection is authenticated, use tcp_auth.

   The command would then look like:# ./imsimta test -rewrite -debug -source_channel=tcp_intranet email-address

   ---

4. Get the LDIF entry of an impacted user.

   UNIX and Linux

   dir-root/shared/bin/ldapsearch -h hostname -p port -D "cn=Directory Manager" -w password -b "basedn" "(objectclass=*)" uid=user > /tmp/user.ldif

   Windows

   dir-root\shared\bin\ldapsearch.exe -h hostname -p port -D "cn=Directory Manager" -w password -b "basedn" "(objectclass=*)" uid=user > C:\user.ldif

   where:

   dir-root

   The directory on the Directory Server machine dedicated to holding the server program, and configuration, maintenance, and information files. The default location for UNIX and Linux versions of Messaging Server is /var/opt/mps/serverroot/.

   hostname

   Name of the host running Directory Server. The default value is localhost. You can omit -h hostname if the Directory Server is running locally.

   port

   Port number on which Directory Server is listening. The default is 389. You can omit port if the Directory Server is running on port 389.

   basedn

   The base dn for the search. Use basedn as the starting point for the search.

5. Get the LDIF entry of the domain where the impacted user resides.

   UNIX and Linux

   dir-root/shared/bin/ldapsearch -h hostname -p port -D "cn=Directory Manager" -w password -s base -b "baseDN" "(objectclass=*)" > /tmp/domain.ldif

   Windows

   dir-root\shared\bin\ldapsearch.exe -h hostname -p port -D "cn=Directory Manager" -w password -s base -b "baseDN" "(objectclass=*)" > C:\domain.ldif

   where:

   dir-root

   The directory on the Directory Server machine dedicated to holding the server program, and configuration, maintenance, and information files. The default location for UNIX and Linux versions of Messaging Server is /var/opt/mps/serverroot/.

   hostname

   Name of the host running Directory Server. You can omit -h hostname if the Directory Server is running locally.

   port

   Port number on which Directory Server is listening. The default is 389. You can omit port if the Directory Server is running on port 389.