summaryrefslogtreecommitdiffstats
path: root/README_FILES/SMTPD_ACCESS_README
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--README_FILES/SMTPD_ACCESS_README346
1 files changed, 346 insertions, 0 deletions
diff --git a/README_FILES/SMTPD_ACCESS_README b/README_FILES/SMTPD_ACCESS_README
new file mode 100644
index 0000000..230204a
--- /dev/null
+++ b/README_FILES/SMTPD_ACCESS_README
@@ -0,0 +1,346 @@
+PPoossttffiixx SSMMTTPP rreellaayy aanndd aacccceessss ccoonnttrrooll
+
+-------------------------------------------------------------------------------
+
+IInnttrroodduuccttiioonn
+
+The Postfix SMTP server receives mail from the network and is exposed to the
+big bad world of junk email and viruses. This document introduces the built-in
+and external methods that control what SMTP mail Postfix will accept, what
+mistakes to avoid, and how to test your configuration.
+
+Topics covered in this document:
+
+ * Relay control, junk mail control, and per-user policies
+ * Restrictions that apply to all SMTP mail
+ * Getting selective with SMTP access restriction lists
+ * Delayed evaluation of SMTP access restriction lists
+ * Dangerous use of smtpd_recipient_restrictions
+ * SMTP access rule testing
+
+RReellaayy ccoonnttrrooll,, jjuunnkk mmaaiill ccoonnttrrooll,, aanndd ppeerr--uusseerr ppoolliicciieess
+
+In a distant past, the Internet was a friendly environment. Mail servers
+happily forwarded mail on behalf of anyone towards any destination. On today's
+Internet, spammers abuse servers that forward mail from arbitrary systems, and
+abused systems end up on anti-spammer blacklists. See, for example, the
+information on http://www.mail-abuse.org/ and other websites.
+
+By default, Postfix has a moderately restrictive approach to mail relaying.
+Postfix forwards mail only from clients in trusted networks, from clients that
+have authenticated with SASL, or to domains that are configured as authorized
+relay destinations. For a description of the default mail relay policy, see the
+smtpd_relay_restrictions parameter in the postconf(5) manual page, and the
+information that is referenced from there.
+
+ NOTE: Postfix versions before 2.10 did not have smtpd_relay_restrictions.
+ They combined the mail relay and spam blocking policies, under
+ smtpd_recipient_restrictions. This could lead to unexpected results. For
+ example, a permissive spam blocking policy could unexpectedly result in a
+ permissive mail relay policy. An example of this is documented under
+ "Dangerous use of smtpd_recipient_restrictions".
+
+Most of the Postfix SMTP server access controls are targeted at stopping junk
+email.
+
+ * Protocol oriented: some SMTP server access controls block mail by being
+ very strict with respect to the SMTP protocol; these catch poorly
+ implemented and/or poorly configured junk email software, as well as email
+ worms that come with their own non-standard SMTP client implementations.
+ Protocol-oriented access controls become less useful over time as spammers
+ and worm writers learn to read RFC documents.
+
+ * Blacklist oriented: some SMTP server access controls query blacklists with
+ known to be bad sites such as open mail relays, open web proxies, and home
+ computers that have been compromised and that are under remote control by
+ criminals. The effectiveness of these blacklists depends on how complete
+ and how up to date they are.
+
+ * Threshold oriented: some SMTP server access controls attempt to raise the
+ bar by either making the client do more work (greylisting) or by asking for
+ a second opinion (SPF and sender/recipient address verification). The
+ greylisting and SPF policies are implemented externally, and are the
+ subject of the SMTPD_POLICY_README document. Sender/recipient address
+ verification is the subject of the ADDRESS_VERIFICATION_README document.
+
+Unfortunately, all junk mail controls have the possibility of falsely rejecting
+legitimate mail. This can be a problem for sites with many different types of
+users. For some users it is unacceptable when any junk email slips through,
+while for other users the world comes to an end when a single legitimate email
+message is blocked. Because there is no single policy that is "right" for all
+users, Postfix supports different SMTP access restrictions for different users.
+This is described in the RESTRICTION_CLASS_README document.
+
+RReessttrriiccttiioonnss tthhaatt aappppllyy ttoo aallll SSMMTTPP mmaaiill
+
+Besides the restrictions that can be made configurable per client or per user
+as described in the next section, Postfix implements a few restrictions that
+apply to all SMTP mail.
+
+ * The built-in header_checks and body_checks content restrictions, as
+ described in the BUILTIN_FILTER_README document. This happens while Postfix
+ receives mail, before it is stored in the incoming queue.
+
+ * The external before-queue content restrictions, as described in the
+ SMTPD_PROXY_README document. This happens while Postfix receives mail,
+ before it is stored in the incoming queue.
+
+ * Requiring that the client sends the HELO or EHLO command before sending the
+ MAIL FROM or ETRN command. This may cause problems with home-grown
+ applications that send mail. For this reason, the requirement is disabled
+ by default ("smtpd_helo_required = no").
+
+ * Disallowing illegal syntax in MAIL FROM or RCPT TO commands. This may cause
+ problems with home-grown applications that send mail, and with ancient PC
+ mail clients. For this reason, the requirement is disabled by default
+ ("strict_rfc821_envelopes = no").
+
+ o Disallowing RFC 822 address syntax (example: "MAIL FROM: the dude
+ <dude@example.com>").
+
+ o Disallowing addresses that are not enclosed with <> (example: "MAIL
+ FROM: dude@example.com").
+
+ * Rejecting mail from a non-existent sender address. This form of egress
+ filtering helps to slow down worms and other malware, but may cause
+ problems with home-grown software that sends out mail software with an
+ unreplyable address. For this reason the requirement is disabled by default
+ ("smtpd_reject_unlisted_sender = no").
+
+ * Rejecting mail for a non-existent recipient address. This form of ingress
+ filtering helps to keep the mail queue free of undeliverable MAILER-DAEMON
+ messages. This requirement is enabled by default
+ ("smtpd_reject_unlisted_recipient = yes").
+
+GGeettttiinngg sseelleeccttiivvee wwiitthh SSMMTTPP aacccceessss rreessttrriiccttiioonn lliissttss
+
+Postfix allows you to specify lists of access restrictions for each stage of
+the SMTP conversation. Individual restrictions are described in the postconf(5)
+manual page.
+
+Examples of simple restriction lists are:
+
+/etc/postfix/main.cf:
+ # Allow connections from trusted networks only.
+ smtpd_client_restrictions = permit_mynetworks, reject
+
+ # Don't talk to mail systems that don't know their own hostname.
+ # With Postfix < 2.3, specify reject_unknown_hostname.
+ smtpd_helo_restrictions = reject_unknown_helo_hostname
+
+ # Don't accept mail from domains that don't exist.
+ smtpd_sender_restrictions = reject_unknown_sender_domain
+
+ # Spam control: exclude local clients and authenticated clients
+ # from DNSBL lookups.
+ smtpd_recipient_restrictions = permit_mynetworks,
+ permit_sasl_authenticated,
+ # reject_unauth_destination is not needed here if the mail
+ # relay policy is specified under smtpd_relay_restrictions
+ # (available with Postfix 2.10 and later).
+ reject_unauth_destination
+ reject_rbl_client zen.spamhaus.org,
+ reject_rhsbl_reverse_client dbl.spamhaus.org,
+ reject_rhsbl_helo dbl.spamhaus.org,
+ reject_rhsbl_sender dbl.spamhaus.org
+
+ # Relay control (Postfix 2.10 and later): local clients and
+ # authenticated clients may specify any destination domain.
+ smtpd_relay_restrictions = permit_mynetworks,
+ permit_sasl_authenticated,
+ reject_unauth_destination
+
+ # Block clients that speak too early.
+ smtpd_data_restrictions = reject_unauth_pipelining
+
+ # Enforce mail volume quota via policy service callouts.
+ smtpd_end_of_data_restrictions = check_policy_service unix:private/policy
+
+Each restriction list is evaluated from left to right until some restriction
+produces a result of PERMIT, REJECT or DEFER (try again later). The end of each
+list is equivalent to a PERMIT result. By placing a PERMIT restriction before a
+REJECT restriction you can make exceptions for specific clients or users. This
+is called whitelisting; the fourth example above allows mail from local
+networks but otherwise rejects mail to arbitrary destinations.
+
+The table below summarizes the purpose of each SMTP access restriction list.
+All lists use the exact same syntax; they differ only in the time of evaluation
+and in the effect of a REJECT or DEFER result.
+
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ | | | |EEffffeecctt ooff |
+ |RReessttrriiccttiioonn lliisstt nnaammee |VVeerrssiioonn|SSttaattuuss |RREEJJEECCTT oorr |
+ | | | |DDEEFFEERR |
+ | | | |rreessuulltt |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ | | | |Reject all |
+ |smtpd_client_restrictions |All |Optional |client |
+ | | | |commands |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ | | | |Reject |
+ |smtpd_helo_restrictions |All |Optional |HELO/EHLO |
+ | | | |information|
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ | | | |Reject MAIL|
+ |smtpd_sender_restrictions |All |Optional |FROM |
+ | | | |information|
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ | | |Required if | |
+ | |>= 2.10|smtpd_relay_restrictions | |
+ | | |does not enforce relay |Reject RCPT|
+ |smtpd_recipient_restrictions | |policy |TO |
+ | |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |information|
+ | | | | |
+ | |< 2.10 |Required | |
+ | | | | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ | | |Required if | |
+ | |>= 2.10|smtpd_recipient_restrictions| |
+ | | |does not enforce relay |Reject RCPT|
+ |smtpd_relay_restrictions | |policy |TO |
+ | |_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |information|
+ | | | | |
+ | |< 2.10 |Not available | |
+ | | | | |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ |smtpd_data_restrictions |>= 2.0 |Optional |Reject DATA|
+ | | | |command |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ | | | |Reject END-|
+ |smtpd_end_of_data_restrictions|>= 2.2 |Optional |OF-DATA |
+ | | | |command |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+ |smtpd_etrn_restrictions |All |Optional |Reject ETRN|
+ | | | |command |
+ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ |
+
+DDeellaayyeedd eevvaalluuaattiioonn ooff SSMMTTPP aacccceessss rreessttrriiccttiioonn lliissttss
+
+Early Postfix versions evaluated SMTP access restrictions lists as early as
+possible. The client restriction list was evaluated before Postfix sent the
+"220 $myhostname..." greeting banner to the SMTP client, the helo restriction
+list was evaluated before Postfix replied to the HELO (EHLO) command, the
+sender restriction list was evaluated before Postfix replied to the MAIL FROM
+command, and so on. This approach turned out to be difficult to use.
+
+Current Postfix versions postpone the evaluation of client, helo and sender
+restriction lists until the RCPT TO or ETRN command. This behavior is
+controlled by the smtpd_delay_reject parameter. Restriction lists are still
+evaluated in the proper order of (client, helo, etrn) or (client, helo, sender,
+relay, recipient, data, or end-of-data) restrictions. When a restriction list
+(example: client) evaluates to REJECT or DEFER the restriction lists that
+follow (example: helo, sender, etc.) are skipped.
+
+Around the time that smtpd_delay_reject was introduced, Postfix was also
+changed to support mixed restriction lists that combine information about the
+client, helo, sender and recipient or etrn command.
+
+Benefits of delayed restriction evaluation, and of restriction mixing:
+
+ * Some SMTP clients do not expect a negative reply early in the SMTP session.
+ When the bad news is postponed until the RCPT TO reply, the client goes
+ away as it is supposed to, instead of hanging around until a timeout
+ happens, or worse, going into an endless connect-reject-connect loop.
+
+ * Postfix can log more useful information. For example, when Postfix rejects
+ a client name or address and delays the action until the RCPT TO command,
+ it can log the sender and the recipient address. This is more useful than
+ logging only the client hostname and IP address and not knowing whose mail
+ was being blocked.
+
+ * Mixing is needed for complex whitelisting policies. For example, in order
+ to reject local sender addresses in mail from non-local clients, you need
+ to be able to mix restrictions on client information with restrictions on
+ sender information in the same restriction list. Without this ability, many
+ per-user access restrictions would be impossible to express.
+
+DDaannggeerroouuss uussee ooff ssmmttppdd__rreecciippiieenntt__rreessttrriiccttiioonnss
+
+By now the reader may wonder why we need smtpd client, helo or sender
+restrictions, when their evaluation is postponed until the RCPT TO or ETRN
+command. Some people recommend placing ALL the access restrictions in the
+smtpd_recipient_restrictions list. Unfortunately, this can result in too
+permissive access. How is this possible?
+
+The purpose of the smtpd_recipient_restrictions feature is to control how
+Postfix replies to the RCPT TO command. If the restriction list evaluates to
+REJECT or DEFER, the recipient address is rejected; no surprises here. If the
+result is PERMIT, then the recipient address is accepted. And this is where
+surprises can happen.
+
+The problem is that Postfix versions before 2.10 did not have
+smtpd_relay_restrictions. They combined the mail relay and spam blocking
+policies, under smtpd_recipient_restrictions. The result is that a permissive
+spam blocking policy could unexpectedly result in a permissive mail relay
+policy.
+
+Here is an example that shows when a PERMIT result can result in too much
+access permission:
+
+1 /etc/postfix/main.cf:
+2 smtpd_recipient_restrictions =
+3 permit_mynetworks
+4 check_helo_access hash:/etc/postfix/helo_access
+5 reject_unknown_helo_hostname
+6 rreejjeecctt__uunnaauutthh__ddeessttiinnaattiioonn
+7
+8 /etc/postfix/helo_access:
+9 localhost.localdomain PERMIT
+
+Line 5 rejects mail from hosts that don't specify a proper hostname in the HELO
+command (with Postfix < 2.3, specify reject_unknown_hostname). Lines 4 and 9
+make an exception to allow mail from some machine that announces itself with
+"HELO localhost.localdomain".
+
+The problem with this configuration is that smtpd_recipient_restrictions
+evaluates to PERMIT for EVERY host that announces itself as
+"localhost.localdomain", making Postfix an open relay for all such hosts.
+
+With Postfix before version 2.10 you should place non-recipient restrictions
+AFTER the reject_unauth_destination restriction, not before. In the above
+example, the HELO based restrictions should be placed AFTER
+reject_unauth_destination, or better, the HELO based restrictions should be
+placed under smtpd_helo_restrictions where they can do no harm.
+
+1 /etc/postfix/main.cf:
+2 smtpd_recipient_restrictions =
+3 permit_mynetworks
+4 rreejjeecctt__uunnaauutthh__ddeessttiinnaattiioonn
+5 check_helo_access hash:/etc/postfix/helo_access
+6 reject_unknown_helo_hostname
+7
+8 /etc/postfix/helo_access:
+9 localhost.localdomain PERMIT
+
+The above mistake will not happen with Postfix 2.10 and later, when the relay
+policy is specified under smtpd_relay_restrictions, and the spam blocking
+policy under smtpd_recipient_restrictions. Then, a permissive spam blocking
+policy will not result in a permissive mail relay policy.
+
+SSMMTTPP aacccceessss rruullee tteessttiinngg
+
+Postfix has several features that aid in SMTP access rule testing:
+
+soft_bounce
+ This is a safety net that changes SMTP server REJECT actions into DEFER
+ (try again later) actions. This keeps mail queued that would otherwise be
+ returned to the sender. Specify "soft_bounce = yes" in the main.cf file to
+ prevent the Postfix SMTP server from rejecting mail permanently, by
+ changing all 5xx SMTP reply codes into 4xx.
+
+warn_if_reject
+ When placed before a reject-type restriction, access table query, or
+ check_policy_service query, this logs a "reject_warning" message instead of
+ rejecting a request (when a reject-type restriction fails due to a
+ temporary error, this logs a "reject_warning" message for any implicit
+ "defer_if_permit" actions that would normally prevent mail from being
+ accepted by some later access restriction). This feature has no effect on
+ defer_if_reject restrictions.
+
+XCLIENT
+ With this feature, an authorized SMTP client can impersonate other systems
+ and perform realistic SMTP access rule tests. Examples of how to
+ impersonate other systems for access rule testing are given at the end of
+ the XCLIENT_README document.
+ This feature is available in Postfix 2.1.
+