Simple spam prevention

HELO restrictions

These are the most basic form of spam defence which can be employed on a Postfix installation. At the start of every mail exchange the client side of the connection is required to send a greeting consisting of the text HELO or EHLO followed by the fully qualified domain name of the connecting host or a host on behalf of which it acting as a mail proxy. A great many spam sending applications do not bother to send an HELO or EHLO greeting in an attempt to increase their throughput. We can therefore reduce some obvious spam simply by requiring that such a greeting is present. We can further increase our rate of spam detection by requiring that the HELO or EHLO greeting actually contains a valid fully qualified domain name which we can resolve to an Internet addressable IP address.

We can implement these simple restrictions on our mail server by simply adding the three lines below to our existing Postfix configuration. The first line of the example below configures Postfix to require a valid greeting while the second required that this greeting contains a valid fully qualified domain name as discussed in the previous paragraph. The third and final line configures the Postfix server to wait to reject mail until the DATA command is issued so that the sending client can be notified of the reason that the message was rejected.

smtpd_helo_required = yes
smtpd_helo_restrictions = reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname
smtpd_delay_reject = yes

Disabling the VRFY command

Most mail servers support the VRFY command which is used to verify that an email address exists prior to sending a message there. As you can probably imagine this is almost always used by people wishing to test the validity of email addresses they have acquired on a bulk list of some kind and therefore disabling it can help to reduce the amount of spam we receive. If you wish to disable the VRFY command add the following configuration option to your existing configuration file.

disable_vrfy_command = yes

Querying SPF records

Another very simple method of spam prevention, although one which is largely overlooked both by receiving mail servers and domain name owning organisations and individuals, is the Sender Policy Framework which is used to provide a list of permitted sending addresses associated with a domain which can be queried by receiving mail servers to detect spam claiming to be from the domain in question.

The Postfix server does not come with the ability to check SPF records built-in however this functionality is easily added using a very small extension. If you wish to enable the checking of SPF records by your installation the first step is to install the required software and any dependencies it may need. For your convenience these are shown below.

Once the required software is installed the next step is to configure the Postfix server to automatically start an instance of the pypolicyd-spf daemon as required. This is easily accomplished by adding the lines shown below to the master configuration file for the Postfix daemon.

policyd-spf  unix  -       n       n       -       0       spawn
    user=nobody argv=/usr/bin/python /usr/bin/policyd-spf /etc/python-policyd-spf/policyd-spf.conf

Now that Postfix will automatically start instances of the pypolicyd-spf daemon as needed we can add the required configuration options to our existing Postgres configuration file so that SPF checks will be performed on received mail. As you can see from the example below this consists of a very simple change to the existing configuration to add the SPF policy check to our existing list of recipient restrictions. The only addition line in our configuration sets the maximum length of time an idle policyd-spf instance can remain active before being terminated by the Postfix daemon.

smtpd_recipient_restrictions = permit_sasl_authenticated, reject_unauth_destination
smtpd_recipient_restrictions = permit_sasl_authenticated,
                               reject_unauth_destination,
                               check_policy_service unix:private/policyd-spf

policyd-spf_time_limit = 3600

As you can see in the above example we have added the SPF policy check after the permit_sasl_authenticated check so that authenticated users can send mail from anywhere regardless of any SPF records. It is very important however that the SPF checks come after we reject unauthorised destinations or our mail server may become an open relay to anyone with a correctly configured SPF record.

 

All that remains to be done now is to restart the Postfix server to ensure that our new configuration will be used immediately. This can be performed using the command shown below.

Requiring strictly RFC821 compliant envelopes

A reasonable percentage of spam can also be rejected by insisting on strictly RFC-821◳ compliant envelopes. If you wish to enable this feature simply add the configuration line shown below to your existing Postfix configuration.

strict_rfc821_envelopes = yes

Using the Spamhaus DNSBL service

The final line of defence which can be implemented using just the features provided by the Postfix daemon is to configure recipient restrictions based on the client network address using a DNS-RBL service such as that provided by the Spamhaus organisation. To use this feature you will need to modify the existing smtpd_recipient_restrictions entry in your Postfix configuration file as shown below.

smtpd_recipient_restrictions = permit_sasl_authenticated,
                               reject_unauth_destination,
                               check_policy_service unix:private/policyd-spf,
                               reject_rbl_client sbl-xbl.spamhaus.org

When using a DNS-RBL service it is a sensible idea, both to reduce load on their servers and to improve mail server throughput, to install a local DNS cache either on the mail server or on a machine close by. It should also be noted that the Spamhaus organisation place usage restrictions on clients of their services.