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 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 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.
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.comand “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 # abelard@example.com spamhater heloise@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_ubeWhen 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.