diff options
Diffstat (limited to '')
-rw-r--r-- | proto/LOCAL_RECIPIENT_README.html | 180 |
1 files changed, 180 insertions, 0 deletions
diff --git a/proto/LOCAL_RECIPIENT_README.html b/proto/LOCAL_RECIPIENT_README.html new file mode 100644 index 0000000..12828cd --- /dev/null +++ b/proto/LOCAL_RECIPIENT_README.html @@ -0,0 +1,180 @@ +<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN" + "http://www.w3.org/TR/html4/loose.dtd"> + +<html> + +<head> + +<title>Rejecting Unknown Local Recipients with Postfix</title> + +<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> + +</head> + +<body> + +<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Rejecting Unknown Local Recipients with Postfix</h1> + +<hr> + +<h2>Introduction</h2> + +<p> As of Postfix version 2.0, the Postfix SMTP server rejects mail +for unknown recipients in local domains (domains that match +$mydestination or the IP addresses in $inet_interfaces or +$proxy_interfaces) with "User unknown in local recipient table". +This feature was optional with earlier Postfix versions. </p> + +<p> The good news is that this keeps undeliverable mail out of your +queue, so that your mail queue is not clogged up with undeliverable +MAILER-DAEMON messages. </p> + +<p> The bad news is that it may cause mail to be rejected when you +upgrade from a Postfix system that was not configured to reject +mail for unknown local recipients. </p> + +<p> This document describes what steps are needed in order to reject +unknown local recipients correctly. </p> + +<ul> + +<li><a href="#main_config">Configuring local_recipient_maps +in main.cf</a> + +<li><a href="#change">When you need to change the local_recipient_maps +setting in main.cf</a> + +<li><a href="#format">Local recipient table format </a> + +</ul> + +<h2><a name="main_config">Configuring local_recipient_maps +in main.cf</a></h2> + +<p> The local_recipient_maps parameter specifies lookup tables with +all names or addresses of local recipients. A recipient address is +local when its domain matches $mydestination, $inet_interfaces or +$proxy_interfaces. If a local username or address is not listed in +$local_recipient_maps, then the Postfix SMTP server will reject +the address with "User unknown in local recipient table". </p> + +<p> The default setting, shown below, assumes that you use the +default Postfix local(8) delivery agent for local delivery, where +recipients are either UNIX accounts or local aliases: </p> + +<blockquote> +<pre> +/etc/postfix/main.cf: + local_recipient_maps = proxy:unix:passwd.byname $alias_maps +</pre> +</blockquote> + +<p> To turn off unknown local recipient rejects by the SMTP server, +specify: </p> + +<blockquote> +<pre> +/etc/postfix/main.cf: + local_recipient_maps = +</pre> +</blockquote> + +<p> That is, an empty value. With this setting, the Postfix SMTP +server will not reject mail with "User unknown in local recipient +table". <b> Don't do this on systems that receive mail directly +from the Internet. With today's worms and viruses, Postfix will +become a backscatter source: it accepts mail for non-existent +recipients and then tries to return that mail as "undeliverable" +to the often forged sender address</b>. </p> + +<h2><a name="change">When you need to change the local_recipient_maps +setting in main.cf</a></h2> + +<ul> + + <li> <p> Problem: you don't use the default Postfix local(8) + delivery agent for domains matching $mydestination, $inet_interfaces, + or $proxy_interfaces. For example, you redefined the + "local_transport" setting in main.cf. </p> + + <p> Solution: your local_recipient_maps setting needs to specify + a database that lists all the known user names or addresses + for that delivery agent. For example, if you deliver users in + $mydestination etc. domains via the virtual(8) delivery agent, + specify: </p> + +<pre> +/etc/postfix/main.cf + mydestination = $myhostname localhost.$mydomain localhost ... + local_transport = virtual + local_recipient_maps = $virtual_mailbox_maps +</pre> + + <p> If you use a different delivery agent for $mydestination + etc. domains, see the section "<a href="#format">Local recipient + table format</a>" below for a description of how the table + should be populated. </p> + + <li> <p> Problem: you use the mailbox_transport or fallback_transport + feature of the Postfix local(8) delivery agent in order to + deliver mail to non-UNIX accounts. </p> + + <p> Solution: you need to add the database that lists the + non-UNIX users: </p> + +<pre> +/etc/postfix/main.cf + local_recipient_maps = proxy:unix:passwd.byname, $alias_maps, + <the database with non-UNIX accounts> +</pre> + + <p> See the section "<a href="#format">Local recipient table + format</a>" below for a description of how the table should be + populated. </p> + + <li> <p> Problem: you use the luser_relay feature of the Postfix + local delivery agent. </p> + + <p> Solution: you must disable the local_recipient_maps feature + completely, so that Postfix accepts mail for all local addresses: + </p> + +<pre> +/etc/postfix/main.cf + local_recipient_maps = +</pre> + +</ul> + +<h2><a name="format">Local recipient table format</a> </h2> + +<p> If you use local files in postmap(1) format, then +local_recipient_maps expects the following table format: </p> + +<ul> + +<li> <p> In the left-hand side, specify a bare username, an +"@domain.tld" wild-card, or specify a complete "user@domain.tld" +address. </p> + +<li> <p> You have to specify something on the right-hand side of +the table, but the value is ignored by local_recipient_maps. + +</ul> + +<p> If you use lookup tables based on NIS, LDAP, MYSQL, or PGSQL, +then local_recipient_maps does the same queries as for local files +in postmap(1) format, and expects the same results. </p> + +<p> With regular expression tables, Postfix only queries with the +full recipient address, and not with the bare username or the +"@domain.tld" wild-card. </p> + +<p> NOTE: a lookup table should always return a result when the address +exists, and should always return "not found" when the address does +not exist. In particular, a zero-length result does not count as +a "not found" result. </p> + +</body> + +</html> |