How to Setup Greylisting Service on Postfix Mail Server

postfix GreylistingSpam became a noticeable treat for the mail servers many years ago. No servers today could be running without being hardened against the spam: according to some reports up to 75% of all the email traffic is spam. It’s noticeable from network capacity, hardware and electricity consumption even if you run small company mail system. Even though the commercial content analyzing anti-spam solutions might be heavy and expensive and open source ones might be heavy and complicated, there are several techniques that would eliminate about 80% of spam traffic at about no cost from the resource perspective. Greylisting is one of these techniques.

The idea behind the greylisting solution is very simple yet elegant: the hosts that are sending the spam messages are not real mail servers, and they’re not controlled by the real system administrator: they’re bots running on random hosts. Since they life is unpredictable even for the owner of the botnet, they don’t obey the rules that the normal mail server does. And if you will try to ask such host politely to postpone the message for 5 minutes it will either disappear forever or it will try once more immediately. That’s the whole idea of greylisting: ask to try once more in 3 or 5 minutes and analyze the behavior of the sender. If it obeys correctly then it most likely a legitimate mail agent, if not — it’s definitely a spam bot. If we already have seen the sender sending this recipient message from the particular host (i.e. triplet) — then we should not bother them with any checks anymore and will not delay message for them.

In this article, I would show you how to configure greylisting service for the Postfix mail server. We would use CentOS 7.4, but on other versions of Linux the procedure is nearly the same. The most convenient way to implement this technique on the Centos with Postfix is to use postgrey.

Since the postgrey is added to the main repository we can install it just running

    # yum install postgrey

Then run the daemon and enable it on boot:

    #systemctl start postgrey
    #systemctl enable postgrey

It uses standard smtpd_recipient_restriction mechanism to deal with the postgrey via UNIX socket. Just adding the socket path to the check_policy_service there:

  smtpd_recipient_restrictions =
   permit_mynetworks,
   check_policy_service unix:postgrey/socket,
   permit

This will tell the smtpd process to send messages to the postgrey’s socket after all other checks (we don’t want to check trivially out filtered email) and accept it only after the postgrey accepts it.

Postgrey itself does not have a real config file and the only option you really need is for how long you want the message to be delayed. So in the /etc/sysconfig/postgrey we can define the startup option for the daemon. By default, the delay is 300 sec but even 60 seconds might be enough for most bots.

    OPTIONS="--unix=/var/spool/postfix/postgrey/socket --delay=60"

If you see “access denied” it’s SELinux issue that can be fixed with audit2allow that will tell the SELinux that it’s fine for the postgrey daemon to write to the UNIX socket:

    # grep smtpd_t /var/log/audit/audit.log | audit2allow -m postgreylocal > postgreylocal.te
    # cat postgreylocal.te
    module postgreylocal 1.0;
    require {
            type postfix_smtpd_t;
            type postfix_spool_t;
            type initrc_t;
            class sock_file write;
            class unix_stream_socket connectto;
    }
    #============= postfix_smtpd_t ==============
    allow postfix_smtpd_t initrc_t:unix_stream_socket connectto;
    allow postfix_smtpd_t postfix_spool_t:sock_file write; 

Here we can see example of the message where the sender, recipient and the sender’s host are already

Sep 21 14:38:04 andreybondarenko postgrey[518]: action=pass, reason=triplet found, client_name=mail2.static.mg.example.com, client_address=192.127.58.166, [email protected], [email protected]

Here is an example of delayed message:

Sep 22 11:20:31 andreybondarenko postgrey[518]: action=greylist, reason=new, client_name=ppp91-122-100-196.pppoe.avonddsl.com, client_address=91.12.10.196, [email protected], [email protected]

As we can see from the PTR, it’s a xDSL pool so it’s definitely a bot.

The drawback of the postgrey is that the first mail that is delivered from the new server would be delayed for several minutes. If you’re running several MX’ex then this problem might be worse since the sending mail server will go to the next MX and if the greylisting is enabled there then it would be delayed on this host too separately, so the delay would be increased.

In conclusion, I want to say that the greylisting bounces most of the spam at no cost since the idea and the software behind it are free and it does not add false positives as Bayes filters do.

 

About Andrey Bondarenko

I am Linux geek with about 20 years of experience in security, mail server, identity management.

Author Archive Page

Have anything to say?

Your email address will not be published. Required fields are marked *

All comments are subject to moderation.