Recipe 21.4. Basic UBE Configurations for Postfix
21.4.1 Problem
You want to block as much spam
at the SMTP level as possible to minimize the load on your server, so
you need to know some basic checks to add to
/etc/postfix/main.cf.
21.4.2 Solution
Add these checks, or some of these checks, to
/etc/postfix/main.cf:
smtpd_helo_required = yes
disable_vrfy_command = yes
smtpd_recipient_restrictions =
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_pipelining,
permit_mynetworks,
reject_unauth_destination
Always run postfix reload after making changes
to main.cf.
With the exception of the last three lines, which are safe and should
always be used, you don't have to use all of these
directives. See the "Discussion"
section of this recipe to find out what the directives do—they
are not specific to spammers, but will also reject mail from
misconfigured mail servers, which are all too common.
21.4.3 Discussion
These directives are for Postfix version 2.0 and newer; the syntax
for 1.x is different. It is important to keep Postfix upgraded to the
latest stable version, to get security and performance updates.
Be sure to follow Recipe Recipe 21.3 for the
correct, nondestructive testing procedures.
Here's a rundown of what the
/etc/postfix/main.cf settings mean. To learn
more about the SMTP commands and transaction sequence, read RFC 2821
and Recipe Recipe 20.19.
- smtpd_helo_required = yes
-
Require the client to send the HELO or EHLO command before sending
the MAIL FROM or ETRN command. Many spammers play dumb tricks with
HELO, so this will get rid of them.
- disable_vrfy_command = yes
-
Do not allow remote servers to verify local addresses. Only spammers
care about this.
- smtpd_recipient_restrictions =
-
This operates on the RCPT TO command. By default, Postfix delays all
reject actions until after RCPT TO, so for the sake of simplicity and
clarity, you can put most of your UBE controls here. Postfix makes
these checks, in order:
smtpd_client_restrictions smtpd_helo_restrictions smtpd_sender_restrictions smtpd_recipient_restrictions smtpd_data_restrictions
Not surprisingly, these checks follow the order of SMTP transactions.
- reject_invalid_hostname
-
Reject when the client HELO/EHLO uses improper hostname syntax.
Spammers often play tricks with HELO/EHLO.
- reject_non_fqdn_hostname
-
Reject when the fully-qualified domain name is not used. Spammers
often use "localhost" or a fake IP
address in place of the FQDN.
- reject_non_fqdn_sender
-
Reject when the sender's domain in MAIL FROM is not
in FQDN form.
- reject_non_fqdn_recipient
-
Reject when the address in the client RCPT TO command is not in FQDN
form.
- reject_unknown_sender_domain
-
Reject when the sender's mail address has no DNS A
or MX record; it's probably a fake.
- reject_unknown_recipient_domain
-
Reject when the recipient mail address has no DNS A or MX record;
it's probably a fake.
- reject_unauth_pipelining
-
Foil spammers who would use pipelining to speed delivery of their
garbage (especially dictionary attacks).
- permit_mynetworks
-
Permit when the client address matches any network listed in
$mynetworks.
- reject_unauth_destination
-
Reject unless the recipient is in your domain. This is determined by
checking that one of the following is true:
RCPT TO matches $relay_domains or a subdomain RCPT TO matches $mydestination,
$inet_interfaces,
$proxy_interfaces,
$virtual_alias_domains, or
$virtual_mailbox_domains. This prevents some
spoofing and all unauthorized relaying.
Running a mail server is a complex, tricky affair, and not all mail
admins are as well trained as they should be. Because it is common
for mail servers to be misconfigured, and because Postfix
can't tell the difference between misconfigured
servers and spammers, you may find that trying to implement UBE
controls at this level is more trouble than it's
worth.
21.4.4 See Also
|