What is Greylisting?


Greylisting is a method that can be implemented on mail services by mail administrators in order to mitigate high spam volumes coming into their organization. It is very simple in its concept and its implementation, which I will describe in more detail below.


How does it work?


The basic principle of greylisting is that a properly implemented mail server will be able to deal with a temporary failure response from another server, and retry to send a given message after a certain amount of time. The goal is to block messages from spam-sending bots and self-propagating viruses that use e-mail as a means of propagation. A well implemented MTA (Mail Transfer Agent) will deal with the temporary failure by queuing the message for later delivery.


When an SMTP server runs a greylisting implementation, as it receives an incoming SMTP connection request, it looks up the sender IP address, sender e-mail address and recipient mail address in a local cache to check if the given message was previously attempted. If the request does not match an entry in the greylisting database, a new entry is added with the source IP, sender and recipient details, recording the date and time of the first request so a countdown timer can be started.


Once the countdown time reaches zero, and the sender attempts to send the same message again, it will now be accepted. This means automated senders that do not handle temporary failures correctly will have been successfully blocked and any genuine senders that retry the message are accepted. Greylisting implementations will also be able to determine when a record for a specific sender has aged and should be removed.


When should it be used?


Enabling greylisting on MEG is recommended when the domain(s) being protected are targeted with high levels of spam mail, as it will block most of the spam right at the connection stage. This will mean the appliance will end up scanning only the data of these emails that are accepted by the greylisting filter, which should be a minority of all spam.


When should it not be used?


By design, greylisting introduces a delay on message delivery. If such a delay will impact service or it outweighs the benefit of the freeing up of scanning resources in the appliance, the administrator can choose not to use the feature.


How to configure greylisting on MEG


1. Go to E-mail | E-mail Configuration | Receiving E-mail | Recipient Authentication

2. The first section of this dashboard covers the Greylisting feature

3. On the 'Protocol preset' drop-down menu on the top right corner of the greylisting section, define the criteria for which the greylisting policy will be applied (for instance, you can create a preset listing the IP addresses of your internal mail servers, and disable greylisting for this preset, and leave greylisting enabled for all other connections - the default preset)


The available options for greylisting presets on MEG are


  • Enable/disable greylisting for a given protocol preset
  • Accept SMTP callback requests (a callback request is a sender verification method used by some mail server implementations)


The following options apply to greylisting globally:


  • Initial retry delay (default is 1 hour)
  • Unretried record lifetime (default 4 hours - if the sender does not retry within this time interval a new request will be placed into the database and a delay enforced again)
  • Greylisted record time (default is 864 hours - 36 days - this specifies how long a greylisted record is kept for)
  • Maximum number of records (max 2 million)


The following considerations apply if you are planning to use greylisting on a deployment where multiple MEG appliances will be used:


If native MEG clustering is in use: The greylist database is managed by the master node. If there is a failure on the master node and the failover needs to take over, greylisting will keep functioning but a new greylisting database will be used (the records from the master node are not synchronized)


If load balancing is external to MEG: There is currently no feature to share the greylisting data between multiple appliances


Links to related articles and documentation:


Email Gateway 7.6.3 Product Guide (from page 120)


KB76653 - When the cluster master switches over to failover, its greylisting database is not switched over