Home // Postfix Guides // Main.cf

Main.cf

SYSTEM CONFIGURATION (main.cf)
The main.cf file contains the majority of the system configuration options for Postfix. In this section, specific aspects or options available in the main.cf file will be listed, and their applicable anti-spam measures explained.

SASL2 & TLS
I would first like to make a point about authenticated SMTP (using SASL2) and TLS encryption. While this is not exactly an anti-spam measure, assuming that some persons (users) need to relay mail through your server, enabling authenticated smtp relaying can limit spammers’ abilities to use your server as an open relay. TLS encryption will prevent anyone in the middle (logically) of your users and mail server from being able to sniff (read/detect) information about mail being sent or passwords being used. For more information about SASL2 authentication and TLS encryption, please see the SASL2/TLS Guide.

THIRD PARTY FILTERS OR SCANNERS
If you will be using a third party filter or scanner that will be either listening on a port or running via a shell script, you will be using something like the following:

content_filter=smtp:[127.0.0.1]:10025
This will cause all email passing through Postfix to be forwarded to port 10025 on localhost (127.0.0.1). In theory, one would be running a process listening on port 10025 that would process incoming mail for spam or antivirus.

content_filter=spamfilter
This will cause all email passing through postfix to be forwarded to a process or script that is defined in master.cf as having the name spamfilter. More information about this can be found in the SYSTEM CONFIGURATION (master.cf) section below.

HEADER & BODY CHECKS
We discussed header and body checks earlier in ealier sections. In order to implement them, you will have to have the following two lines in your main.cf file:

header_checks = regexp:/etc/postfix/maps/header_checks
body_checks = regexp:/etc/postfix/maps/body_checks

RELAY DOMAINS
It is a good idea to keep a map file containing a list of the domains that you want to receive mail from. This can be implemented by adding the following line to postfix:

relay_domains = hash:/etc/postfix/maps/hosted_domains
Note: You will probably have more items listed in your relay_domains than just the map file. Most people will also have at least $mynetworks.

The format of the map file is as follows:
domain.extention #Comment

Example:
posluns.com #Jeff’s personal address domain

RFC 821
Many automated spam programs will not adhere to RFC 821. This RFC specifies the exact format in which an email should be transmitted. You can prohibit messages that do not conform to this specification by adding the following line to main.cf:

strict_rfc821_envelopes = yes

SMTPD CLIENT RESTRICTIONS
SMTPD client restrictions will put restrictions on what systems will be able to send mail through your server based on the client IP and host information (name). As restrictions are looked at in order, you will typically want to look at filters or restrictions that are based on local information first, in order to limit the external communications that will be initiated for each message.

In this example, we will first allow any host listed in the mynetworks file, then client access lists will be checked, and finally RBL checks which require remote communications will be initiated.

Note that this example only lists one RBL check. The RBL FILTERING section below will contain more information about these checks.

smtpd_client_restrictions =
permit_mynetworks,
check_client_access hash:/etc/postfix/maps/access_client,
reject_rbl_client rblserver.domain.extention,
reject_invalid_hostname,
permit

SMTPD HELO RESTRICTIONS
First, you will want to enforce the requirement for a helo to be sent for each message. Without a helo, you will not be able to perform any helo checks. You can do this by adding the following line to main.cf:

smtpd_helo_required = yes

SMTPD helo restrictions will put restrictions on what systems will be able to send mail through your server based on the helo identification string. As restrictions are looked at in order, you will typically want to look at filters or restrictions that are based on local information first, in order to limit the external communications (in this case DNS queries) that will be initiated for each message.

In this example, we will first allow any host listed in the mynetworks file, followed by a check of the helo access list, the verification of HELO to client domain (as described in the RESTRICTION CLASSES Guide), followed by a rejection of unauthorized pipelining, followed by a series of checks on the hostname of the sending system.

Note that you will probably see a fair number of false rejects on reject_non_fqdn_hostname and reject_invalid_hostname if the remote server or related DNS information is not configured properly.

smtpd_helo_restrictions =
permit_mynetworks,
check_helo_access hash:/etc/postfix/maps/access_helo,
check_helo_access hash:/etc/postfix/maps/verify_helo,
reject_unauth_pipelining,
reject_non_fqdn_hostname,
reject_unknown_hostname,
reject_invalid_hostname,
permit

SMTPD SENDER RESTRICTIONS
SMTPD sender restrictions will put restrictions on what addresses will be able to send mail through your server based on the sender email address. As restrictions are looked at in order, you will typically want to look at filters or restrictions that are based on local information first, in order to limit the external communications (in this case DNS queries) that will be initiated for each message.

In this example, we will first allow any host listed in the mynetworks file, followed by a check of the sender access lists for standard access list items, verify_domain, and verify_sender (as described in the RESTRICTION CLASSES Guide), followed by a rejection of non FQDN sender addresses and sender domains. Finally, the sender’s domain will be looked up to ensure that it complies to relevant email RFCs.

smtpd_sender_restrictions =
permit_mynetworks,
check_sender_access hash:/etc/postfix/maps/access_sender,
check_sender_access hash:/etc/postfix/maps/verify_domain,
check_sender_access hash:/etc/postfix/maps/verify_sender,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_rhsbl_sender dsn.rfc-ignorant.org,
permit

SMTPD RECIPIENT RESTRICTIONS
SMTPD recipient restrictions will put restrictions on what messages will be accepted into your server based on the recipient email address.

In this example, after the standard checks, we will allow emails sent by SASL authenticated users to pass through the system.

Note: This set of restrictions is the only one that will reject by default. The above listed restrictions will all permit messages through unless a restriction check fails. The reject_unauth_destination entry at the end of this list will reject all messages that are not going to authorized recipients of the mail server.

smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
check_recipient_access hash:/etc/postfix/maps/access_recipient,
reject_multi_recipient_bounce,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_sasl_authenticated

Note: As of the time of this writing (May 2003), the reject_multi_recipient_bounce feature is only available in snapshot code.

ORDERING SMTPD RESTRICTIONS
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.

This example contains a scenario of smtpd restrictions. Note that not all of the items in the list will apply to you, especially the access checks which are explained in theRESTRICTION CLASSES Guide.

smtpd_client_restrictions =

smtpd_helo_required = yes
smtpd_helo_restrictions =

smtpd_sender_restrictions =

smtpd_recipient_restrictions =

permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
# reject_unknown_client, # This can cause a lot of false rejects.
# reject_non_fqdn_hostname, # This can cause a lot of false rejects.
# reject_unknown_hostname, # This can cause a lot of false rejects.
reject_invalid_hostname,

check_client_access hash:/etc/postfix/maps/access_client,
check_client_access hash:/etc/postfix/maps/exceptions_client,
check_helo_access hash:/etc/postfix/maps/access_helo,
check_helo_access hash:/etc/postfix/maps/verify_helo,
check_sender_access hash:/etc/postfix/maps/access_sender,
check_sender_access hash:/etc/postfix/maps/verify_sender,
check_sender_access hash:/etc/postfix/maps/verify_domain,
check_recipient_access hash:/etc/postfix/maps/access_recipient,

reject_unauth_pipelining,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unverified_sender,
reject_multi_recipient_bounce,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unlisted_recipient,
check_policy_service unix:private/policy,

check_sender_access hash:/etc/postfix/maps/no_verify_sender,
reject_unverified_sender,
check_recipient_access hash:/etc/postfix/maps/no_verify_recipient,
reject_unverified_recipient

Note: The RBL and RHSBL checks have been removed from the end of this list, as they should all be performed by SpamAssassin. You may choose to reject all emails that are listed in an RBL or RHSBL, though weighted scoring systems have proven to reduce the number of false positive rejections. Note that using SpamAssassin instead of rejecting directly in main.cf will increase your system load as the full email will need to be accepted and analyzed instead of simply rejecting the email as soon as a matching header (IP or domain name) is caught.

Leave a Reply

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