This article is a logical continuation of the article " Integration of rspamd email anti-spam with opensmtpd " due to some challenge that I was thrown saying that it is difficult to implement greylisting in the opensmtpd + rspamd combination.

I have not seen the “success stories” of integrating greylisting into opensmtpd (if they exist, please write in the comments).

It is difficult to implement greylisting in my case - I didn’t deny and didn’t intend to do this functionality before opening filters in opensmtpd, although I understood that greylisting is one of the quite good methods of dealing with spam. But the challenge and the desire to a little more reduce the amount of spam and sleep well - they did not let sleep sleep and forced to do it.

I managed to implement a simple greylisting method.

A few clarifications:

1. The method is simple only if the implementation of the opensmtpd + rspamd bundle is done through the mda script layer.

   
   

2. The implementation of greylisting for opensmtpd exists through a filter . But, as they know, people interested in opensmtpd do not have a stable implementation of filters in opensmtpd. In addition, I didn’t want to add one more daemon with rspamd integrated greiling

   
   

3. Implementation of greylisting for opensmtpd exists for freebsd and spamd. I was not interested in the implementation details, since there is no spamd daemon for linux.

   
   
4. Implementation is a crutch and use of undocumented features, but where are we without them in IT?

Theory

Greylisting is a method of spamming, based on the fact that spam programs want to send as much spam as possible here and in this second.

Simplified logic of greylisting: if a letter comes to us, then we reply to the sender with a temporary error, we remember the sender ourselves (for example, for a day) in order to receive a letter from him after some time (for example, after 5 minutes).

The "correct" sender (according to standards) should try to send us an email again after a while. The “wrong” sender either does this or does not, but in the intervening time, the sender has time to get into various external spam lists and we are filtering it out already on the basis of these spam lists.

After we have remembered the sender, then within a day (as an example), the check for greylist is not done again. This allows you to reduce the time of delivery of the second letter (if this is the correct sender).

In postfix + amavis + spamasassin greylisting was done, if I'm not mistaken, by domain names. In rspamd, the IP address of the sender with the mask / 19 (configurable) is made the key for greylisting. On the part of general clustering and geo-distributed services, this looks like a more correct solution, but also discussed, on the other hand.

Unfortunately, all this in theory looks good, but in practice, when there are a lot of botnets on teapots, microwaves and computers of ordinary users, they send spam through regular Outlook (how is it there, still exists on Windows?) - everything is not so great. But somehow the technique works and you should not refuse it.

Practice

redis in rpsamd

We include radish support in rpsamd. The module of greylisting stores its data in radish.

# /etc/rspamd/local.d/redis.conf servers = "redis.example.com"; password = "example_password"; 

Run radishes (in docker, for example, this is done by one team).

greylisting in rspamd

Turn on the greylisting module (by default, it is turned off). expire - the time for which the sender becomes trusted after passing the check. I specifically twirted more. The default is 86400 seconds.

 # /etc/rspamd/modules.d/greylist.conf greylist { expire = 864000; .include(try=true,priority=5) "${DBDIR}/dynamic/greylist.conf" .include(try=true,priority=1,duplicate=merge) "$LOCAL_CONFDIR/local.d/greylist.conf" .include(try=true,priority=10) "$LOCAL_CONFDIR/override.d/greylist.conf" } 

→ Example container with rspamd

greylisting in opensmtpd

The most ambiguous part of the solution.

After we sent the letter to the rspamd daemon via the rspamc client (see previous article), the demon on STDOUT responds with the text of the letter with added headers.

In case greylisting is required, then "X-Spam-Action: soft reject" will be present in the headers. For good, mta or filters recognize this header and respond to the sender with a temporary error.

But we have no support for mta or filters. Therefore, we just do exit 1!

 # .     greylisted=$( cat $mail_file | fgrep 'X-Spam-Action: soft reject' ) if [ -n "$greylisted" ]; then exit 1 fi 

opensmtpd, having received return code 1, understands that something went wrong and is responsible for the sender with a temporary error.

Peculiarities of launching a docker container with opensmtpd: it must be launched in the network mode "host" in order for the daemon to see the correct IP addresses of senders.

→ Example container with opensmtpd

Total

Even less spam.