The Postfix Greylisting Policy Server (Postgrey) uses the concept of greylisting to take advantage of mail standards that the vast majority of spammers are not or cannot be configured to support.
The postfix process is configured to send incoming mail to postgrey, which determines whether the mail can continue to the next step in the delivery process by checking whether the sender (“client”) or recipient match anything postgrey is configured to match.
When the postgrey test fails, postfix will notify the sending server that the message was rejected and to try again after a minimum time period, which Mail-in-a-Box is configured for 180 seconds. Mail delivered before the 180 seconds will receive the same postgrey failure and postfix rejected delivery message.
Since a significant percentage of spam servers cannot receive or interpret the rejected delivery message, the spam server will typically never attempt to send the mail again after the time period, so the message is never delivered to any recipient.
After a client has passed the postgrey checks resulting in a delivered mail, the client information is stored so that in the future the client will bypass the initial delay test and be delivered as normal.
There also exists a Postgrey project maintained list of trusted servers that will always bypass the delay test. These can be viewed in /etc/postgrey/whitelist_clients. This file is automatically updated by a Mail-in-a-Box script, so manual changes to this file will disappear into the flux of time.
The greylisting solution is considered by most admins to be well worth the minor inconvenience, but it does have some problems. For this reason, users can create a locally maintained whitelist for both clients and recipients.
From the relevant section of the postgrey man page:
Whitelists
Whitelists allow you to specify client addresses or recipient address, for which no greylisting should be done.
Per default postgrey will read the following files:/etc/postgrey/whitelist_clients
/etc/postgrey/whitelist_clients.local
/etc/postgrey/whitelist_recipients
/etc/postgrey/whitelist_recipients.localYou can specify alternative paths with the --whitelist-x options.
Postgrey whitelists follow similar syntax rules as Postfix access tables. The following can be specified for recipient addresses:
domain.addr
“domain.addr” domain and subdomains.name@ “name@.*” and extended addresses “name+blabla@.*”.
name@domain.addr
“name@domain.addr” and extended addresses./regexp/ anything that matches “regexp” (the full address is matched).
The following can be specified for client addresses:
domain.addr
“domain.addr” domain and subdomains.IP1.IP2.IP3.IP4
IP address IP1.IP2.IP3.IP4. You can also leave off one number, in which case only the first specified numbers will be checked.IP1.IP2.IP3.IP4/MASK
CIDR-syle network. Example: 192.168.1.0/24/regexp/ anything that matches “regexp” (the full address is matched).
The most common usage of postgrey whitelists is on the client whitelist, especially with domains that use multiple SMTP servers and are not configured to always send to an address from the same SMTP server.
A real-world current example is craigslist.org:
Aug 28 06:15:57 mail postfix/smtpd[9576]: NOQUEUE: reject: RCPT from mxo3f.craigslist.org[208.82.238.98]: 450 4.2.0 <username@example.com>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/desertduck.net.html; from=<bounce-accounts@craigslist.org> to=<username@example.com> proto=ESMTP helo=<outbound.200username.craigslist.org>
Aug 28 06:48:36 mail postfix/smtpd[12592]: NOQUEUE: reject: RCPT from mxo6f.craigslist.org[208.82.238.101]: 450 4.2.0 <username@example.com>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/desertduck.net.html; from=<bounce-accounts@craigslist.org> to=<username@example.com> proto=ESMTP helo=<outbound.200username.craigslist.org>
We can see that craigslist.org is using at least two different SMTP servers with different IP addresses, which means they will be delayed by postgrey checks until all of the SMTP servers have been checked by postgrey.
There may be several ways to deal with this issue, but at least two in this case seem preferable. The first would be to identify the IP addresses used by the from domain, which we can see in the message from=bounce-accounts@craigslist.org so craigslist.org is the client domain in this case.
View the SPF record to determine how to add craigslist.org to the whitelist with only the SPF authorized sending servers.
$ dig txt craigslist.org +short
"v=spf1 ip4:208.82.237.96/29 ip4:208.82.237.104/31 ip4:208.82.238.96/29 ip4:208.82.238.104/31 -all"
...
Create the whitelist_clients.local file:
$ sudo nano /etc/postgrey/whitelist_clients.local
And add the IP address ranges in CIDR notation:
# craigslist.org SPF authorized sending servers retrieved 28 Aug 2021
208.82.237.96/29
208.82.237.104/31
208.82.238.96/29
208.82.238.104/31
Of course, it’s always possible that craigslist.org will change the IP addresses in their SPF record, in which case it would be necessary to revise the whitelist_clients.local file.
For a second, somewhat lazier option, let’s check who owns those IP addresses:
$ whois 208.82.237.96
...
CIDR: 208.82.236.0/22
...
OrgName: Craigslist, Inc.
...
Since the owners of craigslist.org also own their IP address range, another option would be to choose to have postgrey whitelist their entire IP address range. It is unlikely that an organization would choose to purchase such a hefty investment without making use of it, so they will likely only send mail from these IP addresses and will also act to protect the reputation of these IP addresses.
Add the entire IP address range to /etc/postgrey/whitelist_clients.local:
208.82.236.0/22
Questions and constructive feedback on this guide is appreciated.