Home // Postfix Guides // Restriction Classes

Restriction Classes

RESTRICTION CLASSES
Restriction classes can be used to impose specific restrictions based on a variety of criteria. There are a few areas where restriction classes have proven to be extremely useful in filtering out spam on our servers.

Note: When dealing with smtpd restrictions, we prefer to list all of the options in smtpd_recipient_restrictions as described at the end of the Main.cf Guide.

While it can be a good idea to restrict / reject specific types of messages as early as possible (a helo based restriction in the smtpd_helo_restrictions section), by placing all of the restrictions into the smtpd_recipient_restrictions, you will be able to accumulate as much information about the attempted spam as possible, as well as order all of the restrictions to better allow you to prevent spam.

VERIFY SENDER
As of mid-2004 we are using reject_unverified_sender in our main.cf smtpd_recipient_restrictions which deprecates the information in this VERIFY SENDER section. This information is being left as an example, but you should consider that rejecting any email for which the sender address does not exist is probably a good idea. Likewise, if you are running an MX server or relay that is not on the same server as your pop/imap/final destination, then reject_unverified_recipient will reject any email for which a recipient check fails. The way both these checks work is upon receipt of the mail from and rcpt to headers of a message, postfix will attempt to start delivery of a message from postmaster@your.domain.com to the sender’s address. If the MX server of the sender’s domain responds with an OK to send the email, your postfix server knows that the address exists. If not, the your postfix will reject the message. This data is cached for a time, so subsequent emails to or from the same address won’t need to always be checked.

The first restriction class that we use is called verify_sender. This will cause Postfix to perform a check on the MX (mail exchange) host responsible for the domain portion of the sender’s email address. This check will verify that the sender’s address is valid, and that the address is capable of receiving email. This will cause a connection out to another mail server every time you receive an email, so you will want to limit this activity to domains that are very commonly spoofed or forged.

1. In your main.cf, you will first have to define a restriction class. You will do so by adding the following:

smtpd_restriction_classes = verify_sender

2. Next, it will be necessary to specify what “verify_sender” means. You will do so by adding the following:

verify_sender = reject_unverified_sender, permit

3. You will then have to add an item to your smtpd restrictions as explained below.

smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/maps/verify_sender
Note: This is not all that should be in smtpd restrictions. A good example of smtpd restrictions can be found in the Main.cf Guide .

4. Lastly, you will have to create the map file /etc/postfix/maps/verify_sender in the format below.

Example:
#domain.extention verify_sender
earthlink.net verify_sender
hotmail.com verify_sender
lycos.com verify sender
msn.com verify_sender
netscape.com verify_sender
netscape.net verify_sender
yahoo.com verify_sender

VERIFY DOMAIN
The second restriction class that we use is called verify_domain. This will cause Postfix to verify that the client’s host name, the server name supplied in the helo command, and the sender’s address all use the same domain. Spammers will commonly use a reply address of one of the free email providers, but originate their emails from somewhere else. Most of the time, an email from someone@yahoo.com should not originate on a server other than one of the mail.yahoo.com subset.

You will only want to run these verifications on mail that you know is commonly spoofed or forged, as most custom (personal or commercial) domain names (such as securitysage.com) will not always originate from their own servers.

1. In your main.cf, you will first have to define a restriction class. You will do so by adding the following:

smtpd_restriction_classes =
verify_domain_client,
verify_domain_helo,
verify_domain_sender

2. If you are already using the verify_sender restriction class, then your main.cf entry will look like this:

smtpd_restriction_classes =
verify_sender,
verify_domain_client,
verify_domain_helo,
verify_domain_sender

3. Next, it will be necessary to specify what each of the verify_domain classes mean. You will do so by adding the following:

verify_domain_client =
check_client_access hash:/etc/postfix/maps/bad_domains,
check_client_access regexp:/etc/postfix/maps/text_domain_client_mismatch,
reject

verify_domain_helo =
check_helo_access hash:/etc/postfix/maps/bad_domains,
check_client_access regexp:/etc/postfix/maps/text_domain_helo_mismatch,
reject

verify_domain_sender =
check_sender_access hash:/etc/postfix/maps/bad_domains,
check_client_access regexp:/etc/postfix/maps/text_domain_sender_mismatch,
reject

Note: The regexp entries will be used to provide a custom error message for each verification as seen in the text file descriptions below. The reject entry after these is being left just in case something gets through the rejection entry in the regexp files. Once your system is working properly, you can safely remove the reject entries (and the comma at the end of the previous lines).

4. You will then have to add an item to your smtpd restrictions as follows:

smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/maps/verify_domain
Note: This is not all that should be in smtpd restrictions. A good example of smtpd restrictions can be found in the Main.cf Guide .

5. You will then have to create the /etc/postfix/maps/verify_domain map file in the format below.

Example:
#domain verify_domain_client,verify_domain_helo
earthlink.net verify_domain_client,verify_domain_helo
hotmail.com verify_domain_client,verify_domain_helo
karamail.com verify_domain_client,verify_domain_helo
mac.com verify_domain_client,verify_domain_helo
msn.com verify_domain_client,verify_domain_helo
netscape.com verify_domain_client,verify_domain_helo
netscape.net verify_domain_client,verify_domain_helo
yahoo.com verify_domain_client,verify_domain_helo

Note: We do not need verify_domain_sender as the check will start out as an smtpd_sender_restriction. That restriction was created as part of these instructions to enable you to perform other related checks more easily in the future.

This will enable the verify_domain_client and verify_domain_helo restriction classes for each domain in the list.

IMPORTANT NOTE: You don’t want the verify_domain and bad_domains files getting too big, as all of the domains listed in them will be allowed to work together. As an example, if you have yahoo.com, hotmail.com and earthlink.net listed, then a client from dial-up.earthlink.net could send a helo of spammer.hotmail.com and use a sender address of spammer@yahoo.com, and this message will get through this restriction class. You can make as many restriction classes as you want, so in theory you can separate each domain into its own restriction class, but that would cause your configuration to become overly complicated.

6. Next, the /etc/postfix/maps/bad_domains map file has to be created. This is the file that will be referenced by the restriction class entries in main.cf as listed above. In these files, Postfix will be looking for the names of the expected servers with an OK. The restriction class will be responsible for rejecting messages if the domains are not listed in this list.

Example:
#domain OK
earthlink.net OK
hotmail.com OK
karamail.com OK
mac.com OK
msn.com OK
netscape.com OK
netscape.net OK
yahoo.com OK

Note: Remember that the domains in this map file have to be identical to those in the /etc/postfix/maps/verify_domain map file. The latest version of our bad_domains file can be obtained here.

7. Lastly, you will have to create the text files for each of the rejections on client, helo, and sender checks as follows:

File: /etc/postfix/maps/text_domain_client_mismatch
Contents: /./ 554 Client Domain Mismatch
File: /etc/postfix/maps/text_domain_helo_mismatch
Contents: /./ 554 HELO Domain Mismatch
File: /etc/postfix/maps/text_domain_sender_mismatch
Contents: /./ 554 Sender Domain Mismatch

Now, if anyone should send an email from any of the verify_domain / bad_domains with alternate client or helo domains, it should be rejected.

VERIFY HELO
Some people have found it useful to perform an additional check using the configurations set up in the above VERIFY DOMAIN instructions. If you would like to perform a check specifically on HELO commands to verify if the client domain matches the HELO domain, then once you have completed the above configuration, add the following to your smtpd restrictions:

smtpd_recipient_restrictions = check_helo_access hash:/etc/postfix/maps/verify_helo
Note: This is not all that should be in smtpd restrictions. A good example of smtpd restrictions can be found in the Main.cf Guide .

You will then have to create the /etc/postfix/maps/verify_helo map file in the format below.

Example:
#domain verify_domain_client
earthlink.net verify_domain_client
hotmail.com verify_domain_client
karamail.com verify_domain_client
mac.com verify_domain_client
msn.com verify_domain_client
netscape.com verify_domain_client
netscape.net verify_domain_client
yahoo.com verify_domain_client

Note: We do not need verify_domain_sender as that check will be performed in the smtpd_sender_restrictions defined in the VERIFY DOMAIN section above. We do not need verify_domain_helo as this check will start out as an smtpd_helo_restriction.

This will enable the verify_domain_client restriction class for each domain in the list.

IMPORTANT NOTE
Of very high importance is the placement of reject_unauth_destination before any entries in smtpd_recipient_restrictions (expect perhaps the permit mynetworks option), otherwise you could become an open relay for any of the domains listed with an OK. This also requires that all of the smtpd restrictions be placed into smtpd_recipient_restrictions as described at the end of the Main.cf Guide .

Note: Ralf Hildebrandt has put up a great set of pages on restriction classes. For more information, please see his site.

Leave a Reply

Your email address will not be published. Required fields are marked *