To Debug User-level Filters

Steps

1. For fileinto filtering to work, check that in the imta.cnf file that the ims-ms channel is marked as follows:

   fileinto $u+$s@$d

2. Get the user level filters from the user’s LDAP entry.

   User level filters are stored in their LDAP entry under the MailSieveRuleSource attribute(s). To retrieve this with a ldapsearch command, remember they are base64 encoded so you will need to decode the output by using the -Bo switch.

   ./ldapsearch -D "cn=directory manager" -w password -b "o=alcatraz.sesta.com,o=isp" -Bo uid=test

   The imsimta test -rewrite command, described below, will also automatically decode them.

3. Verify that the user’s filters are being seen by the MTA.

   Issue the command:

   # imsimta test -rewrite -filter -debug user@sesta.com

   This should output the user’s Sieve filters that you retrieve in the previous step. If you do not see the filters, then you need to figure out why the LDAP entry isn't returning them. If the imsimta test -rewrite output shows the filters, then you know that the user’s filters are being seen by the MTA. The next step is to test the interpretation of the filters by using the imsimta test -expression command.

4. Use imsimta test -exp to debug the user's filter. The following information is required:

   1. The user's Sieve language statements from their mailSieveRuleSource attribute. See the steps above.

   2. The rfc2822 message that was supposed to trigger the filter.

   3. Description of what they expected the filter to do to the message.

5. Create a text file (example: temp.filter) containing the Sieve language statements based on the user's mailSieveRuleSource: values. Example:

   require "fileinto";
   if anyof(header :contains
   ["To","Cc","Bcc","Resent-to","Resent-cc", 
      "Resent-bcc"] "commsqa"){ 
      fileinto "QMSG";
   }

   Expected result: if commsqa is a recipient for this message, then file the message into a folder called QMSG.

6. Create a text file called test.msg that contains the contents of the rfc2822 message file supplied by user.

   You can either use a .msg file from the user's message store area, or create a text file called test_rfc2822.msg that contains the contents of the rfc2822 message file supplied by user.

7. Use the imsimta test -exp command:

   # imsimta test -exp -mm -block -input=temp.filter -message=test_rfc2822.msg

8. Examine the output.

   The last lines of the imsimta test -exp command will show the result of the Sieve interpretation. They will look like this:

   Sieve Result: [] or this: Sieve Result: [action]

   where action is the action that would be done as a result of applying the Sieve filter on this message.

   If the criteria of the filter matched, you will have some action displayed as the result. If nothing matched, then the Sieve result will be blank, and there is either a logic error in the Sieve filter or the .msg file doesn't contain matching information. If you get any other error, then there is a syntax error in the Sieve script file, and you need to debug it.

   For more details on the output, see imsimta test -exp Output.

9. If the filter is syntactically valid and results are correct, then the next step is to examine a tcp_local_slave.log debug log file.

   It may be that the message file you're testing and the one being sent aren't identical. The only way to see what's being received is to examine a tcp_local_slave.log file. This log will show you the exact message being sent to the MTA and how the filter is being applied to that message.

   For more information on getting a tcp_local_slave.log debug file, see the slave_debug keyword in Debugging Keywords.