PureMessage for UNIX: Enabling Sender Genotype for IP Blocker

  • Article ID: 112593
  • Rating:
  • 2 customers rated this article 4.5 out of 6
  • Updated: 06 Jun 2012

The IP Blocker service can be run at the mail transfer agent (MTA) level or applied as part of the PureMessage policy. Sophos recommends running the IP Blocker service at the MTA level because it is more efficient and requires substantially less resources.

Policy-based IP blocking uses a milter (mail filter) for every connection, which can become extremely resource-intensive. At the MTA level, the decision is made to drop the connection before the message reaches the milter(s). In addition, connecting MTAs are sent a URL with an explanation and possible solution when the IP Blocker service runs at the MTA level.

How do I enable Blocker?

See the following article, which explains how to enable IP blocking at the MTA level:


What is Sender Genotype?


Can I run the IP Blocker service with a third party version of Postfix?

Yes. The instructions are available here:


Configuring Sender Genotype (Dynamic IP) Blocking

There are two components of the IP Blocker service. The first component is enabled by default and contains a list of known spam IP addresses compiled by SophosLabs.

The second component is Sender Genotype. You must enable this manually. The Sender Genotype component is a list of end user and dynamic IP addresses that should not be sent "direct to MX" email. (Spammers often attempt to bypass a sending MTA, and send email directly to an MX host).

The IP Blocker service is configured in this file:


The settings related to the IP Blocker service are:

block_dynamic = __DEFAULT__
block_helo = __DEFAULT__


When enabled, PureMessage uses a list of end user and dynamic IP addresses.

Default: No

To enable Sender Genotype, use the following notation in the blocklist.conf file:

block_dynamic = Yes

block_helo (Postfix only)

When enabled, PureMessage rejects connections from mailers that use HELO/EHLO arguments that only appear in spam and may not be RFC-compliant. The associated block_dynamic option must also be set to "Yes" in order for this option to take effect.

Important: This option is available to Postfix users only.

Default: No

To enable this feature, set both options as follows in the blocklist.conf file:

block_dynamic = Yes
block_helo = Yes

Once these changes have been made, run the following commands as the "pmx" user:

  1. $ pmx-blocklist-compile
  2. $ pmx-service restart (Restarts both PureMessage and the mail transfer agent)

Note: In a multi-server deployment, you must edit blocklist.conf and run these commands on each edge server.

Excluding/Including IP addresses

There are two default IP blocking lists:

  1. IP Blocking Exception List
  2. IP Blocking Inclusions List

IP Blocking Exceptions (Whitelisting IP Blocker addresses)

You can exclude specific hostnames or IP addresses from IP blocking by including them in the IP Blocking Exception list.

  1. On the sidebar of the Policy tab, click IP Blocking Exception list.
  2. In the Add Items text box, type an IP address or fully qualified hostname.
  3. Click Add.

This list is a PureMessage resource, and changes made will be propagated to any edge servers via the "resource-sync" job in the scheduler.

IP Blocking Inclusions (Blacklisting IP Blocker addresses)

You can specify the hostnames and IP addresses that you want blocked by the IP Blocker service by adding them to the IP Blocking Inclusions list.

  1. On the sidebar of the Policy tab, click IP Blocking Inclusions list.
  2. In the Add Items text box, type an IP address or fully qualified hostname.
  3. Click Add.

Important: This list is not automatically propagated to all edge servers. You must add it to a PureMessage publication before it can be synchronized between edge servers. See "Server Groups Tab" in the PureMessage Manager Reference for instructions on adding a file to a publication.


These lists take precedence over any SophosLabs data. The IP Blocking Inclusions list, and then the IP Blocking Exception list will be honored before the original IP Blocker service data, the new Dynamic IP Blocker service data, the new Regular Expression list for Dynamic IP Blocker service data, and the HELO check.


The /opt/pmx/var/log/blocklist_log indicates the reason for rejection.

Here is an example of the blocklist_log output:

2008-06-22T03:49:03 OK reason=sophos_exception
2008-06-22T03:49:04 REJECT reason=blocklist
2008-06-22T03:49:04 REJECT reason=blocklist
2008-06-22T03:49:06 OK reason=not_found
2008-06-22T03:49:07 OK reason=not_found
2008-06-22T03:49:08 OK reason=sophos_exception
2008-06-22T03:49:09 OK reason=blocklist
2008-06-22T03:49:10 REJECT reason=blocklist
2008-06-22T03:49:10 OK reason=dynamic_sender_ip
2008-06-22T03:49:12 REJECT reason=dynamic_sender_ip

Understanding the Message Log

The following table maps the blocklist_log reason code to a SophosLabs explanation. The abbreviations in the Rejection Message Substitution column are defined in the subsequent section, "Customizing an IP Blocker Rejection Message."


blocklist_log reason

Rejection Message Substitution




The sender's IP was recorded in the SophosLabs list of known spammers (Blocker data).



The sender's ISP usage policy doesn't allow customers to send email unless it is via a smart-host. (Dynamic Sender data)



The PTR record is checked against a list of regular expressions from ISPs whose usage policy doesn't allow customers to send email unless it is via a smart-host. (Regular Expression for rDNS mail senders)



Senders that use HELO/EHLO arguments that only appear in spam and may not be RFC-compliant.



An explicit IP hostname has been added to the IP Blocking Inclusion list.



The customer has added a hostname glob match to the IP Blocking Inclusion list.

Customizing an IP Blocker Rejection Message

Administrators can specify a custom rejection message. This replaces the SophosLabs rejection message, which contains the default Sophos explanation and a possible solution.

Note: The text included in this setting is used as a rejection message that is delivered to the original sender. It is not recommended that you change this setting because doing so will cause the same message to be issued in all cases, regardless of the reason for the rejection. By default, the rejection messages provided by Sophos vary, depending on the reason the message was rejected.

To customize the rejection message, edit the following setting in /opt/pmx/etc/pmx.d/blocklist.conf:


Note: This change must be made on each edge server in a multi-server configuration.


The following variables are available for use in a customized message string:


The IP address of the server from which the blocked message originated. Only use this variable in the context of a custom URL. For example:

Your message has been rejected because it is spam. http://www.example.com/ip=

You would set this in blocklist.conf as:

reject_message = Your message has been rejected because it is spam. http://www.example.com/ip=%%IP%%


The reason that the message was blocked. The reasons include:

  • IP - Matched data from SophosLabs.
  • DYN - Matched dynamic sender data from SophosLabs.
  • HELO - The HELO string of the connecting mail transfer agent is suspicious.
  • CUSTIP - Matched an IP or hostname in the IP Blocking Inclusion list.
  • CUSTRDNS - A glob match has been specified in the IP Blocking Inclusion list.
  • DYNR - Matched a regular expression for RDNS mail senders.


The default URL that links to Sophos's web service. This variable must be replaced with a custom URL if you want the rejection message to direct recipients to a location other than the Sophos site.

If you are directing rejected senders to a site other than Sophos via a custom URL, the senders can, optionally, be redirected to a different page, depending on the type of block that occurred.

For example:

Your message has been rejected because your internet service provider does not permit you to send mail.

Note: When using multiple variables in a customized message string, they should be entered consecutively, without spaces (%%IP%%%%TYPE%%%%URL%%).

Building a Custom Rejection Message

Your rejection message must meet the following requirements:

  1. There must be a value in reject_message. A blank reject_message will not work, and you will receive errors when starting PureMessage.
  2. Please ensure that the reject_message is set between the <blocklist></blocklist> tags, or it will not work.
You will receive an error as follows:

/opt/pmx/etc/pmx.d/blocklist.conf:17: Unexpected option 'reject_message' while parsing in strict mode.
Compilation failed in require at /opt/pmx/lib/site_perl/5.6.1/pmx_user.pm line 9.
BEGIN failed--compilation aborted at /opt/pmx/bin/pmx line 7.


Here is an example of a /opt/pmx/etc/pmx.d/blocklist.conf modified custom rejection message. The IP address has been added to the list /opt/pmx/etc/ip-blocking-inclusions:

<blocklist Policy>
port = inet:4466@localhost
blocklist_log = blocklist_log
refresh_interval = 1m
block_dynamic = __DEFAULT__
block_helo = __DEFAULT__
reject_message = CUSTOM MESSAGE Type %%TYPE%% %%IP%%

The sending mail transfer agent would show the following in the system mail log:

5.7.1 <unknown[]>: Client host rejected: CUSTOM MESSAGE Type CUSTIP

As explained in the table in "Logging," CUSTIP means that an explicit IP hostname has been added to the IP Blocking Inclusion list.

Using the SophosLabs Remediation Page

Mail transfer agents that connect to a PureMessage server with the IP Blocker service enabled will receive a rejection message that links to a remediation site, where you can enter IP addresses to see if they are included on SophosLabs' lists. If the IP address is listed, you can request that SophosLabs review it for possible removal.

The site is located at:


Remediation can take up to 24 hours.


If you need more information or guidance, then please contact technical support.

Rate this article

Very poor Excellent