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 # firstname.lastname@example.org spamhater email@example.com 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 firstname.lastname@example.org, 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 email@example.com go through the same process, but when Postfix checks the "spamlover" restrictions, it finds permit and immediately accepts the message.
General Configuration and Administration
Email and DNS
Local Delivery and POP/IMAP
Hosting Multiple Domains
Blocking Unsolicited Bulk Email
Transport Layer Security
Appendix A. Configuration Parameters
Appendix B. Postfix Commands
Appendix C. Compiling and Installing Postfix
Appendix D. Frequently Asked Questions