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 = 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
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 = permitYou 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 # email@example.com spamhater firstname.lastname@example.org 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
email@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
firstname.lastname@example.org go through the same
process, but when Postfix checks the “spamlover”
restrictions, it finds “permit” and immediately accepts the
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_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
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.