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 righthand side of an access table. They cannot be used in header and body checksonly 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 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.

11.10.1 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. You 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, you 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
#
[e-mail] spamhater
[e-mail] spamlover

Next, tell Postfix that it should check your 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 [e-mail], 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 [e-mail] go through the same process, but when Postfix checks the "spamlover" restrictions, it finds permit and immediately accepts the message.