PureMessage for UNIX: How Delay Queue works

This article explains how the Delay Queue feature in PMX 6.4 works.

The following sections are covered:

Applies to the following Sophos products and versions

PureMessage for Unix 6.4.0 and above

This section discusses the order of operations for the Milter to sort mail and determine if a message should be delayed.

When the Milter starts

  1. It reads IP and Port information from /opt/pmx6/etc/redis_location.conf and connects to Redis server.
  2. If the Redis server is not available, it will not be able to delay any messages or log any information in the Sender History Database.
  3. You will see a log line in pmx.log for each message processed that says: Unable to connect to Sender History Database server at <ip:port>. Delay queue protection will not work. The Milter will not attempt to connect to the Redis Database until the Milter is restarted.

When the Milter receives a message

  1. If the message is inbound and the delay_status is set to Collect or On in delay.conf then the Milter will extract the First Untrusted Relay (FUR), from the message.
  2. The Milter will query the Redis server for statistics, like the number of messages and spam received from the IP of this FUR.
  3. The Milter then passes this information to the AntiSpam Engine.
  4. If there is no FUR for the message then the pmx_log will display the line, No Fur (first untrusted relay) value present! The message cannot be delayed since it is trusted.

Notes

  • You don’t need to write any test or action in policy.siv. The Milter records information for the FUR value of each message on the Redis server.
  • The private IP address from the subnet 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 are private and excluded when calculating FUR.
  • The AntiSpam Engine may suggest to delay the message. To check that, user need to add the following rule into the policy.siv:

if pmx_spam_hit :comparator “i;ascii-casemap” :matches [“DQ_SUSP_?”] {

pmx_suspect_delay;

}

PMX suspect delay action

  1. The pmx_suspect_delay action checks if the AntiSpam engine has given a verdict for delaying the message.
  2. If you have pmx_suspect_delay set without the if condition, it will work as if the if statement is present.The message must be submitted to the AntiSpam engine before the action pmx_suspect_delay is executed.
  3. The policy.siv file should be written in a way that the tests pmx_spam_hit or pmx_spam_prob before the action pmx_suspect_delay is executed. You should not use the stop action after pmx_suspect_delay because it does that internally.

pmx_suspect_delay action will not delay the message if:

  • The delay_status in delay.conf is not On
  • The message was delayed previously and if delayed this time, will exceed the maximum allowed limit as per delay_max_minutes as specified in delay.conf.
  • The message was delayed previously and is injected again by the administrator using the GUI.
  • The message was delayed previously and was injected again because the size of the delay directory has been exceeded as stated by delay_max_size located in the delay.conf file.

The pmx_suspect_delay action will park the message in the minute directory 1 to 59 at /opt/pmx6/var/qdir/delay according to the time it needs to be delayed.

The /opt/pmx6/var/qdir/delay/delay_queue_size will give you total space occupied by all the messages delayed so far and how many messages have been delayed.

Direction of re-injected messages

If the local IP address chosen to send a message to send_delayed_mail_to in the delay.conf file is a member of the list internal-hosts the mail will be considered Outbound. Otherwise, it will be considered Inbound.

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable to us to ensure that we continually strive to give our customers the best information possible.

Related:

  • No Related Posts

Leave a Reply