This plugin delivers to another mail server. This is a common setup when you want to have a mail server with a solid pedigree of outbound delivery to other hosts, and inbound delivery to users.
In comparison to
queue/smtp_proxy, this plugin waits until queue time to
attempt the ongoing connection. This can be a benefit in reducing connections
to your inbound mail server when you have content filtering (such as
spamassassin) enabled. A possible downside is that it also delays recipient
validation that the ongoing mail server may provide until queue time.
Configuration is stored in this file in the following keys:
SMTP forward outbound messages (set to false to enable Haraka’s separate Outbound mail routing (MX based delivery)).
The host to connect to.
The port to connect to. Default: 25
The maximum amount of time to wait when creating a new connection to the host. Default: 30 seconds.
The amount of seconds to let a backend connection live idle in the connection pool. This should always be less than the global plugin timeout, which should in turn be less than the connection timeout.
Maximum number of connections at any given time. Default: 1000
Enable TLS with the forward host (if supported). TLS uses options from the tls plugin. If key and cert are provided in the the outbound section of the tls plugin, that certificate will be used as a TLS Client Certificate.
This option controls the use of TLS via
STARTTLS. This plugin does not work with SMTP over TLS.
Enable PLAIN or LOGIN SMTP AUTH. This is required to enable AUTH.
SMTP AUTH username to use.
SMTP AUTH password to use.
Which queue plugin to use. Default: undefined. The default bahavior is to use smtp_forward for inbound connections and outbound for relaying connections. This option is used for complex mail routes.
Requires that sender domains defined in smtp_forward.ini (see Per-Domain below) have relaying privileges. This is a form of spoof prevention and assumes that any mail clients have relaying or AUTH privileges. This is usually the case.
By default, Haraka accepts no emails until a recipient plugin has been configured to accept mails for a domain. The simplest common case is the in_host_list plugin with a list of domains in config/host_list. An alternative is to set
check_recipient=trueand list each domain in a definition block in smtp_forward.ini (see Per-Domain Configuration). An example for two domains:
More specific forward routes for domains can be defined. The domain is
chosen based on the value of the
domain_selector config variable.
domain_selector is set to
rcpt_to (the default), more specific
routes are only honored for SMTP connections with a single recipient or SMTP
connections where every recipient host is identical.
domain_selector is set to
mail_from, the domain of the MAIL FROM
address is used.
enable_outbound can be set or unset on a per-domain level to enable or disable forwarding for specific domains.
# default SMTP host host=184.108.40.206 # auth_type=plain # auth_user=user # auth_user=pass [example1.com] host=220.127.116.11 # auth_type=plain # auth_user=user # auth_pass=pass [example2.com] host=18.104.22.168 [example3.com] host=22.214.171.124 [example4.com] enable\_outbound=false
Split host forward routing
When an incoming email transaction has multiple recipients with different forward routes, recipients to subsequent forward routes are deferred. Example: an incoming email transaction has recipients firstname.lastname@example.org, email@example.com, and firstname.lastname@example.org. The first two messages will be accepted (they share the same forward destination) and the latter one will be deferred. It will arrive in a future delivery attempt by the remote.