Postfix SMTP relay and access control (2024)

Introduction

The Postfix SMTP server receives mail from the network and isexposed to the big bad world of junk email and viruses. This documentintroduces the built-in and external methods that control what SMTPmail Postfix will accept, what mistakes to avoid, and how to testyour configuration.

Topics covered in this document:

• Relay control, junk mail control, and per-userpolicies
• Restrictions that apply to all SMTP mail
• Getting selective with SMTP access restrictionlists
• Delayed evaluation of SMTP access restriction lists
• Dangerous use of smtpd_recipient_restrictions
• SMTP access rule testing

Relay control, junk mail control, and per-userpolicies

In a distant past, the Internet was a friendly environment.Mail servers happily forwarded mail on behalf of anyone towardsany destination. On today's Internet, spammers abuse servers thatforward mail from arbitrary systems, and abused systems end up onanti-spammer denylists. See, for example, the information onhttp://www.mail-abuse.org/ and other websites.

By default, Postfix has a moderately restrictive approach tomail relaying. Postfix forwards mail only from clients in trustednetworks, from clients that have authenticated with SASL, or todomains that are configured as authorized relaydestinations. For a description of the default mail relay policy,see the smtpd_relay_restrictions parameter in the postconf(5) manualpage, and the information that is referenced from there.

NOTE: Postfix versions before 2.10 did not havesmtpd_relay_restrictions. They combined the mail relay and spamblocking policies, under smtpd_recipient_restrictions. This couldlead to unexpected results. For example, a permissive spam blockingpolicy could unexpectedly result in a permissive mail relay policy.An example of this is documented under "Dangeroususe of smtpd_recipient_restrictions".

Most of the Postfix SMTP server access controls are targetedat stopping junk email.

• Protocol oriented: some SMTP server access controls blockmail by being very strict with respect to the SMTP protocol; thesecatch poorly implemented and/or poorly configured junk emailsoftware, as well as email worms that come with their own non-standardSMTP client implementations. Protocol-oriented access controlsbecome less useful over time as spammers and worm writers learn toread RFC documents.

• Denylist oriented: some SMTP server access controlsquery denylists with known to be bad sites such as open mailrelays, open web proxies, and home computers that have beencompromised and that are under remote control by criminals. Theeffectiveness of these denylists depends on how complete and howup to date they are.

• Threshold oriented: some SMTP server access controls attemptto raise the bar by either making the client do more work (greylisting)or by asking for a second opinion (SPF and sender/recipient addressverification). The greylisting and SPF policies are implementedexternally, and are the subject of the SMTPD_POLICY_README document.Sender/recipient address verification is the subject of theADDRESS_VERIFICATION_README document.

Unfortunately, all junk mail controls have the possibility offalsely rejecting legitimate mail. This can be a problem for siteswith many different types of users. For some users it is unacceptablewhen any junk email slips through, while for other users the worldcomes 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 differentusers. This is described in the RESTRICTION_CLASS_README document.

Restrictions that apply to all SMTP mail

Besides the restrictions that can be made configurable perclient or per user as described in the next section, Postfiximplements a few restrictions that apply to all SMTP mail.

• The built-in header_checks and body_checks contentrestrictions, as described in the BUILTIN_FILTER_README document.This happens while Postfix receives mail, before it is stored inthe incoming queue.

• The external before-queue content restrictions, as describedin the SMTPD_PROXY_README document. This happens while Postfixreceives mail, before it is stored in the incoming queue.

• Requiring that the client sends the HELO or EHLO commandbefore sending the MAIL FROM or ETRN command. This may cause problemswith home-grown applications that send mail. For this reason, therequirement 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 sendmail, and with ancient PC mail clients. For this reason, therequirement is disabled by default ("strict_rfc821_envelopes =no").

  • Disallowing RFC 822 address syntax (example: "MAIL FROM: thedude <dude@example.com>").

  • Disallowing addresses that are not enclosed with <>(example: "MAIL FROM: dude@example.com").

• Rejecting mail from a non-existent sender address. This formof egress filtering helps to slow down worms and other malware, butmay cause problems with home-grown software that sends out mailsoftware with an unreplyable address. For this reason the requirementis disabled by default ("smtpd_reject_unlisted_sender = no").

• Rejecting mail for a non-existent recipient address. Thisform of ingress filtering helps to keep the mail queue free ofundeliverable MAILER-DAEMON messages. This requirement is enabledby default ("smtpd_reject_unlisted_recipient = yes").

Getting selective with SMTP access restrictionlists

Postfix allows you to specify lists of access restrictions foreach stage of the SMTP conversation. Individual restrictions aredescribed 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 untilsome restriction produces a result of PERMIT, REJECT or DEFER (tryagain later). The end of each list is equivalent to a PERMIT result.By placing a PERMIT restriction before a REJECT restriction youcan make exceptions for specific clients or users. This is calledallowlisting; the smtpd_relay_restrictions example above allows mail from localnetworks, and from SASL authenticated clients, but otherwise rejects mailto arbitrary destinations.

The table below summarizes the purpose of each SMTP accessrestriction list. All lists use the exact same syntax; they differonly in the time of evaluation and in the effect of a REJECT orDEFER result.

Restriction list name	Version	Status	Effectof REJECT or DEFER result
smtpd_client_restrictions	All	Optional	Reject all client commands
smtpd_helo_restrictions	All	Optional	Reject HELO/EHLO information
smtpd_sender_restrictions	All	Optional	Reject MAIL FROM information
smtpd_recipient_restrictions	≥2.10	Required if smtpd_relay_restrictions does not enforcerelay policy	Reject RCPT TO information
	< 2.10	Required
smtpd_relay_restrictions	≥ 2.10	Required if smtpd_recipient_restrictions does not enforcerelay policy	Reject RCPT TO information
	< 2.10	Not available
smtpd_data_restrictions	≥ 2.0	Optional	Reject DATA command
smtpd_end_of_data_restrictions	≥ 2.2	Optional	Reject END-OF-DATA command
smtpd_etrn_restrictions	All	Optional	Reject ETRN command

Delayed evaluation of SMTP access restriction lists

Early Postfix versions evaluated SMTP access restrictions listsas early as possible. The client restriction list was evaluatedbefore Postfix sent the "220 $myhostname..." greeting banner tothe SMTP client, the helo restriction list was evaluated beforePostfix replied to the HELO (EHLO) command, the sender restrictionlist 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, orend-of-data) restrictions.When a restriction list (example: client) evaluates to REJECT orDEFER the restriction lists that follow (example: helo, sender, etc.)are skipped.

Around the time that smtpd_delay_reject was introduced, Postfixwas also changed to support mixed restriction lists that combineinformation about the client, helo, sender and recipient or etrncommand.

Benefits of delayed restriction evaluation, and of restrictionmixing:

• Some SMTP clients do not expect a negative reply early inthe SMTP session. When the bad news is postponed until the RCPT TOreply, the client goes away as it is supposed to, instead of hangingaround until a timeout happens, or worse, going into an endlessconnect-reject-connect loop.

• Postfix can log more useful information. For example, whenPostfix rejects a client name or address and delays the actionuntil the RCPT TO command, it can log the sender and the recipientaddress. This is more useful than logging only the client hostnameand IP address and not knowing whose mail was being blocked.

• Mixing is needed for complex allowlisting policies. Forexample, in order to reject local sender addresses in mail fromnon-local clients, you need to be able to mix restrictions on clientinformation with restrictions on sender information in the samerestriction list. Without this ability, many per-user accessrestrictions would be impossible to express.

Dangerous use of smtpd_recipient_restrictions

By now the reader may wonder why we need smtpd client, heloor sender restrictions, when their evaluation is postponed untilthe RCPT TO or ETRN command. Some people recommend placing ALL theaccess restrictions in the smtpd_recipient_restrictions list.Unfortunately, this can result in too permissive access. How isthis possible?

The purpose of the smtpd_recipient_restrictions feature is tocontrol how Postfix replies to the RCPT TO command. If the restrictionlist evaluates to REJECT or DEFER, the recipient address is rejected;no surprises here. If the result is PERMIT, then the recipientaddress is accepted. And this is where surprises can happen.

The problem is that Postfix versions before 2.10 did not havesmtpd_relay_restrictions. They combined the mail relay and spamblocking policies, under smtpd_recipient_restrictions. The resultis that a permissive spam blocking policy could unexpectedly resultin a permissive mail relay policy.

Here is an example that shows when a PERMIT result can resultin too much access permission:

1 /etc/postfix/main.cf:2 smtpd_recipient_restrictions = 3 permit_mynetworks4 check_helo_access hash:/etc/postfix/helo_access5 reject_unknown_helo_hostname6 reject_unauth_destination7 8 /etc/postfix/helo_access:9 localhost.localdomain PERMIT

Line 5 rejects mail from hosts that don't specify a properhostname in the HELO command (with Postfix < 2.3, specifyreject_unknown_hostname). Lines 4 and 9 make an exception toallow mail from some machine that announces itself with "HELOlocalhost.localdomain".

The problem with this configuration is thatsmtpd_recipient_restrictions evaluates to PERMIT for EVERY hostthat announces itself as "localhost.localdomain", making Postfixan open relay for all such hosts.

With Postfix before version 2.10 you should place non-recipientrestrictions AFTER the reject_unauth_destination restriction, notbefore. In the above example, the HELO based restrictions shouldbe placed AFTER reject_unauth_destination, or better, the HELObased restrictions should be placed under smtpd_helo_restrictionswhere they can do no harm.

1 /etc/postfix/main.cf:2 smtpd_recipient_restrictions = 3 permit_mynetworks4 reject_unauth_destination5 check_helo_access hash:/etc/postfix/helo_access6 reject_unknown_helo_hostname7 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 apermissive mail relay policy.

SMTP access rule testing

Postfix has several features that aid in SMTP access ruletesting:

soft_bounce

This is a safety net that changesSMTP server REJECT actions into DEFER (try again later) actions.This keeps mail queued that would otherwise be returned to thesender. Specify "soft_bounce = yes" in the main.cf file to preventthe Postfix SMTP server from rejecting mail permanently, by changingall 5xx SMTP reply codes into 4xx.

warn_if_reject

When placed before a reject-typerestriction, 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 bysome later access restriction). This feature has no effect ondefer_if_reject restrictions.

XCLIENT

With this feature, an authorized SMTPclient can impersonate other systems and perform realistic SMTPaccess rule tests. Examples of how to impersonate other systemsfor access rule testing are given at the end of the XCLIENT_READMEdocument.
This feature is available in Postfix 2.1.