/etc/postfix/main.cf
configuration file.
mail.falcot.com
. This is the only question asked by default, but the configuration it leads to is not complete enough for the needs of Falcot, which is why the administrators run dpkg-reconfigure postfix
so as to be able to customize more parameters.
localhost
, but the main falcot.com
domain needs to be added by hand. More generally, this question should usually be answered with all the domain names for which this machine should serve as an MX server; in other words, all the domain names for which the DNS says this machine will accept email. This information ends up in the mydestination
variable of the main Postfix configuration file, /etc/postfix/main.cf
.
192.168.0.0/16
to the default answer. If the question is not asked, the relevant variable in the configuration file is mynetworks
, as seen in the example below.
procmail
. This tool allows users to sort their incoming email according to rules stored in their ~/.procmailrc
file.
Example 11.1. Initial /etc/postfix/main.cf
file
# See /usr/share/postfix/main.cf.dist for a commented, more complete version # Debian specific: Specifying a file name will cause the first # line of that file to be used as the name. The Debian default # is /etc/mailname. #myorigin = /etc/mailname smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no # appending .domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h # TLS parameters smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache # See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # information on enabling SSL in the smtp client. myhostname = mail.falcot.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = mail.falcot.com, falcot.com, localhost, localhost.localdomain relayhost = mynetworks = 127.0.0.0/8 192.168.0.0/16 mailbox_command = procmail -a "$EXTENSION" mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all inet_protocols = all
virtual_alias_domains
variable, and referencing an address mapping file in the virtual_alias_maps
variable.
Example 11.2. Directives to add in the /etc/postfix/main.cf
file
virtual_alias_domains = falcotsbrand.tm.fr virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual
file describes mapping with a rather straightforward syntax: each line contains two fields separated by whitespace; the first field is the alias name, the second field is a list of email addresses where it redirects. The special @domain.tm.fr
syntax covers all remaining aliases in a domain.
Example 11.3. Example /etc/postfix/virtual
file
webmaster@falcotsbrand.tm.fr jean@falcot.com contact@falcotsbrand.tm.fr laure@falcot.com, sophie@falcot.com # The alias below is generic and covers all addresses within # the falcotsbrand.tm.fr domain not otherwise covered by this file. # These addresses forward email to the same user name in the # falcot.com domain. @falcotsbrand.tm.fr @falcot.com
virtual_mailbox_domains
variable, and referencing a mailbox mapping file in virtual_mailbox_maps
. The virtual_mailbox_base
parameter contains the directory under which the mailboxes will be stored.
virtual_uid_maps
parameter (respectively virtual_gid_maps
) references the file containing the mapping between the email address and the system user (respectively group) that “owns” the corresponding mailbox. To get all mailboxes owned by the same owner/group, the syntax is static:5000
.
Example 11.4. Directives to add in the /etc/postfix/main.cf
file
virtual_mailbox_domains = falcot.org virtual_mailbox_maps = hash:/etc/postfix/vmailbox virtual_mailbox_base = /var/mail/vhosts
/etc/postfix/vmailbox
file is quite straightforward: two fields separated with whitespace. The first field is an email address within one of the virtual domains, and the second field is the location of the associated mailbox (relative to the directory specified in virtual_mailbox_base). If the mailbox name ends with a slash (/
), the emails will be stored in the maildir format; otherwise, the traditional mbox format will be used. The maildir format uses a whole directory to store a mailbox, each individual message being stored in a separate file. In the mbox format, on the other hand, the whole mailbox is stored in one file, and each line starting with “From
” (From
followed by a space) signals the start of a new message.
Example 11.5. The /etc/postfix/vmailbox
file
# Jean's email is stored as maildir, with # one file per email in a dedicated directory jean@falcot.org falcot.org/jean/ # Sophie's email is stored in a traditional "mbox" file, # with all mails concatenated into one single file sophie@falcot.org falcot.org/sophie
smtpd_client_restrictions
directive controls which machines are allowed to communicate with the email server.
Example 11.6. Restrictions Based on Client Address
smtpd_client_restrictions = permit_mynetworks, warn_if_reject reject_unknown_client, check_client_access hash:/etc/postfix/access_clientip, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client list.dsbl.org
permit_mynetworks
directive, used as the first rule, accepts all emails coming from a machine in the local network (as defined by the mynetworks configuration variable).
warn_if_reject
modifier to the reject_unknown_client
directive: this modifier turns the rejection into a simple warning recorded in the logs. The administrators can then keep an eye on the number of messages that would be rejected if the rule were actually enforced, and make an informed decision later if they wish to enable such enforcement.
/etc/postfix/access_clientip
file. Servers in the white list are considered as trusted, and the emails coming from there therefore do not go through the following filtering rules.
HELO
(or EHLO
) command, followed by the name of the sending email server; checking the validity of this name can be interesting.
Example 11.7. Restrictions on the name announced in EHLO
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, check_helo_access hash:/etc/postfix/access_helo, reject_non_fqdn_hostname, warn_if_reject reject_unknown_hostname
permit_mynetworks
directive allows all machines on the local network to introduce themselves freely. This is important, because some email programs do not respect this part of the SMTP protocol adequately enough, and they can introduce themselves with nonsensical names.
reject_invalid_hostname
rule rejects emails when the EHLO
announce lists a syntactically incorrect hostname. The reject_non_fqdn_hostname
rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The reject_unknown_hostname
rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to too many rejections, the administrators turned its effect to a simple warning with the warn_if_reject
modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule.
permit_mynetworks
as the first rule has an interesting side effect: the following rules only apply to hosts outside the local network. This allows blacklisting all hosts that announce themselves as part of the falcot.com
, for instance by adding a falcot.com REJECT You're not in our network!
line to the /etc/postfix/access_helo
file.
MAIL FROM
command of the SMTP protocol; again, this information can be validated in several different ways.
Example 11.8. Sender checks
smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/access_sender, reject_unknown_sender_domain, reject_unlisted_sender, reject_non_fqdn_sender
/etc/postfix/access_sender
table maps some special treatment to some senders. This usually means listing some senders into a white list or a black list.
reject_unknown_sender_domain
rule requires a valid sender domain, since it is needed for a valid address. The reject_unlisted_sender
rule rejects local senders if the address does not exist; this prevents emails from being sent from an invalid address in the falcot.com
domain, and messages emanating from joe.bloggs@falcot.com
are only accepted if such an address really exists.
reject_non_fqdn_sender
rule rejects emails purporting to come from addresses without a fully-qualified domain name. In practice, this means rejecting emails coming from user@machine
: the address must be announced as either user@machine.example.com
or user@example.com
.
RCPT TO
command in the SMTP protocol. These addresses also warrant validation, even if that may be less relevant than the checks made on the sender address.
Example 11.9. Recipient checks
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient, reject_non_fqdn_recipient
reject_unauth_destination
is the basic rule that requires outside messages to be addressed to us; messages sent to an address not served by this server are rejected. Without this rule, a server becomes an open relay that allows spammers to sent unsolicited emails; this rule is therefore strongly recommended, and it will be located near the beginning of the list for preference, so as to avoid other rules to authorize the message to pass through before its destination has been checked.
reject_unlisted_recipient
rule rejects messages sent to non-existing local users, which makes sense. Finally, the reject_non_fqdn_recipient
rule rejects non-fully-qualified addresses; this makes it impossible to send an email to jean
or jean@machine
, and requires using the full address instead, such as jean@machine.falcot.com
or jean@falcot.com
.
DATA
command of SMTP is emitted before the contents of the message. It doesn't provide any information per se, apart from announcing what comes next. It can still be subjected to checks.
reject_unauth_pipelining
directives causes the message to be rejected if the sending party sends a command before the reply to the previous command has been sent. This guards against a common optimization used by spammer robots, since they usually don't care a fig about replies and only focus on sending as many emails as possible in as short a time as possible.
RCPT TO
command.
EHLO
command, Postfix knows the sender and the recipient when announcing the rejection. It can then log a more explicit message than it could if the transaction had been interrupted from the start. In addition, a number of SMTP clients do not expect failures on the early SMTP commands, and these clients will be less disturbed by this late rejection.
Example 11.11. Enabling content-based filters
header_checks = regexp:/etc/postfix/header_checks body_checks = regexp:/etc/postfix/body_checks
Example 11.12. Example /etc/postfix/header_checks
file
/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane) /^Subject: *Your email contains VIRUSES/ DISCARD virus notification
GOTO Sarbacane
(a bulk email software) is found, the message is rejected. The second expression controls the message subject; if it mentions a virus notification, we can decide not to reject the message but to discard it immediately instead.
check_policy_service
parameter as an extra restriction:
smtpd_recipient_restrictions = permit_mynetworks, [...] check_policy_service inet:127.0.0.1:60000
postgrey
daemon and send it information concerning the relevant message. On its side, Postgrey considers the IP address/sender/recipient triplet and checks in its database whether that same triplet has been seen recently. If so, Postgrey replies that the message should be accepted; if not, the reply indicates that the message should be temporarily rejected, and the triplet gets recorded in the database.
smtpd_restriction_classes
parameter, and defined the same way as smtpd_recipient_restrictions
. The check_recipient_access
directive then defines a table mapping a given recipient to the appropriate set of restrictions.
Example 11.13. Defining restriction classes in main.cf
smtpd_restriction_classes = greylisting, aggressive, permissive greylisting = check_policy_service inet:127.0.0.1:10000, check_policy_service inet:127.0.0.1:60000 aggressive = reject_rbl_client sbl-xbl.spamhaus.org, check_policy_service inet:127.0.0.1:60000 permissive = permit smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access hash:/etc/postfix/recipient_access
Example 11.14. The /etc/postfix/recipient_access
file
# Unfiltered addresses postmaster@falcot.com permissive support@falcot.com permissive sales-asia@falcot.com permissive # Aggressive filtering for some privileged users joe@falcot.com aggressive # Special rule for the mailing-list manager sympa@falcot.com reject_unverified_sender # Greylisting by default falcot.com greylisting
clamav
for their free antivirus. The main package is clamav, but they also installed a few extra packages such as arj, unzoo, unrar and lha, since they are required for the antivirus to analyze attachments archived in one of these formats.
clamav-milter
. A milter (short for mail filter) is a filtering program specially designed to interface with email servers. A milter uses a standard application programming interface (API) that provides much better performance than filters external to the email servers. Milters were initially introduced by Sendmail, but Postfix soon followed suit.
/etc/default/clamav-milter
file must be edited, so that the milter is configured to run on a TCP port rather than on the default named socket:
SOCKET=inet:10002@127.0.0.1
/etc/init.d/clamav-milter restart
.
dpkg-reconfigure clamav-base
. Similarly, running dpkg-reconfigure clamav-milter
allows defining the mail filter's behavior in some detail.
/etc/postfix/main.cf
:
# Virus check with clamav-milter smtpd_milters = inet:[127.0.0.1]:10002
/etc/init.d/postfix reload
should be run so that this change is taken into account.
saslpasswd2
command, which takes several parameters. The -u
option defines the authentication domain, which must match the smtpd_sasl_local_domain
parameter in the Postfix configuration. The -c
option allows creating a user, and -f
allows specifying the file to use if the SASL database needs to be stored at a different location than the default (/etc/sasldb2
).
#
saslpasswd2 -h `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean
[... type jean's password twice ...]
/etc/sasldb2
into a symbolic link pointing at the database used by Postfix, with the ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2
command.
postfix
user needs to be added to the sasl
group, so that it can access the SASL account database. A few new parameters are also needed to enable SASL, and the smtpd_recipient_restrictions
parameter needs to be configured to allow SASL-authenticated clients to send emails freely.
Example 11.15. Enabling SASL in /etc/postfix/main.cf
# Enable SASL authentication smtpd_sasl_auth_enable = yes # Define the SASL authentication domain to use smtpd_sasl_local_domain = $myhostname [...] # Adding permit_sasl_authenticated before reject_unauth_destination # allows relaying mail sent by SASL-authenticated users smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, [...]