SMTP Server Options

This page configures the majority of the options that directly affect the behavior of the SMTP server portion of Postfix, specifically the portions of Postfix that impact how the server behaves toward an SMTP client that connects to the server.

SMTP greeting banner

When a client connects to an SMTP server a greeting banner will be sent to the client (note the term client in this context is not the end user, but rather the email software program that is being used to make the connection). This option configures the text that will follow the status code in the banner. It is possible to use a number of variable expansions, for example, to display the specific version of the server software, though Postfix does not include the version by default. If configuring this option to be other than the default, you must include $myhostname at the start of this line, as it allows Postfix to report and respond to a mailer loop rather than overloading the system with many multiple deliveries. This option correlates to the smtpd_banner directive and contains $myhostname ESMTP $mail_name by default.

Note 

A proposed federal law in the U.S. would make it illegal to send unsolicited commercial email through a mail server if the server included in its SMTP greeting the words NO UCE. Because spammers are generally of a criminal mindset anyway, it is unlikely that many of them will respect the new law if it is ever passed. Nonetheless, it is worth mentioning in hopes that sometime soon, all Americans will have legal protection against the stolen resources and time that UCE represents.

Max number of recipients accepted for delivery

This option limits the number of recipients that may be specified in a single message header. It is usually rare for legitimate messages to have an extremely large number of recipients specified in a single message header, but it is often done in UCE messages. The legitimate exception is messages to a mailing list (possibly sent by mailing list software like majordomo or mailman. This option correlates to the smtpd_recipient_limit and defaults to 1000.

Disable SMTP VRFY command

Normally, the SMTP VRFY command is used to verify the existence of a particular user. However, it is also illegitimately used by spammers to harvest live email addresses. Thus it is sometimes useful to disable this command. This option correlates to disable_vrfy_command and defaults to No.

Timeout in seconds for SMTP transactions

This option sets the timeout in seconds for a client to respond to the SMTP server's response with an SMTP request. The connection process involves the client opening a connection to the server, the server replies with a greeting, and then the client makes its request. If the client request does not come within the time specified here, the connection will be closed. This option correlates to the opts_smtpd_timeout directive and defaults to 300s.

Timeout before sending 4xx/5xx error response

When sending an error response to a client, the server will sleep a specified time. The purpose of this feature is to prevent certain buggy clients from hitting the server with repeated requests in rapid succession. This option correlates to the smtpd_error_sleep_time directive and defaults to 5s.

Error count for temporarily ignore a client

This option configures the number of errors that a client may generate before Postfix will stop responding to requests for a specified time. Some buggy mail clients may send a large number of requests, while ignoring or responding incorrectly to the error messages that result. Postfix attempts to minimize the impact of these buggy clients on normal service. This option correlates to the smtpd_soft_error_limit directive, and defaults to 10.

Error count for closing connection

If the number exceeds this limit the connection will be closed. This option correlates to the smtpd_hard_error_limit directive and defaults to 100.

HELO is required

Enabling this option causes Postfix to require clients to introduce themselves with a HELO header at the beginning of an SMTP session. This may prevent some UCE software packages from connecting, though it may also impact other legitimate clients from connecting. This option correlates to the smtpd_helo_required directive and defaults to No.

Allow untrusted routing

This option configures whether Postfix will forward messages with sender-specified routing from untrusted clients to destinations within the accepted relay domains. This feature closes a sneaky potential loophole in access controls that would normally prevent the server from being an open relay for spammers. If this behavior is allowed, a malicious user could possibly exploit a backup MX mail host into forwarding junk mail to a primary MX server that believes the mail has originated from a local address, and thus delivers it as the spammer intended. This option correlates to the allow_untrusted_routing directive and is disabled by default. Enabling this option should only be done with extreme caution and care to prevent turning your Postfix installation into an open relay.

Restrict ETRN command upon . . .

The SMTP ETRN command is a rather clumsy means for a client that is not always connected to the Internet to retrieve mail from the server. The usage of this command is rather outdated, and rarely used, as POP3 and IMAP are better suited to solve this problem in the general case. This option correlates to the smtpd_etrn_restrictions directive, and the default is to allow ETRN from any host. This option accepts the following directives: check_etrn_access maptype:mapname, permit_naked_ip_address, reject_invalid_hostname, check_helo_access maptype:mapname, reject_maps_rbl, reject_unknown_client, permit_mynetworks, check_client_access, permit, reject, warn_if_reject, and reject_unauth_pipelining.

This option as well as the following three Restrictions options accept one or all of the following values in the text field. Each is described only once here, and the specific entry will include the list of accepted directives for the option. The impact of some of these choices depends on configuration performed elsewhere and could potentially open security holes if not configured carefully.

permit_mynetworks

Permit the message if the relevant address (sender or recipient depending on the restriction) is within the local network.

reject_unknown_client

The request will be refused is the client IP has no PTR record in the DNS. This means that a client with an IP address that cannot be resolved to a host name cannot send mail to this host.

check_client_access maptype:mapname

This option requires the inclusion of an already configured map, as discussed earlier. This will restrict based on the contents of the map, allowing only clients that are allowed by the map. The map may contain networks, parent domains, or client addresses, and Postfix will strip off unnecessary information to match the client to the level of specificity needed.

check_sender_access maptype:mapname

This will restrict based on the contents of the map, allowing only senders that are allowed by the map. The map may contain networks, parent domains, or localpart@.

reject_maps_rbl

An RBL is a relay domain black hole list. By testing a reverse domain lookup against a name server that receives a domain black hole list transfer, the server can know if the mail was sent through a known open mail relay. There are a number of free and for-fee services providing black hole data. The largest and longest lasting is the service operated by MAPS [http://www.mail-abuse.org/], while two new similar services are operated by the Open Relay Database [http://ordb.org/] and by Distributed Sender Boycott List [http://dsbl.org/]. All operated on the principle of allowing administrators to choose to refuse mail sent from open mail relays. If this option is listed, the client will be checked against the available RBL domains, and if any match the mail will be refused.

Note 

If using any of the free RBL services on the network, consider donating money, time, or resources to the project maintainers. The projects are generally run by volunteer labor, using network resources that have been paid for by the maintainers.

reject_invalid_hostname

If the client host name is invalid, due to bad syntax, the request will be rejected.

permit_naked_ip_address

If the client HELO or EHLO command contains a naked IP address without the enclosing [] brackets as required by the mail RFC, the message will be rejected. Beware that some popular mail clients send a HELO greeting that is broken this way.

reject_unknown_hostname

Reject the request if the host name in the client HELO command has no A or MX record in the DNS.

reject_non_fqdn_hostname

If the client host name is not in the form of a fully qualified domain name, as required by the RFC, the message will be rejected.

check_helo_access maptype:mapname

The server will search the named access database map for the HELO host name or parent domains. If the result from the database search is REJECT or a 4xx text or 5xx text error code the message will be refused, while a response of OK or RELAY or an all numerical response will permit the message.

permit

This simply permits anything. Generally this will be at the end of a set of restrictions in order to allow anything that has not been explicitly prohibited.

reject

Rejects everything. This can be used at the end of a chain of restrictions to prohibit anything that has not been explicitly permitted.

warn_if_reject

This is a special option that changes the meaning of the following restriction, so that a message that would have been rejected will be logged but still accepted. This can be used for testing new rules on production mail servers without risk of denying mail due to a problem with the rules.

reject_unauth_pipelining

If the client sends commands ahead of time without first confirming that the server support SMTP command pipelining, the message will be rejected. This will prevent mail from some poorly written bulk email software that improperly uses pipelining to speed up mass deliveries.

Restrictions on client hostnames/addresses

This restriction applies to the client host name and/or address. By default, Postfix will allow connections from any host, but you may add additional restrictions using the following: reject_unknown_client, permit_mynetworks, check_client_access maptype:mapname, reject_maps_rbl, maps_rbl_reject_code, permit, reject, warn_if_reject, reject_unauth_pipelining.

Restrictions on sends in HELO commands

This option specifies additional restrictions on what information can be sent by client in the HELO and EHLO commands. This option correlates to the smtpd_helo_restrictions directive. By default Postfix accepts anything, and the following restrictions may be added: reject_invalid_hostname, permit_naked_ip_address, reject_unknown_hostname, reject_non_fqdn_hostname, check_helo_access maptype:mapname, reject_maps_rbl, reject_unknown_client, check_client_access maptype:mapname, permit, reject, warn_if_reject, reject_unauth_pipelining.

Restrictions on sender addresses

This option restricts what can be contained in the MAIL FROM command in a message. It may be used to prevent specific email addresses from sending mail, reject clients without a resolvable host name, and so on. This option correlates to the smtpd_sender_restrictions directive and may contain any of the following restrictions: permit_mynetworks:, reject_unknown_client, reject_maps_rbl, reject_invalid_hostname, reject_unknown_hostname, reject_unknown_sender_domain, check_sender_access maptype:mapname, check_client_access maptype:mapname, check_helo_access maptype:mapname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject, permit.

Restrictions on recipient addresses

This parameter places restrictions on the recipients that can be contained in the RCPT TO command of a sent message. It can be used to dictate where email may be sent. This option correlates to the smtpd_recipient_restrictions and may contain any of the following restrictions: permit_mynetworks, reject_unknown_client, reject_maps_rbl, reject_invalid_hostname, reject_unknown_hostname, reject_unknown_sender_domain, check_relay_domains, permit_auth_destination, reject_unauth_pipelining, permit_mx_backup, reject_unknown_recipient, check_recipient_access, check_client_access, check_helo_access, check_sender_access, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject, permit.

DNS domains for blacklist lookups

This option configures the optional blacklist DNS servers that will be used for all RBL checks that have been specified in all access restrictions. It may contain any number of servers in a whitespace separated list. These services can be used to help prevent spam, as discussed earlier in this section, with the Restrict ETRN command upon parameter. This option configures the maps_rbl_domains directive and is empty by default.

Restrict mail relaying

This option specifies from which hosts, networks, domains, and so on. Postfix will relay email for. This option correlates to the relay_domains directive and defaults to $mydestination.

SMTP server response on access map violation, SMTP server response on RBL domains violation, SMTP server response on forbidden relaying, SMTP server response on unknown client reject, SMTP server response on invalid hostname reject, SMTP server response on unknown domain reject, SMTP server response on unknown hostname reject

These options configure the error result code that will be sent to the client when any of the specified restrictions are being applied. These errors have sensible default values and generally should not need to be changed. Consult with RFC 822 if you wish to understand more about the SMTP error codes or have a reason to change any of these values.