Postfix Restriction Classes

[ home / articles / Postfix Restriction Classes]
The following article is exerpted from Chapter 11 of Postfix: The Definitive Guide. This section describes setting up restriction classes for refining how your anti-spam rules are applied.

Customized Restriction Classes

Restriction classes provide the last wrinkle in the Postfix anti-spam parameters. They allow you to define a set of restrictions that you can assign to the right-hand side of an access table. They cannot be used in header and body checks—only in access tables. Restriction classes let you set up different restrictions for different clients, senders and recipients. Restriction classes are a powerful tool that can provide great flexibility in Postfix UBE (Unsolicited Bulk Email) restrictions. If you require any sort of complicated rules to block spam, it is well worth your while to invest the time to understand restriction classes.

Restriction classes are particularly useful when you need to create exceptions to your normal restrictions. To illustrate with an example, let's create two classes of users. One group wants to receive all messages addressed to them whether or not the messages are spam. The other group prefers particularly stringent checks against spam even at the risk of losing some legitimate mail.

Sample Restriction Classes

We'll call the two classes “spamlover” and “spamhater.” You must list all of the restriction classes you plan to define in the smtpd_restriction_classes parameter.

smtpd_restriction_classes = spamlover, spamhater

We've invented the names of the classes, but once listed with smtpd_restriction_classes, they can be treated like any other restriction rule. We can assign a list of restrictions to be considered for the class. Once defined the restriction class can be used as an action in an access table. When Postfix encounters the class, it steps through the assigned restrictions.

We'll define “spamhater” with several restrictions:

spamhater =
	reject_invalid_hostname
	reject_non_fqdn_hostname
	reject_unknown_sender_domain
	reject_rbl_client nospam.example.com
and “spamlover” with a simple “permit.”
spamlover = permit
You could, of course, refine these with restrictions that make sense for your own configuration.

Now that the restriction classes have been declared and defined, we can put them to use by assigning the appropriate class to each of our recipients in a lookup table. We'll call the table per_user_ube.

#
# per_user_ube
#
abelard@example.com   spamhater
heloise@example.com   spamlover

Next, we tell Postfix that it should check our recipient lookup table when checking restrictions.

smtpd_recipient_restrictions =
    permit_mynetworks
    reject_unauth_destination
    check_recipient_access hash:/etc/postfix/per_user_ube

When a message comes in addressed to abelard@example.com, Postfix goes through the normal default restrictions and then encounters check_recipient_access pointing to the recipient lookup table. Postfix finds the recipient address in the file, reads the action spamhater and then invokes the restrictions defined for spamhater. If any of the “spamhater” restrictions returns REJECT, Postfix rejects the message; otherwise, it is delivered. Messages for heloise@example.com go through the same process, but when Postfix checks the “spamlover” restrictions, it finds “permit” and immediately accepts the message.

Postfix Anti-Spam Example

Now that we've covered the many aspects of Postfix's anti-spam arsenal, we'll finish by presenting an example configuration. Requirements vary considerably from site to site, so it's impossible to make actual recommendations apart from the considerations that have been discussed in this chapter. The samples earlier in the chapter can provide a starting point, but you must decide for yourself which restrictions fit your own circumstances.

Sample restrictions to block UBE

smtpd_restriction_classes =
	spamlover
	spamhater

spamhater =
	reject_invalid_hostname
	reject_non_fqdn_hostname
	reject_unknown_sender_domain
	reject_rbl_client nospam.example.com

spamlover = permit

smtpd_helo_required = yes
smtpd_client_restrictions =
     	check_client_access hash:/etc/postfix/client_access
smtpd_helo_restrictions =
	reject_invalid_hostname
	check_helo_access hash:/etc/postfix/helo_access
smtpd_sender_restrictions =
	reject_non_fqdn_sender
	reject_unknown_sender_domain
	check_sender_access hash:/etc/postfix/sender_access
smtpd_recipient_restrictions =
	permit_mynetworks
	reject_unauth_destination
	reject_non_fqdn_recipient
	reject_unknown_recipient_domain
smtpd_data_restrictions =
	reject_unauth_pipelining
header_checks = /etc/postfix/header_checks
body_checks = /etc/postfix/body_checks

You should enter IP and email addresses into the access tables from messages you receive that you have identified as spam. It's very difficult to block a lot of spam with the check_helo_access and check_sender_access restrictions because it's so easy for spammers to fake that information. There is effectively an unlimited number of addresses and hostnames spammers might use. This makes it nearly impossible to keep up with them. Since it's so easy to fake this information, you might be blocking legitimate hosts and addresses that just have the bad luck of having their information used by spammers.

But these checks can be useful against messages that repeatedly use the same forged information and spammers that don't attempt to cover their tracks. Some online marketing services use their real information when sending spam. These sites might even honor removal requests, but if you object to having to request a removal from companies you've never heard of, you can block them based on the HELO or MAIL FROM information.

You can also block sites that you don't want to hear from whether they're real or fake. Mail from a site you consider objectionable is one example. Also, if you believe it's impossible that you would be receiving messages from the Republic of Maldives, you could block addresses and hostnames using the Republic of Maldives' top level domain. Keep in mind, however, if you run a mail system for many users, you probably shouldn't force your own moral attitude on everyone or assume your users don't have Maldivian relatives or a special interest in the cuisine.

Bookmark and Share
   
[Back to Top]

Enter a comment or email me directly if you prefer.

Comments:

Name (optional):
Comment: