3455 lines
87 KiB
HTML
3455 lines
87 KiB
HTML
<html>
|
|
|
|
<!--Warning, preformatted content! -->
|
|
|
|
<head>
|
|
|
|
<title>Postfix Frequently Asked Questions</title>
|
|
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<h1><a href="big-picture.html"><img src="small-picture.gif" width="115" height="45"></a> Postfix Frequently Asked Questions</h1>
|
|
|
|
<hr>
|
|
|
|
<a href="index.html">Up one level</a> | Postfix FAQ
|
|
|
|
<h2>Table of contents</h2>
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#poppers">POP or IMAP problems</a>
|
|
|
|
<li><a href="#systems">Problems with specific Operating Systems</a>
|
|
|
|
<li><a href="#warnings">Postfix warnings and error messages</a>
|
|
|
|
<li><a href="#example_config">Example configurations</a>
|
|
|
|
<li><a href="#sendmail_incompatibility">Sendmail incompatibility</a>
|
|
|
|
<li><a href="#moby">Running hundreds of Postfix processes</a>
|
|
|
|
<li><a href="#performance">Postfix performance</a>
|
|
|
|
<li><a href="#receiving">Receiving mail via the network</a>
|
|
|
|
<li><a href="#relaying">Mail relaying</a>
|
|
|
|
<li><a href="#remote_delivery">Remote delivery</a>
|
|
|
|
<li><a href="#local_delivery">Local (non-virtual) delivery</a>
|
|
|
|
<li><a href="#mailing_lists">Mailing lists</a>
|
|
|
|
<li><a href="#virtual_domains">Virtual domains</a>
|
|
|
|
<li><a href="#address_rewriting">Address rewriting</a>
|
|
|
|
<li><a href="#content_filtering">Content filtering</a>
|
|
|
|
<li><a href="#other_transports">Other transports: UUCP, FAX, etc.</a>
|
|
|
|
<li><a href="#queue_maint">Postfix queue maintenance</a>
|
|
|
|
<li><a href="#compiling_installing">Compiling and installing Postfix</a>
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<a name="warnings"><h3>Postfix warnings and error messages</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#biff">What does "biff_notify: Connection refused" mean?</a>
|
|
|
|
<li><a href="#nisdom">What does "NIS domain name not set - NIS lookups disabled" mean?</a>
|
|
|
|
<li><a href="#dns-again">Mail stays queued with: Host not found, try again</a>
|
|
|
|
<li><a href="#timeouts">Mail fails consistently with timeout or lost connection</a>
|
|
|
|
<li><a href="#noalias">What does "fatal: open database /etc/aliases.db" mean?</a>
|
|
|
|
<li><a href="#noservice">What does "fatal: unknown service: smtp/tcp" mean?</a>
|
|
|
|
<li><a href="#nosuid">sendmail has set-uid root file permissions, or is run from a set-uid root process</a>
|
|
|
|
<li><a href="#whoami">sendmail: unable to find out your login name</a>
|
|
|
|
<li><a href="#paranoid">warning: xxx.xxx.xxx.xxx: address not listed
|
|
for hostname yyy.yyy.yyy</a>
|
|
|
|
<li><a href="#unknown_virtual_loop">Mail for unknown users in
|
|
virtual domains fails with "mail loops back to myself"</a>
|
|
|
|
<li><a href="#virtual_relay">Postfix refuses mail for virtual
|
|
domains with "relay access denied"</a>
|
|
|
|
<li><a href="#broken_transport">Mail delivery fails with: "unknown
|
|
mail transport error"</a>
|
|
|
|
<li><a href="#msql_limit">Too many connections</a>
|
|
|
|
<li><a href="#reiser_bugs">write queue file: No such file or directory</a>
|
|
|
|
<li><a href="#reiser_bugs">write queue file: Unknown error 4294967289</a>
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<a name="example_config"><h3>Example configurations</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#stand_alone">Stand-alone machine</a>
|
|
|
|
<li><a href="#workstation_server">Workstations and servers</a>
|
|
|
|
<li><a href="#null_client">Null clients</a>
|
|
|
|
<li><a href="#intranet">Running Postfix inside an intranet</a>
|
|
|
|
<li><a href="#firewall">Running Postfix on a firewall</a>
|
|
|
|
<li><a href="#dialup">Running Postfix on a dialup machine</a>
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<a name="sendmail_incompatibility"><h3>Sendmail incompatibility</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#verbose">Postfix breaks "sendmail -v"</a>
|
|
|
|
<li><a href="#delayed">Postfix sends no "delayed mail" notices</a>
|
|
|
|
<li><a href="#root">Root's mail is delivered to nobody</a>
|
|
|
|
<li><a href="#bogus">Postfix accepts mail for non-existing local users</a>
|
|
|
|
<li><a href="#duplicate">Postfix sends duplicate mail</a>
|
|
|
|
<li><a href="#metoo">Postfix sends mail to every member of a
|
|
distribution list</a>
|
|
|
|
<li><a href="#delivered">Getting rid of the ugly Delivered-To: header</a>
|
|
|
|
<li><a href="#majordomo-approve">Postfix breaks the majordomo "approve" command</a>
|
|
|
|
<li><a href="#skip_greeting">Postfix does not try all the MX addresses</a>
|
|
|
|
<li><a href="#worm">Postfix accepts MAIL FROM and RCPT TO "| command"</a>
|
|
|
|
</ul>
|
|
|
|
<a name="moby"><h3>Running hundreds of Postfix processes</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#moby-freebsd">Running hundreds of Postfix processes on FreeBSD</a>
|
|
|
|
<li><a href="#moby-linux">Running hundreds of Postfix processes on Linux</a>
|
|
|
|
<li><a href="#moby-sun">Running hundreds of Postfix processes on Solaris</a>
|
|
|
|
<li><a href="#moby-postfix">Running thousands of Postfix delivery agents</a>
|
|
|
|
</ul>
|
|
|
|
|
|
<a name="performance"><h3>Postfix performance</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#incoming">Mail stays queued in the incoming queue</a>
|
|
|
|
<li><a href="#delay">Postfix responds slowly to incoming SMTP connections</a>
|
|
|
|
</ul>
|
|
|
|
<a name="receiving"><h3>Receiving mail via the network</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#delay">Postfix responds slowly to incoming SMTP connections</a>
|
|
|
|
<li><a href="#numerical_log">Postfix logs SMTP clients as IP
|
|
addresses</a>
|
|
|
|
<li><a href="#paranoid">warning: xxx.xxx.xxx.xxx: address not listed
|
|
for hostname yyy.yyy.yyy</a>
|
|
|
|
</ul>
|
|
|
|
<a name="relaying"><h3>Mail relaying</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#open_relay">Help! Postfix is an open relay</a>
|
|
|
|
<li><a href="#mobile">Relaying mail for mobile users</a>
|
|
|
|
<li><a href="#virtual_relay">Postfix refuses mail for virtual
|
|
domains with "relay access denied"</a>
|
|
|
|
<li><a href="#relay_restrict">Restricting what users can send mail to off-site destinations</a>
|
|
|
|
<li><a href="#backup">Configuring Postfix as backup MX host</a>
|
|
|
|
</ul>
|
|
|
|
<a name="remote_delivery"><h3>Remote delivery</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#dns-again">Mail stays queued with: Host not found, try again</a>
|
|
|
|
<li><a href="#timeouts">Mail fails consistently with timeout or lost connection</a>
|
|
|
|
<li><a href="#skip_greeting">Postfix does not try all the MX addresses</a>
|
|
|
|
<li><a href="#noservice">What does "fatal: unknown service: smtp/tcp" mean?</a>
|
|
|
|
<li><a href="#broken_transport">Mail delivery fails with: "unknown
|
|
mail transport error"</a>
|
|
|
|
</ul>
|
|
|
|
<a name="local_delivery"><h3>Local (non-virtual) delivery</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#root">Root's mail is delivered to nobody</a>
|
|
|
|
<li><a href="#biff">What does "biff_notify: Connection refused" mean?</a>
|
|
|
|
<li><a href="#nisdom">What does "NIS domain name not set - NIS lookups disabled" mean?</a>
|
|
|
|
<li><a href="#bogus">Postfix accepts mail for non-existing local users</a>
|
|
|
|
<li><a href="#some_local">Delivering some users locally while
|
|
sending mail as user@domain</a>
|
|
|
|
<li><a href="#maildir">Support for maildir-style mailboxes</a>
|
|
|
|
<li><a href="#procmail">Using Procmail for system-wide local delivery</a>
|
|
|
|
<li><a href="#delivered">Getting rid of the ugly Delivered-To: header</a>
|
|
|
|
<li><a href="#duplicate">Postfix sends duplicate mail</a>
|
|
|
|
<li><a href="#metoo">Postfix sends mail to every member of a
|
|
distribution list</a>
|
|
|
|
<li><a href="#owner-foo">Postfix ignores the owner-list alias</a>
|
|
|
|
<li><a href="#noalias">What does "fatal: open database /etc/aliases.db" mean?</a>
|
|
|
|
<li><a href="#broken_transport">Mail delivery fails with: "unknown
|
|
mail transport error"</a>
|
|
|
|
</ul>
|
|
|
|
<a name="mailing_lists"><h3>Mailing lists</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#majordomo-approve">Postfix breaks the majordomo "approve" command</a>
|
|
|
|
<li><a href="#internal-list">Protecting internal email distribution lists</a>
|
|
|
|
<li><a href="#duplicate">Postfix sends duplicate mail</a>
|
|
|
|
<li><a href="#metoo">Postfix sends mail to every member of a
|
|
distribution list</a>
|
|
|
|
<li><a href="#owner-foo">Postfix ignores the owner-list alias</a>
|
|
|
|
<li><a href="#virtual_command">Commands, mailing lists, and /file/name destinations don't work in Postfix virtual maps</a>
|
|
|
|
</ul>
|
|
|
|
<a name="virtual_domains"><h3>Virtual domains</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#unknown_virtual_accept">Postfix does not refuse mail for
|
|
unknown users in virtual domains</a>
|
|
|
|
<li><a href="#unknown_virtual_loop">Mail for unknown users in
|
|
virtual domains fails with "mail loops back to myself"</a>
|
|
|
|
<li><a href="#virtual_relay">Postfix refuses mail for virtual
|
|
domains with "relay access denied"</a>
|
|
|
|
<li><a href="#virtual_command">Commands, mailing lists, and /file/name destinations don't work in Postfix virtual maps</a>
|
|
|
|
<li><a href="#domain_mailbox">Receiving a virtual domain in a
|
|
mailbox</a>
|
|
|
|
<li><a href="#virtual_logging">Postfix logs delivery to virtual
|
|
address with the wrong name</a>
|
|
|
|
</ul>
|
|
|
|
<a name="address_rewriting"><h3>Address rewriting</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#masquerade">Address masquerading with exceptions</a>
|
|
|
|
</ul>
|
|
|
|
<a name="content_filtering"><h3>Content filtering</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#scanning">Support for virus scanning</a>
|
|
|
|
</ul>
|
|
|
|
<a name="other_transports"><h3>Other transports: UUCP, FAX, etc.</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#uucp-tcp">Using UUCP over TCP</a>
|
|
|
|
<li><a href="#internet-uucp">Setting up an Internet to UUCP gateway</a>
|
|
|
|
<li><a href="#uucp-only">Using UUCP as the default transport</a>
|
|
|
|
<li><a href="#fax">Sending mail to a FAX machine</a>
|
|
|
|
</ul>
|
|
|
|
<a name="queue_maint"><h3>Postfix queue maintenance</h3></a>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#deleting">Deleting a message from the Postfix queue</a>
|
|
|
|
<li><a href="#copying">Moving or restoring the Postfix queue</a>
|
|
|
|
</ul>
|
|
|
|
<a name="compiling_installing"><h3>Compiling and installing Postfix</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#bind">Undefined symbols: ___dn_expand, ___res_init etc.</a>
|
|
|
|
<li><a href="#dbm_dirfno">Undefined symbols: dbm_pagfno, dbm_dirfno etc.</a>
|
|
|
|
<li><a href="#db">Using third-party DB libraries</a>
|
|
|
|
<li><a href="#sgistruct">IRIX problems translating IP address to string</a>
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<a name="systems"><h3>Problems with specific Operating Systems</h3>
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#compaq">Problems with Compaq</a>
|
|
|
|
<li><a href="#irix">Problems with IRIX</a>
|
|
|
|
</ul>
|
|
|
|
<a name="compaq"><h3>Problems with Compaq</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#compaq-chmod">Compaq mail blackhole problem</a>
|
|
|
|
</ul>
|
|
|
|
<a name="irix"><h3>Problems with IRIX</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#sgistruct">IRIX problems translating IP address to string</a>
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="poppers"><h3>POP or IMAP problems</h3>
|
|
|
|
Postfix is a mail delivery system. Postfix does not implement
|
|
services such as POP or IMAP to read mail. Several POP/IMAP
|
|
implementations exist that can cooperate with software such as
|
|
Postfix.
|
|
|
|
<p>
|
|
|
|
Examples of software that is used successfully with Postfix:
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li><a href="http://asg.web.cmu.edu/cyrus/">Cyrus IMAP</a> implements
|
|
IMAP, POP3, and KPOP, later versions also support TLS. This software
|
|
implements its own private mail database system. Not for beginners.
|
|
|
|
<p>
|
|
|
|
<li><a href="http://www.inter7.com/courierimap/">Courier-Imap</a>
|
|
provides POP3 and IMAP, and supports access over SSL.
|
|
This software supports the maildir-style mailbox format only
|
|
(one message per file, same format as qmail).
|
|
|
|
<p>
|
|
|
|
<li><a href="http://www.eudora.com/qpopper/">Qpopper</a> supports
|
|
POP3, TLS (SSL), and uses the traditional UNIX-style mailbox format
|
|
(multiple messages per file, each message starts with "From sender date...").
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<hr>
|
|
|
|
<a name="stand_alone"><h3>Stand-alone machine</h3>
|
|
|
|
Out of the box, Postfix should work without change on a stand-alone
|
|
machine that has direct Internet access. At least, that is how
|
|
Postfix installs when you download the Postfix source code. If you
|
|
are on a firewalled intranet, or if your machine is dial-up connected
|
|
only a small part of the time, see the respective sections.
|
|
|
|
<hr>
|
|
|
|
<a name="workstation_server"><h3>Workstations and servers</h3>
|
|
|
|
This section describes a workstation-server environment. All systems
|
|
send mail as user@domain. All systems receive mail for user@hostname.
|
|
The server receives mail for user@domain, too.
|
|
|
|
<p>
|
|
|
|
Postfix has sane defaults for all parameters, so the text shows
|
|
only the overrides. In particular, Postfix will relay mail only
|
|
for clients in its own domain (and subdomains) and in its class A,
|
|
B or C networks. The master.cf file (somewhat like inetd.conf)
|
|
needs tweaking only if you have a very slow or a very fast net/machine.
|
|
|
|
<p>
|
|
|
|
Workstation:
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
myorigin = $mydomain
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Server:
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
myorigin = $mydomain
|
|
mydestination = $myhostname, localhost.$mydomain, $mydomain
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
In an environment like this. either the mail spool directory is
|
|
shared via NFS, users access their mailboxes via POP, or each user
|
|
receives her mail on her own workstation. In the latter case, each
|
|
user has an alias on the server that forwards mail to the respective
|
|
workstation:
|
|
|
|
<p>
|
|
|
|
Server:
|
|
<pre>
|
|
/etc/aliases:
|
|
joe: joe@joes.workstation
|
|
jane: jane@janes.workstation
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
On some systems the alias database is not in <b>/etc/aliases</b>.
|
|
To find out the location for your system, execute the command
|
|
<b>postconf alias_maps</b>.
|
|
|
|
<hr>
|
|
|
|
<a name="null_client"><h3>Null clients</h3>
|
|
|
|
A null client is a machine that can only send mail. It receives no
|
|
mail from the network, and it does not deliver any mail locally. A
|
|
null client typically uses POP or NFS for mailbox access.
|
|
|
|
<p>
|
|
|
|
In the following example, mail is sent as user@domain, and all mail
|
|
is forwarded to the mail server that is responsible for the local
|
|
domain.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
myorigin = $mydomain
|
|
relayhost = $mydomain
|
|
|
|
/etc/postfix/master.cf:
|
|
Comment out the SMTP server entry
|
|
Comment out the local delivery agent entry
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Since everything sends mail as user@domain, nothing sends mail as
|
|
user@nullclient, and therefore no special configuration needs to
|
|
be done on the mail server for mail addressed to user@nullclient.
|
|
|
|
<hr>
|
|
|
|
<a name="intranet"> <h3>Running Postfix inside an intranet</h3> </a>
|
|
|
|
The simplest way to set up Postfix on a host inside a firewalled
|
|
network is to send all your mail to an intranet mail gateway, and
|
|
to let that mail gateway take care of forwarding.
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li>Send mail as user@domain. This is optional but highly recommended
|
|
because it allows users to change machines without hassle.
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
myorigin = $mydomain
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<li>Forward <i>all</i> mail to an intranet mail gateway, except
|
|
for mail for the local machine:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
relayhost = $mydomain
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
This assumes that your organization has set up internal MX records
|
|
for the local domain.
|
|
|
|
<p>
|
|
|
|
If your intranet does not use MX records internally, you have to
|
|
specify the intranet mail gateway host itself:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
relayhost = host.my.domain
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
If your intranet does not use DNS internally, you have to disable
|
|
DNS lookups as well:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
disable_dns_lookups = yes
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<li>In addition to the above you can configure Postfix to deliver
|
|
intranet mail directly instead of sending it via the intranet
|
|
mail gateway.
|
|
|
|
<p>
|
|
|
|
Specify routing information for the internal domain in the <a
|
|
href="transport.5.html">transport</a> table, and enable <a
|
|
href="transport.5.html">transport</a> table lookups.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/transport:
|
|
my.domain smtp:
|
|
.my.domain smtp:
|
|
thishost.my.domain local: !!!important!!!
|
|
localhost.my.domain local: !!!important!!!
|
|
|
|
/etc/postfix/main.cf:
|
|
transport_maps = hash:/etc/postfix/transport
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Important: do not omit the entries that deliver mail locally, or
|
|
else mail will bounce with a "mail loops to myself" condition.
|
|
|
|
<p>
|
|
|
|
Specify <b>dbm</b> instead of <b>hash</b> if your system uses
|
|
<b>dbm</b> files instead of <b>db</b>. To find out what map types
|
|
Postfix supports, use the command <b>postconf -m</b>.
|
|
|
|
<p>
|
|
|
|
Execute the command <b>postmap /etc/postfix/transport</b> whenever
|
|
you edit the transport table.
|
|
|
|
<p>
|
|
|
|
<li>Execute the command <b>postfix reload</b> to make the
|
|
changes effective.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="firewall"><h3>Running Postfix on a firewall</h3> </a>
|
|
|
|
Note: this text applies to Postfix versions dated 19991115
|
|
and later only. To find out what Postfix version you have,
|
|
execute the command <b>postconf mail_version</b>.
|
|
|
|
<p>
|
|
|
|
How to set up Postfix on the firewall machine so that it relays
|
|
mail for <i>domain.com</i> to a gateway machine on the inside, and
|
|
so that it refuses mail for <i>*.domain.com</i>? The problem is that
|
|
the default <a href="uce.html#relay_domains">relay_domains</a>
|
|
mail relaying restriction allows mail to <i>*.domain.com</i> when
|
|
you specify <i>domain.com</i>.
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li>Specify a <a href="transport.5.html">transport</a> table to
|
|
route mail for <i>domain.com</i> to the inside machine.
|
|
|
|
<p>
|
|
|
|
Specify explicit settings for <a
|
|
href="uce.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a>
|
|
and for <a href="basic.html#mynetworks">mynetworks</a> that allow
|
|
local systems to send mail anywhere, and that allow remote systems
|
|
to send mail only to <i>user@domain.com</i>.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
myorigin = domain.com
|
|
mydestination = domain.com
|
|
transport_maps = hash:/etc/postfix/transport
|
|
mynetworks = 12.34.56.0/24
|
|
smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination
|
|
local_transport = error:local mail delivery is disabled on this machine
|
|
|
|
/etc/postfix/transport:
|
|
domain.com smtp:inside-gateway.domain.com (forwards user@domain)
|
|
|
|
/etc/postfix/master.cf:
|
|
Comment out the local delivery agent
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Specify <b>dbm</b> instead of <b>hash</b> if your system uses
|
|
<b>dbm</b> files instead of <b>db</b>. To find out what map types
|
|
Postfix supports, use the command <b>postconf -m</b>.
|
|
|
|
<p>
|
|
|
|
<li>Execute the command <b>postmap /etc/postfix/transport</b>
|
|
whenever you change the transport table.
|
|
|
|
<p>
|
|
|
|
<li>Execute the command <b>postfix reload</b> after a
|
|
configuration change.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="dialup"><h3>Running Postfix on a dialup machine</h3></a>
|
|
|
|
This section applies to dialup connections that are down most of
|
|
the time. For dialup connections that are up 24x7, see the <a
|
|
href="#workstation_server">workstations and servers</a> section
|
|
instead.
|
|
|
|
<p>
|
|
|
|
If you do not have your own hostname (as with dynamic IP addressing)
|
|
and must send mail as user@your-isp.com, you should also study the
|
|
the section on <a href="#some_local">delivering some users locally
|
|
while sending mail as user@domain</a>.
|
|
|
|
<ul>
|
|
|
|
<li> Route all outgoing mail to your provider.
|
|
|
|
<p>
|
|
|
|
If your machine is disconnected most of the time, there isn't
|
|
a lot of opportunity for Postfix to deliver mail to hard-to-reach
|
|
corners of the Internet. It's better to drop the mail to a machine
|
|
that is connected all the time.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
relayhost = smtprelay.someprovider.com
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<li> <a name="spontaneous_smtp">Disable spontaneous SMTP mail
|
|
delivery (on-demand dialup IP only).</a>
|
|
|
|
<p>
|
|
|
|
Normally, Postfix attempts to deliver outbound mail at its convenience.
|
|
If your machine uses on-demand dialup IP, this causes your system
|
|
to place a telephone call whenever you submit new mail, and whenever
|
|
Postfix retries to deliver delayed mail. To prevent such telephone
|
|
calls from being placed, disable spontaneous SMTP mail deliveries.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
defer_transports = smtp (Only for systems that use on-demand dialup IP)
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<li> Disable SMTP client DNS lookups (dialup LAN only).
|
|
|
|
<p>
|
|
|
|
Some people use Postfix to deliver mail across a LAN that is
|
|
disconnected most of the time. Under such conditions, mail delivery
|
|
can suffer from delays while the Postfix SMTP client performs sender
|
|
and recipient domain DNS lookups in order to be standards-compliant.
|
|
To prevent these delays, disable all SMTP client DNS lookups.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
disable_dns_lookups = yes (Only for delivery across LANs that are disconnected most of the time)
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<i> When you disable DNS lookups, you must specify the</i>
|
|
<b>relayhost</b> <i> as either a numeric IP address, or as a hostname
|
|
that resolves to one or more IP addresses (with DNS lookup disabled,
|
|
Postfix does no MX lookup</i>).
|
|
|
|
<p>
|
|
|
|
<li> Flush the mail queue whenever the Internet link is established.
|
|
|
|
<p>
|
|
|
|
Put the following command into your PPP or SLIP dialup scripts:
|
|
|
|
<p>
|
|
|
|
<dl>
|
|
|
|
<dd><b>/usr/sbin/sendmail -q</b> (whenever the Internet link is up)
|
|
|
|
</dl>
|
|
|
|
<p>
|
|
|
|
The exact location of the <b>sendmail</b> command is system-specific.
|
|
With some UNIX versions, use <b>/usr/lib/sendmail</b>.
|
|
|
|
<p>
|
|
|
|
In order to find out if the mail queue is flushed, use something
|
|
like:
|
|
|
|
<p>
|
|
<pre>
|
|
#!/bin/sh
|
|
|
|
# Start deliveries.
|
|
/usr/sbin/sendmail -q
|
|
|
|
# Allow deliveries to start.
|
|
sleep 10
|
|
|
|
# Loop until all messages have been tried at least once.
|
|
while mailq | grep '^[^ ]*\*' >/dev/null
|
|
do
|
|
sleep 10
|
|
done
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
If you have disabled <a href="#spontaneous_smtp">spontaneous SMTP
|
|
mail delivery</a>, you also need to run the above command every
|
|
now and then while the dialup link is up, so that newly-posted mail
|
|
is flushed from the queue.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="verbose"><h3>Postfix breaks "sendmail -v"</h3> </a>
|
|
|
|
Some people will complain that <b>sendmail -v</b> no longer shows
|
|
the actual mail delivery.
|
|
|
|
<p>
|
|
|
|
With a distributed mail system such as Postfix, this is difficult
|
|
to implement. Unlike sendmail, no Postfix mail delivery process
|
|
runs under control by a user. Instead, Postfix delivers mail with
|
|
daemon processes that have no parent-child relationship with user
|
|
processes. This eliminates a large variety of potential security
|
|
exploits with environment variables, signal handlers, and with
|
|
other process attributes that UNIX passes on from parent process
|
|
to child process.
|
|
|
|
<p>
|
|
|
|
Postfix uses multiple processes in order to insulate subsystems
|
|
from each other. Making the delivery agents talk directly to user
|
|
processes would defeat a lot of the effort that went into making
|
|
Postfix more secure than ordinary mailers.
|
|
|
|
<hr>
|
|
|
|
<a name="delayed"><h3>Postfix sends no "delayed mail" notices</h3>
|
|
|
|
<blockquote>
|
|
|
|
When I was using Sendmail, after 4 hours, it would always send a receipt
|
|
back to the sender saying mail delivery is delayed.
|
|
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
In order to make Postfix send "delayed mail" notifications after
|
|
four hours, specify:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
delay_warning_time = 4
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
|
|
With Postfix, delayed mail notices are turned off by default -
|
|
people get enough mail already.
|
|
|
|
<hr>
|
|
|
|
<a name="duplicate"><h3>Postfix sends duplicate mail</h3> </a>
|
|
|
|
Some people will complain that Postfix sends duplicate messages.
|
|
This happens whenever one message is mailed to multiple addresses
|
|
that reach the same user. Examples of such scenarios are:
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li>One message is sent to the user, and to an alias that lists
|
|
the user. The user receives one copy of the mail directly, and
|
|
one copy via the alias.
|
|
|
|
<p>
|
|
|
|
<li>One message is sent to multiple aliases that list the user.
|
|
The user receives one copy of the mail via each alias.
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
Some people will even argue that this is the "right" behavior. It
|
|
is probably more a matter of expectation and of what one is used to.
|
|
|
|
<p>
|
|
|
|
This can be "fixed" only by making Postfix slower. In the above
|
|
examples, Postfix would first have to completely expand all
|
|
distribution lists before starting any delivery. By design, Postfix
|
|
delivers mail to different destinations in parallel, and local
|
|
delivery is no exception. This is why Postfix can be faster than
|
|
sendmail.
|
|
|
|
<hr>
|
|
|
|
<a name="metoo"><h3>Postfix sends mail to every member of a
|
|
distribution list</h3> </a>
|
|
|
|
Some people will complain that Postfix sends mail to every member
|
|
of a distribution list, including the poster. By default, Sendmail
|
|
deletes the poster from distribution lists. Sendmail sends mail to
|
|
the poster only when the "metoo" flag is explicitly turned on.
|
|
|
|
<p>
|
|
|
|
Wietse believes that Postfix implements the "right" behavior,
|
|
and suspects that Sendmail's default behavior is a remnant from a
|
|
dark past when Sendmail used a pretty crummy algorithm to avoid
|
|
aliasing loops.
|
|
|
|
<hr>
|
|
|
|
<a name="owner-foo"><h3>Postfix ignores the owner-list alias</h3></a>
|
|
|
|
Normally, when a local alias <i>foo</i> has a companion alias
|
|
<i>owner-foo</i>, Postfix reports delivery errors to the owner
|
|
address rather than the message originator.
|
|
|
|
<p>
|
|
|
|
However, as a result of a Postfix implementation artefact, the
|
|
owner-foo alias takes effect only after the alias expansion is
|
|
completed.
|
|
|
|
<p>
|
|
|
|
Delivery problems that happen while expanding the alias, including
|
|
delivery to commands or files, are reported to the original sender
|
|
envelope address.
|
|
|
|
<p>
|
|
|
|
The reason is that bounces are sent by the Postfix queue manager,
|
|
which does not know that the sender address is being replaced.
|
|
|
|
<p>
|
|
|
|
This limitation will be fixed by changing how the Postfix local
|
|
delivery agent deals with undeliverable mail.
|
|
|
|
<hr>
|
|
|
|
<a name="noalias"><h3>What does "fatal: open database /etc/aliases.db" mean?</h3></a>
|
|
|
|
DB files are maintained by the Berkeley DB library. The above
|
|
message means one of the following things:
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li> The existing file does not have the expected file format.
|
|
The cause is one of the following:
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li>The file was created by Berkeley DB version 1 and you are using
|
|
version 2 or 3 (or vice versa).
|
|
|
|
<p>
|
|
|
|
<li> The file was written in "btree" format and Postfix expects
|
|
"hash" format (or vice versa).
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
To fix the problem for Postfix execute the following command as root:
|
|
|
|
<blockquote>
|
|
<pre>
|
|
newaliases
|
|
</pre>
|
|
</blockquote>
|
|
|
|
This creates the aliases.db in the format that Postfix expects.
|
|
|
|
<p>
|
|
|
|
<li>Or the problem could be something completely different. If the
|
|
result of running <tt>newaliases</tt> is a zero-length aliases.db
|
|
file, then you probably suffer from the following problem.
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li>Postfix was compiled with #include files for Berkeley DB version
|
|
<i>X</i> and was linked against object library files for Berkeley DB
|
|
version <i>Y</i>, where <i>X</i> and <i>Y</i> are different versions
|
|
of the Berkeley DB library.
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
The fix for this is to properly install the Berkeley DB library.
|
|
For example, RedHat version 7.0 uses the Berkeley DB version 3
|
|
object library by default, but no /usr/include/db.h file is
|
|
installed by default. In order to correctly build Postfix you
|
|
must install the db3-devel package.
|
|
|
|
<p>
|
|
|
|
On a properly installed system, including the file <b><db.h></b>
|
|
and linking with <b>-ldb</b> should access files from the same
|
|
Berkeley DB library version.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="nosuid"><h3>sendmail has set-uid root file permissions, or is run from a
|
|
set-uid root process</h3></a>
|
|
|
|
Traditionally, the UNIX <b>sendmail</b> command is installed with
|
|
set-uid root permissions. Even many MTAs other than Sendmail ship
|
|
with a set-uid root <b>sendmail</b> command. This is not the case
|
|
with Postfix. The Postfix <b>sendmail</b> command is designed not
|
|
to be set-uid.
|
|
|
|
<p>
|
|
|
|
Unfortunately, some Linux systems have a helpful utility called
|
|
<b>linuxconf</b> that automatically "fixes" file permissions to
|
|
what they are supposed to be for Sendmail's <b>sendmail</b> command.
|
|
Even when you reset the set-uid bit on the Postfix <b>sendmail</b>
|
|
executable file, <b>linuxconf</b> will happily turn it on again
|
|
for you.
|
|
|
|
<p>
|
|
|
|
On SuSE systems the file permission fixing utulity is called
|
|
<b>SuSEconfig</b>. Other Linux systems may use different names.
|
|
The usual disclaimers about mileages etc. apply.
|
|
|
|
<p>
|
|
|
|
<h4>Solutions</h4>
|
|
|
|
<ul>
|
|
|
|
<li>Rask Ingemann Lambertsen has a particularly effective
|
|
solution :-)
|
|
|
|
<blockquote>
|
|
<pre>
|
|
# /etc/rc.d/init.d/linuxconf stop && rpm --erase linuxconf
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<li>According to Matthias Andree, the band-aid fix for SuSE is to
|
|
add to /etc/permissions.local the following line:
|
|
|
|
<blockquote>
|
|
<pre>
|
|
/usr/sbin/sendmail root.root 755
|
|
</pre>
|
|
</blockquote>
|
|
|
|
and to make sure that in /etc/rc.config,
|
|
PERMISSIONS_SECURITY mentions local last, EXAMPLE:
|
|
|
|
<blockquote>
|
|
<pre>
|
|
CHECK_PERMISSIONS=set
|
|
PERMISSION_SECURITY="secure local"
|
|
</pre>
|
|
</blockquote>
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="whoami"><h3>sendmail: unable to find out your login name</h3>
|
|
|
|
This message is logged when submitting mail from a process with a
|
|
userid that does not exist in the UNIX password file. Postfix uses
|
|
this information in order to set the envelope sender address.
|
|
|
|
<p>
|
|
|
|
The envelope sender address is also the default value for the From:
|
|
header address, when none is specified in the message.
|
|
|
|
<p>
|
|
|
|
To fix, specify the envelope sender address on the sendmail command
|
|
line:
|
|
|
|
<blockquote>
|
|
<pre>
|
|
sendmail -f user@domain ...
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<hr>
|
|
|
|
<a name="moby-freebsd"><h3>Running hundreds of Postfix processes on FreeBSD</h3></a>
|
|
|
|
With hundreds of Postfix processes, the kernel will eventually
|
|
run out of file handles; after that, it will run out of sockets.
|
|
|
|
<p>
|
|
|
|
To set the following kernel parameters at boot time, add the
|
|
following lines to the <b>/boot/loader.conf</b> file (this is
|
|
verified with FreeBSD 4.4):
|
|
|
|
<p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
kern.ipc.maxsockets="5000"
|
|
kern.ipc.nmbclusters="65536"
|
|
kern.maxproc="2048"
|
|
kern.maxfiles="16384"
|
|
kern.maxfilesperproc="16384"
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
With FreeBSD 4.2, the last three parameters cannot be set from
|
|
<b>/boot/loader.conf</b>. To set the open file limits, execute the
|
|
following commands as root:
|
|
|
|
<p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
# sysctl -w kern.maxfiles=16384
|
|
# sysctl -w kern.maxfilesperproc=16384
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
With FreeBSD 4.2, <b>kern.maxproc</b> can be set only by recompiling
|
|
the kernel with a different <b>maxusers</b> setting in the kernel
|
|
configuration file.
|
|
|
|
<hr>
|
|
|
|
<a name="moby-linux"><h3>Running hundreds of Postfix processes on Linux</h3></a>
|
|
|
|
When you increase the number of Postfix processes into the hundreds,
|
|
the kernel will eventually run out of file handles; after that it
|
|
is likely to run out of process slots.
|
|
|
|
<p>
|
|
|
|
The following information is kernel version dependent.
|
|
|
|
<p>
|
|
|
|
To set parameters at boot time on Linux systems that have
|
|
<b>/etc/sysctl.conf</b>, add the following lines:
|
|
|
|
<p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
fs.file-max = 16384
|
|
kernel.threads-max = 2048
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
To set kernel parameters at run time, execute the following
|
|
commands as <b>root</b>:
|
|
|
|
<p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
# echo 16384 > /proc/sys/fs/file-max
|
|
# echo 2048 > /proc/sys/kernel/threads-max
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<hr>
|
|
|
|
<a name="moby-sun"><h3>Running hundreds of Postfix processes on Solaris</h3></a>
|
|
|
|
In order to run hundreds of processes you may have to adjust the
|
|
per-process open file limit. According to the <a
|
|
href="http://www.science.uva.nl/pub/solaris/solaris2.html#q3.45">Solaris
|
|
FAQ</a>, add the following lines to /etc/system on Solaris 2.4 and later:
|
|
|
|
<p>
|
|
<blockquote>
|
|
<pre>
|
|
* set hard limit on file descriptors
|
|
set rlim_fd_max = 4096
|
|
* set soft limit on file descriptors
|
|
set rlim_fd_cur = 2048
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<hr>
|
|
|
|
<a name="moby-postfix"><h3>Running thousands of Postfix delivery agents</h3></a>
|
|
|
|
In order to run Postfix with more than a thousand delivery agents you
|
|
need to recompile the software with an appropriate value of the
|
|
<b>FD_SETSIZE</b> constant.
|
|
|
|
<p>
|
|
<blockquote>
|
|
<pre>
|
|
% make tidy
|
|
% make makefiles "CCARGS=-DFD_SETSIZE=2048"
|
|
% make
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<hr>
|
|
|
|
<a name="incoming"><h3>Mail stays queued in the incoming queue</h3></a>
|
|
|
|
<blockquote>
|
|
|
|
I have lots if mail in the incoming queue, but Postfix only runs
|
|
a few outbound SMTP deliveries. Why is it not running more SMTP
|
|
clients?
|
|
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
Your problem could be that the disk is saturated with I/O from
|
|
receiving mail, so that the Postfix queue manager gets insufficient
|
|
chance to process the requests (many SMTP server processes are
|
|
competing for disk access against one poor queue manager).
|
|
|
|
<p>
|
|
|
|
You solve the problem by getting faster disks.
|
|
|
|
<p>
|
|
|
|
I am still solving the scheduling problem from the software side,
|
|
but don't hold your breath.
|
|
|
|
<p>
|
|
|
|
Currently, the workaround is to configure multiple IP addresses
|
|
per machine, and to run one Postfix instance per IP address, each
|
|
instance preferably on a different disk. The Postfix instances
|
|
can't share queue directories, but sharing mailbox directories is
|
|
OK.
|
|
|
|
<p>
|
|
|
|
Just start each Postfix instance with a different configuration
|
|
directory:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
# postfix -c config_directory start
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Each main.cf file has a different <b>$myhostname</b> setting,
|
|
depending on the interface that it is supposed to handle.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/my/own/main.cf:
|
|
queue_directory = /my/own/queue/directory
|
|
myhostname = foo1.my.domain
|
|
inet_interfaces = $myhostname
|
|
</pre>
|
|
|
|
<hr>
|
|
|
|
<a name="delay"><h3>Postfix responds slowly to incoming SMTP connections</h3></a>
|
|
|
|
Question:
|
|
|
|
<blockquote>
|
|
|
|
My Postfix server is too slow. When I telnet to the SMTP port
|
|
(<tt>telnet hostname 25</tt>), the response comes after 40 seconds.
|
|
On the other hand, when I telnet to the POP port (<tt>telnet
|
|
hostname 110</tt>) the response comes with no delay.
|
|
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
Answer:
|
|
|
|
<blockquote>
|
|
|
|
You have a name service problem.
|
|
|
|
<p>
|
|
|
|
Postfix calls the C library routines <b>gethostbyname()</b> and
|
|
<b>gethostbyaddr()</b> in order to find out the SMTP client hostname.
|
|
These library routines use several system configuration files in
|
|
order to satisfy the request. They may in fact end up calling the
|
|
DNS for reasons that are not under control by Postfix.
|
|
|
|
<p>
|
|
|
|
Depending on your system, these controlling files can be named
|
|
<b>/etc/nsswitch.conf</b>, <b>/etc/svcorder</b>, <b>/etc/host.conf</b>
|
|
or otherwise. Those files specify whether the C library routines
|
|
will use local <b>/etc/hosts</b> before or after DNS.
|
|
|
|
</blockquote>
|
|
|
|
<hr>
|
|
|
|
<a name="numerical_log"><h3>Postfix logs SMTP clients as IP
|
|
addresses</h3>
|
|
|
|
<blockquote>
|
|
|
|
The Postfix SMTP server logs client connections with numerical IP
|
|
addresses instead of resolving the hostname. When I use <b>nslookup</b>
|
|
the address does resolve to a name.
|
|
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
You run the Postfix SMTP server inside a <b>chroot</b> jail for
|
|
extra security, but some configuration files are missing. In order
|
|
to run inside a chroot jail, the Postfix SMTP client and server
|
|
need copies of system configuration files inside the Postfix queue
|
|
directory. The exact list of files is very system dependent, but
|
|
you will probably need at the very least:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/var/spool/postfix/etc/resolv.conf
|
|
/var/spool/postfix/etc/services
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Of course, these directories and files must be owned by root, but
|
|
they must be accessible by the postfix user, so directories need
|
|
mode 0755 and files need mode 0644.
|
|
|
|
<p>
|
|
For more details, see the files in the <b>examples/chroot-setup</b>
|
|
directory of the Postfix source code distribution.
|
|
|
|
<hr>
|
|
|
|
<a name="paranoid"><h3>warning: xxx.xxx.xxx.xxx: address not listed
|
|
for hostname yyy.yyy.yyy</h3>
|
|
|
|
Postfix uses hostnames in its junk mail and mail relay controls.
|
|
This means that in theory someone could be motivated to set up
|
|
bogus DNS information, in order to get past your junk mail or mail
|
|
relay controls.
|
|
|
|
<p>
|
|
|
|
When Postfix looks up the SMTP client hostname for the SMTP client
|
|
IP address, then Postfix also checks if the SMTP client IP address
|
|
is listed under the SMTP client hostname.
|
|
|
|
<p>
|
|
|
|
If the SMTP client IP address is not listed under the SMTP client
|
|
hostname, then Postfix concludes that the SMTP client hostname does
|
|
not belong to the SMTP client IP address, and ignores the SMTP
|
|
client hostname. A warning is logged, so that you can find out why
|
|
an SMTP client is or is not stopped by your junk mail or mail relay
|
|
checks.
|
|
|
|
<p>
|
|
|
|
You could contact the people who maintain the SMTP client's DNS
|
|
records, and explain to them that each IP address needs one PTR
|
|
record, and that this one PTR record needs a matching A record.
|
|
|
|
<p>
|
|
|
|
Some people read the RFCs such that one IP address can have multiple
|
|
PTR records, but that makes PTR records even less useful than they
|
|
already are. And in any case, having multiple names per IP address
|
|
only worsens the problem of finding out the SMTP client hostname.
|
|
|
|
<hr>
|
|
|
|
<a name="open_relay"><h3>Help! Postfix is an open relay</h3>
|
|
|
|
According to some relay checking software, Postfix accepts
|
|
mail for arbitrary non-local destinations:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
>>> MAIL FROM:<someone@some.where>
|
|
<<< 250 Ok
|
|
>>> RCPT TO:<test@some.other.site@some.site>
|
|
<<< 250 Ok
|
|
>>> DATA
|
|
<<< 354 End data with <CR><LF>.<CR><LF>
|
|
>>> (message body)
|
|
<<< 250 Ok: queued as A958F5A15
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Don't Panic! Upgrade to a Postfix version of 19991227 or later.
|
|
To find out what Postfix version you have, execute the command
|
|
<b>postconf mail_version</b>.
|
|
|
|
<p>
|
|
|
|
With earlier Postfix versions,
|
|
|
|
<ol>
|
|
|
|
<li>Good but confusing: a Postfix primary MX host for <i>some.site</i>
|
|
accepts <i>test@some.other.site@some.site</i> then bounces it because
|
|
<i>test@some.other.site</i> is not a known local username.
|
|
|
|
<li>Good: a Postfix primary MX host for <i>some.site</i> rejects
|
|
other source-routed addresses such as <i>test%some.other.site@some.site</i>
|
|
or <i>some.other.site!test@some.site</i>.
|
|
|
|
<li>Loophole: a Postfix backup MX host for <i>some.site</i> forwards
|
|
source-routed addresses such as <i>test@some.other.site@some.site</i>
|
|
or <i>test%some.other.site@some.site</i> to a primary MX host for
|
|
<i>some.site</i>. Depending on the primary MX host's mailer
|
|
configuration, the primary MX host could then spam the mail into
|
|
the Internet.
|
|
|
|
</ol>
|
|
|
|
<p>
|
|
|
|
With newer Postfix versions,
|
|
|
|
<ol>
|
|
|
|
<li>A Postfix primary MX host for <i>some.site</i> host rejects
|
|
<i>test@some.other.site@some.site</i> just like it rejects
|
|
<i>test%some.other.site@some.site</i>. This ends the confusion
|
|
mentioned in 1 above.
|
|
|
|
<li>A Postfix backup MX host for <i>some.site</i> host rejects
|
|
source-routed addresses including <i>test@some.other.site@some.site</i>.
|
|
This closes the loophole mentioned in 3 above.
|
|
|
|
</ol>
|
|
|
|
<p>
|
|
|
|
To be precise, Postfix UCE restrictions refuse to forward source-routed
|
|
addresses under the following conditions:
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li> <a href="uce.html#check_relay_domains">check_relay_domains</a>:
|
|
reject when the destination is not local and when the client hostname
|
|
does not match <a href="uce.html#relay_domains">relay_domains</a>.
|
|
|
|
<li> <a
|
|
href="uce.html#permit_auth_destination">permit_auth_destination</a>:
|
|
skip when the destination is not local.
|
|
|
|
<li> <a
|
|
href="uce.html#reject_unauth_destination">reject_unauth_destination</a>:
|
|
reject when the destination is not local.
|
|
|
|
<li> <a href="uce.html#permit_mx_backup">permit_mx_backup</a>:
|
|
permit if the local system is listed as MX host for the recipient
|
|
domain. Use the optional <a
|
|
href="#permit_mx_backup_networks">permit_mx_backup_networks</a>
|
|
parameter to also require that the primary MX hosts match a list
|
|
of network blocks (Postfix versions 20011008 and later).
|
|
|
|
<li> Other UCE restrictions (e.g., SMTPD access maps) are not aware
|
|
of sender-provided routing information.
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
However, a Postfix primary MX host for still forwards source-routed
|
|
addresses <b>if received from a trusted client</b>, just like it
|
|
did before.
|
|
|
|
<p>
|
|
|
|
In order to have guaranteed protection against source-routed relaying
|
|
through trusted SMTP clients, specify a regular expression restriction
|
|
ahead of the other SMTPD recipient restrictions:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
smtpd_recipient_restrictions =
|
|
regexp:/etc/postfix/regexp_access
|
|
...other restrictions...
|
|
|
|
/etc/postfix/regexp_access:
|
|
/[%!@].*[%!@]/ 550 Sender specified routing is not supported here.
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
This would be installed on all MX hosts.
|
|
|
|
<hr>
|
|
|
|
<a name="mobile"><h3>Relaying mail for mobile users </h3>
|
|
|
|
<blockquote>
|
|
|
|
I have Postfix setup on a machine but I'd like to have a select
|
|
group of Internet users be able to relay mail through it. I'd
|
|
either like to base the relaying on IP address (e.g., a 256-block
|
|
for dynamic IP people) or on hostname (whatever.dialup.isp.com)
|
|
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
The most preferable way is to have users submit mail via some
|
|
authenticated protocol instead of plain old SMTP.
|
|
|
|
<p>
|
|
|
|
The next best way is to use plain old SMTP and to authenticate the
|
|
user first, for example, with a "please login via POP before using
|
|
SMTP" scheme. In that case, some software
|
|
maintains
|
|
a Postfix-compatible access table with client IP address information.
|
|
In order to make this work you need Postfix version 19991231 or later.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
smtpd_recipient_restrictions =
|
|
permit_mynetworks
|
|
check_client_access hash:/etc/postfix/client_access
|
|
check_relay_domains
|
|
|
|
/etc/postfix/client_access:
|
|
4.3.2.1 OK
|
|
5.4.3.2 987654321
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Specify <B>dbm</b> instead of <b>hash</b> if your system uses
|
|
<b>dbm</b> files instead of <b>db</b> files. To find out what map
|
|
types Postfix supports, use the command <b>postconf -m</b>.
|
|
|
|
<p>
|
|
|
|
N.B. Some non-Postfix software such as <a
|
|
href="http://mail.cc.umanitoba.ca/drac/">DRAC</a> uses <b>btree</b>
|
|
files instead of <b>hash</b> files. In that case, you will have
|
|
to adjust the above <b>check_client_access</b> restriction accordingly.
|
|
|
|
<p>
|
|
|
|
A less preferable way is based on client IP address (for example,
|
|
a 256-block) or DNS hostname (for example, whatever.pop.isp.com).
|
|
This scheme does not authenticate the user. If you use IP/DNS-based
|
|
relay access control, pray that no customer with that same ISP
|
|
points their spam software at your machine, or else you may end up
|
|
on internet-wide black lists.
|
|
|
|
<p>
|
|
|
|
The least preferable way is based on the sender address. It is
|
|
trivially easy to spoof by anyone who ever received mail from your
|
|
site. If you use sender address access control, pray that no
|
|
spammer ever finds out the address of your users.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
smtpd_recipient_restrictions =
|
|
permit_mynetworks
|
|
check_client_access hash:/etc/postfix/client_access
|
|
check_sender_access hash:/etc/postfix/sender_access
|
|
check_relay_domains
|
|
|
|
/etc/postfix/client_access:
|
|
11.22.33 OK
|
|
dialup.isp.com OK
|
|
|
|
/etc/postfix/sender_access:
|
|
joe@my.domain OK
|
|
blow@my.domain OK
|
|
</pre>
|
|
|
|
<hr>
|
|
|
|
<a name="relay_restrict"><h3>Restricting what users can send mail to off-site destinations</h3>
|
|
|
|
<blockquote>
|
|
|
|
How can I configure Postfix in a way that some users can send mail
|
|
to the internet and other users not. The users with no access should
|
|
receive a generic bounce message. Please don't discuss whether such
|
|
access restrictions are necessary, it was not my decision.
|
|
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
Postfix has support for per-user restrictions. The restrictions
|
|
are implemented by the SMTP server. Thus, users that violate the
|
|
policy have their mail rejected by the SMTP server. Like this:
|
|
|
|
<p>
|
|
|
|
<blockquote>
|
|
|
|
<pre>
|
|
554 <user@remote>: Access denied
|
|
</pre>
|
|
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
The implementation uses two lookup tables. One table defines what
|
|
users are restricted in where they can send mail, and the other
|
|
table defines what destinations are local. It is left as an exercise
|
|
for the reader to change this into a scheme where only some users
|
|
have permission to send mail to off-site destinations, and
|
|
where most users are restricted.
|
|
|
|
<p>
|
|
|
|
The example assumes DB/DBM files, but this could also be done with
|
|
LDAP or SQL.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
smtpd_recipient_restrictions =
|
|
check_sender_access hash:/etc/postfix/restricted_senders
|
|
...other stuff...
|
|
|
|
smtpd_restriction_classes = local_only
|
|
local_only = check_recipient_access hash:/etc/postfix/local_domains, reject
|
|
|
|
/etc/postfix/restricted_senders:
|
|
foo@domain local_only
|
|
bar@domain local_only
|
|
|
|
/etc/postfix/local_domains:
|
|
this.domain OK <i>matches this.domain and subdomains</i>
|
|
that.domain OK <i>matches that.domain and subdomains</i>
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Specify <B>dbm</b> instead of <b>hash</b> if your system uses
|
|
<b>dbm</b> files instead of <b>db</b> files. To find out what map
|
|
types Postfix supports, use the command <b>postconf -m</b>.
|
|
|
|
<p>
|
|
|
|
The <b>smtpd_restriction_classes</b> verbiage exists so that Postfix can
|
|
open <b>/etc/postfix/local_domains.db</b> before entering a chroot
|
|
jail, so it is only an artefact of implementation.
|
|
|
|
<p>
|
|
|
|
This scheme does not authenticate the user, therefore it can be
|
|
bypassed in several ways:
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li>By sending mail as someone else who does have permission to
|
|
send mail to off-site destinations.
|
|
|
|
<p>
|
|
|
|
<li>By sending mail as yourself via a less restrictive mail relay
|
|
host.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="backup"><h3>Configuring Postfix as backup MX host</h3></a>
|
|
|
|
When you are <b>secondary mx</b> for a <b>remote site</b> this is
|
|
all you need:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
DNS:
|
|
the.backed-up.domain.name IN MX 100 your.machine.name
|
|
|
|
/etc/postfix/main.cf:
|
|
relay_domains = $mydestination the.backed-up.domain.name
|
|
smtpd_recipient_restrictions = permit_mynetworks check_relay_domains
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
When you are <b>primary mx</b> for a <b>remote site</b> you also
|
|
need:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
transport_maps = hash:/etc/postfix/transport
|
|
|
|
/etc/postfix/transport:
|
|
the.backed-up.domain.name smtp:[their.mail.host.name]
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Specify <B>dbm</b> instead of <b>hash</b> if your system uses
|
|
<b>dbm</b> files instead of <b>db</b> files. To find out what map
|
|
types Postfix supports, use the command <b>postconf -m</b>.
|
|
|
|
<hr>
|
|
|
|
<a name="dns-again"><h3>Mail stays queued with: Host not found, try again</h3></a>
|
|
|
|
<blockquote>
|
|
|
|
When I send mail to a remote address, the following happens:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
Jul 14 12:45:38 myhostname postfix/qmgr[2246]: 74FBF30501:
|
|
from=<sender@sender.domain> size=309 (queue active)
|
|
Jul 14 12:45:39 myhostname postfix/smtp[2349]: 74FBF30501:
|
|
to=<recip@recip.domain> relay=none, delay=3944, status=deferred (Name
|
|
service error for domain recip.domain: Host not found, try again)
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
However, I can nslookup the hostname just fine.
|
|
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
There can be several different problems.
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li> First of all, the result of nslookup for the hostname may be
|
|
irrelevant. Postfix is required to look up the MX record first. So
|
|
your nslookup test should begin with asking for the MX record. Some
|
|
DNS servers are broken and produce no reply when asked for a
|
|
non-existent MX record.
|
|
|
|
<p> <li>
|
|
|
|
Check out your Postfix <b>master.cf</b> file. If the SMTP client
|
|
runs chrooted, then it needs a bunch of files inside the Postfix
|
|
queue directory. Examples are in the source distribution in the
|
|
<b>examples</b> subdirectory.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="timeouts"><h3>Mail fails consistently with timeout or lost connection</h3></a>
|
|
|
|
Every now and then, mail fails with "timed out while sending end
|
|
of data -- message may be sent more than once", or with: "lost
|
|
connection after DATA". Network outages happen, systems crash.
|
|
There isn't much you can do about it. Usually the problem goes away
|
|
by itself.
|
|
|
|
<p>
|
|
|
|
However, when you see mail deliveries fail consistently, you may
|
|
have a different problem: broken path MTU discovery. Or it could
|
|
be a broken PIX firewall.
|
|
|
|
<h4>Cisco PIX "fixup protocol smtp" bug</h4>
|
|
|
|
The Cisco PIX firewall has a bug when running software older than
|
|
version 5.2(4) or 6.0(1).
|
|
|
|
<p>
|
|
|
|
The bug ID is CSCds90792. The "fixup protocol smtp" feature does
|
|
not correctly handle the case where the "." and the "CRLF" at the
|
|
end of mail are sent in separate packets.
|
|
|
|
<p>
|
|
|
|
How does one recognize a mailer behind a Cisco PIX with "fixup
|
|
protocol smtp" enabled? As of version 5.1 and later, the fixup
|
|
protocol smtp command changes the characters in the SMTP banner to
|
|
asterisks except for the "2", "0" and "0 SPACE" characters.
|
|
|
|
<p>
|
|
|
|
When you connect to a mailer behind such a filter you see something
|
|
like:
|
|
|
|
<blockquote>
|
|
<pre>
|
|
220 **************************************0******0*********20 ****200**0*********0*00
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<h4>IP path MTU discovery</h4>
|
|
|
|
A little background is in order. With the SMTP protocol, the HELO,
|
|
MAIL FROM and RCPT TO commands and responses are relatively short.
|
|
When you're talking to old versions of sendmail, every command and
|
|
every response is sent as a separate packet, because sendmail didn't
|
|
implement ESMTP command pipelining until recently.
|
|
|
|
<p>
|
|
|
|
The message content, however, is sent as a few datagrams, each
|
|
datagram typically a kbyte large or even bigger, depending on your
|
|
local network MTU.
|
|
|
|
<p>
|
|
|
|
When mail fails consistently due to a timeout, I suspect that the
|
|
sending machine runs a modern UNIX which implements path MTU
|
|
discovery. That causes the machine to send packets as large as it
|
|
would send over the LAN, with the IP DON'T FRAGMENT bit set,
|
|
preventing intermediate routers from fragmenting the packets that
|
|
are too big for their networks.
|
|
|
|
<p>
|
|
|
|
Depending on what network path a message follows, some router on
|
|
the way responds with an ICMP MUST FRAGMENT message saying the
|
|
packet is too big. Normally, the sending machine will re-send the
|
|
data after chopping it up into smaller pieces.
|
|
|
|
<p>
|
|
|
|
However, things break when some router closer to the sending system
|
|
is dropping such ICMP feedback messages, in a mistaken attempt to
|
|
protect systems against certain attacks. In that case, the ICMP
|
|
feedback message never reaches the sending machine, and the connection
|
|
times out.
|
|
|
|
<p>
|
|
|
|
This is the same configuration problem that causes trouble with
|
|
web servers behind a misconfigured packet filter: small images/files
|
|
are sent intact, large images/files time out because the server
|
|
does not see the MUST FRAGMENT ICMP feedback messages.
|
|
|
|
<p>
|
|
|
|
Workaround: disable path MTU discovery at the sending machine. Mail
|
|
will get out, but of course everyone else will still suffer. How
|
|
to disable path MTU discovery? It depends. Solaris has an <b>ndd</b>
|
|
command; other systems use different means such as <b>sysctl</b>
|
|
to control kernel parameters on a running system.
|
|
|
|
<p>
|
|
|
|
Fix: find the router that drops the ICMP MUST FRAGMENT messages,
|
|
and convince the person responsible for it to fix the configuration.
|
|
|
|
<hr>
|
|
|
|
<a name="skip_greeting"><h3>Postfix does not try all the MX
|
|
addresses</h3>
|
|
|
|
When delivering mail, Postfix tries all MX addresses in order of
|
|
preference, and stops at the first server that speaks SMTP.
|
|
|
|
<p>
|
|
|
|
If the first server that speaks SMTP rejects the connection by
|
|
greeting the client with a 5xx status code, which means "I will
|
|
never accept your mail", Postfix gives up and bounces the message
|
|
to the sender.
|
|
|
|
<p>
|
|
|
|
If the first server that speaks SMTP rejects the connection by
|
|
greeting the client with a 4xx status code, which means "come back
|
|
later", Postfix backs off and defers delivery until later.
|
|
|
|
<p>
|
|
|
|
Some people will argue that Postfix should contact the other MX
|
|
addresses even when the server greets with 4xx or 5xx, if only
|
|
because that is what Sendmail does, and of course we know that
|
|
everything Sendmail does is right.
|
|
|
|
<p>
|
|
|
|
Unfortunately, some people configure their infrastructure badly.
|
|
Their most preferred MX server is visible to the world but it
|
|
rejects connections from outside with a 5xx or 4xx greeting. Just
|
|
because Sendmail goes to the second-best MX server, these people
|
|
assume that every mailer will do so.
|
|
|
|
<p>
|
|
|
|
If such configurations are a problem for you, below are some controls
|
|
that work around them.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
smtp_skip_4xx_greeting = yes
|
|
smtp_skip_5xx_greeting = yes
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
The <b>smtp_skip_5xx_greeting</b> is present in Postfix releases
|
|
later than 20000104. To find out what Postfix version you have,
|
|
use the command <b>postconf mail_version</b>.
|
|
|
|
<p>
|
|
|
|
Execute the command <b>postfix reload</b> to make the change
|
|
effective immediately.
|
|
|
|
<a name="noservice"><h3>What does "fatal: unknown service: smtp/tcp"
|
|
mean?</h3>
|
|
|
|
The Postfix <b>/etc/postfix/master.cf</b> file specifies that the
|
|
Postfix SMTP client runs inside a <b>chroot</b> environment. However,
|
|
the files necessary for that mode of operation are not installed
|
|
below <b>/var/spool/postfix</b>.
|
|
|
|
<p>
|
|
|
|
Enabling <b>chroot</b> operation adds a non-trivial barrier for
|
|
system penetrators.
|
|
|
|
<p>
|
|
|
|
Two solutions:
|
|
|
|
<ul>
|
|
|
|
<li> Disable the <b>chroot</b> in <b>/etc/postfix/master.cf</b>
|
|
(and issue <b>postfix reload</b> when done).
|
|
|
|
<p>
|
|
|
|
<li>Install the necessary files for <b>chroot</b> operation.
|
|
Instructions are given in the source code distribution, in the
|
|
<b>examples/chroot-setup</b> directory.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="broken_transport"><h3>Mail delivery fails with: "unknown
|
|
mail transport error"</h3>
|
|
|
|
This is an opportunity to meet your friends <b>egrep</b> and
|
|
<b>less</b>. Postfix activity, including progres and failure, is
|
|
logged to a logfile, typically named <b>/var/log/maillog</b>. To
|
|
find out where Postfix activity is logged on your machine, examine
|
|
the <b>/etc/syslog.conf</b> file.
|
|
|
|
<p>
|
|
|
|
To find out the cause for the "unknown mail transport error", type
|
|
the following command:
|
|
|
|
<blockquote>
|
|
|
|
<tt>egrep '(warning|fatal|panic):' /var/log/maillog | less</tt>
|
|
|
|
</blockquote>
|
|
|
|
Pay particular attention to messages that are labeled as <b>fatal</b>
|
|
and <b>panic</b>. These describe catastrophic failures that need
|
|
to be addressed before Postfix is happy. Problems labeled as
|
|
<b>fatal</b> are fixed by you, by adjusting configuration files,
|
|
file permissions and so on. Problems labeled as <b>panic</b> are
|
|
fixed by the Postfix author, by changing Postfix source code.
|
|
|
|
<hr>
|
|
|
|
<a name="root"> <h3>Root's mail is delivered to nobody</h3>
|
|
|
|
If you use <a href="#procmail">procmail</a> (or some other command)
|
|
for local mail delivery, Postfix will not deliver mail as root.
|
|
Instead, Postfix runs <b>procmail</b> (or whatever) as <b>nobody</b>.
|
|
Perhaps some day Wietse will trust Postfix enough to run external
|
|
commands as <b>root</b>.
|
|
|
|
<p>
|
|
|
|
Solution: just like you're not supposed to log in as <b>root</b>
|
|
(except for unusual conditions), you're not supposed to receive
|
|
mail as <b>root</b>.
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li>Create a mail alias for <b>root</b> that forwards mail to a
|
|
real user.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/aliases:
|
|
root: you
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<li>Execute the command <b>newaliases</b> whenever you change the
|
|
alias database.
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
On some systems the alias database is not in <b>/etc/aliases</b>.
|
|
To find out the location for your system, execute the command
|
|
<b>postconf alias_maps</b>.
|
|
|
|
<hr>
|
|
|
|
<a name="biff"><h3>What does "biff_notify: Connection refused" mean?</h3>
|
|
|
|
By default, the Postfix local delivery agent attempts to notify
|
|
local users of the arrival of new mail. This feature makes use of
|
|
the <b>comsat</b> network service, which is turned off on many UNIX
|
|
systems for performance and/or security reasons.
|
|
|
|
<p>
|
|
|
|
The warning message means that new mail notificiation failed because
|
|
the <b>comsat</b> network service is turned off.
|
|
|
|
<p>
|
|
|
|
To disable the <b>comsat</b> client code in the Postfix delivery agent,
|
|
specify:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
biff = no
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
To enable the <b>comsat</b> network service, uncomment the
|
|
corresponding entry in the <b>inetd.conf</b> file, and <b>kill -HUP</b>
|
|
the <b>inetd</b> process.
|
|
|
|
<hr>
|
|
|
|
<a name="nisdom"><h3>What does "NIS domain name not set - NIS lookups disabled" mean?</h3>
|
|
|
|
<p>
|
|
|
|
The warning message means that NIS (Network Information Service)
|
|
is not enabled on your machine. That is perfectly OK. It's just
|
|
hard for Postfix to find out about these things ahead of time.
|
|
|
|
<p>
|
|
|
|
To disable the <b>NIS</b> client code in the Postfix local delivery agent,
|
|
update the corresponding section in the <b>main.cf</b> file and specify
|
|
one of the following, depending on the type of aliases file:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
alias_maps = $alias_database
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
This forces Postfix to use only the local aliases database, if one
|
|
is defined.
|
|
|
|
<hr>
|
|
|
|
<a name="bogus"><h3>Postfix accepts mail for non-existing local users</h3>
|
|
|
|
See elsewhere for how to reject mail for <a
|
|
href="#unknown_virtual_accept">unknown users in virtual domains</a>.
|
|
|
|
<p>
|
|
|
|
The information in this section applies to Postfix versions 19991216
|
|
and later. To find out what Postfix version you have, execute the
|
|
command <b>postconf mail_version</b>.
|
|
|
|
<p>
|
|
|
|
By default, the Postfix SMTP server does not know what local users
|
|
exist, and will happily accept mail for <i>unknown@your.site</i>.
|
|
The reason is that different local delivery agents have different
|
|
types of user databases.
|
|
|
|
<p>
|
|
|
|
Of course mail for a non-existent local user will eventually bounce
|
|
as undeliverable, but why accept such mail in the first place? You
|
|
can tell the Postfix SMTP server how to find out if a user exists by
|
|
listing all tables with local addresses in the <b>local_recipient_maps</b>
|
|
parameter.
|
|
|
|
<p>
|
|
|
|
For example, if you use the default Postfix local delivery agent
|
|
in <b>/etc/postfix/master.cf</b>, specify:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
local_recipient_maps = $alias_maps, unix:passwd.byname
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
However, if you run the Postfix SMTP server chrooted, on some
|
|
systems it will be necessary to have a copy of the passwd file
|
|
inside the chroot jail (typically: in <b>/var/spool/postfix/etc</b>).
|
|
The only way to find out is to try.
|
|
|
|
<p>
|
|
|
|
By default, the Postfix SMTP server is aware of Postfix <a
|
|
href="virtual.5.html">virtual</a> maps, and will accept mail for
|
|
<i>known-user@virtual.domain</i> without further configuration.
|
|
|
|
<hr>
|
|
|
|
<a name="some_local"><h3>Delivering some users locally while sending
|
|
mail as user@domain</h3></a>
|
|
|
|
<ul>
|
|
|
|
<li>In order to send mail as <i>user@domain.name</i>, specify what
|
|
domain is to be appended to addresses that do not have a domain:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
myorigin = domain.name
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<li>In order to receive some users locally, such as <b>root</b> or
|
|
<b>postmaster</b>, specify a virtual lookup table with the non-default
|
|
destinations:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
virtual_maps = hash:/etc/postfix/virtual
|
|
|
|
/etc/postfix/virtual:
|
|
root root@localhost
|
|
postmaster postmaster@localhost
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Specify <B>dbm</b> instead of <b>hash</b> if your system uses
|
|
<b>dbm</b> files instead of <b>db</b> files. To find out what map
|
|
types Postfix supports, use the command <b>postconf -m</b>.
|
|
|
|
<p>
|
|
|
|
<li>Execute the command <b>postmap /etc/postfix/virtual</b> whenever
|
|
you edit the <b>virtual</b> table.
|
|
|
|
<p>
|
|
|
|
<li>Execute the command <b>postfix reload</b> to make the changes
|
|
effective.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="maildir"><h3>Support for maildir-style mailboxes</h3> </a>
|
|
|
|
<b>Maildir</b> is a specific one-file-per-message organization that
|
|
was introduced with the <b>qmail</b> system by Daniel Bernstein.
|
|
In order to turn on <b>maildir</b>-style delivery, specify,
|
|
for example:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
home_mailbox = Maildir/
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Any relative pathname that ends in <b>/</b> turns on <b>maildir</b>
|
|
delivery. The <b>home_mailbox</b> value is appended to the user's
|
|
home directory pathname.
|
|
|
|
<p>
|
|
|
|
The <b>maildir</b> format is also supported with delivery via
|
|
aliases or via <b>.forward</b> files. Specify <i>/file/name/</i>
|
|
as destination. The trailing <b>/</b> turns on <b>maildir</b>
|
|
delivery.
|
|
|
|
<hr>
|
|
|
|
<a name="procmail"><h3>Using Procmail for system-wide local delivery</h3> </a>
|
|
|
|
Warning: if you use <b>procmail</b> in this manner, you must set
|
|
up an alias for <b>root</b> that forwards mail for <b>root</b> to
|
|
a real user. See the FAQ entry titled "<a href="#root">Mail for root
|
|
is delivered to nobody</a>".
|
|
|
|
<ul>
|
|
|
|
<li>Specify that all mailbox delivery is to be done by <b>procmail</b>.
|
|
For example:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
mailbox_command = /path/to/procmail
|
|
|
|
/etc/postfix/main.cf:
|
|
mailbox_command = /path/to/procmail -a $EXTENSION
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
If you can, avoid using any shell meta characters or built-ins such
|
|
as <b>$</b> or <b>"</b> or <b>IFS</b> or <b>&&</b>, because
|
|
they force Postfix to run an expensive shell process. However,
|
|
procmail is a pig, and the gain of avoiding a shell can be
|
|
unnoticeable.
|
|
|
|
<p>
|
|
|
|
<li>Execute the command <b>postfix reload</b> to make the changes
|
|
effective.
|
|
|
|
</ul>
|
|
|
|
Postfix exports information via environment variables. The contents
|
|
are censored. Characters that may have special meaning to the shell,
|
|
including whitespace, are replaced by underscores.
|
|
|
|
<p>
|
|
|
|
<blockquote>
|
|
|
|
<dl>
|
|
|
|
<dt><b>DOMAIN</b> <dd> The text to the right-hand side of the
|
|
<b>@</b> in the recipient address.
|
|
|
|
<dt><b>EXTENSION</b> <dd> Optional address extension part.
|
|
|
|
<dt><b>HOME</b> <dd> The recipient's home directory.
|
|
|
|
<dt><b>LOCAL</b> <dd> The text to the left-hand side of the <b>@</b>
|
|
in the recipient address, for example, <b>$USER+$EXTENSION</b>.
|
|
|
|
<dt><b>LOGNAME</b> <dd> The recipient username.
|
|
|
|
<dt><b>RECIPIENT</b> <dd> The entire recipient address,
|
|
<b>$LOCAL@$DOMAIN</b>.
|
|
|
|
<dt><b>SHELL</b> <dd> The recipient's login shell.
|
|
|
|
<dt><b>USER</b> <dd> The recipient username.
|
|
|
|
</dl>
|
|
|
|
</blockquote>
|
|
|
|
<hr>
|
|
|
|
<a name="delivered"><h3>Getting rid of the ugly Delivered-To: header</h3> </a>
|
|
|
|
Some people will complain about the ugly <b>Delivered-To:</b>
|
|
message header that Postfix prepends to their mail. By default,
|
|
Postfix prepends this header when forwarding mail, and when delivering
|
|
to file (mailbox) or command. The purpose is to stop mail forwarding
|
|
loops as early as possible, that is, before they have a chance to
|
|
happen. But the header is ugly, no question about it.
|
|
|
|
<p>
|
|
|
|
Solutions, ranging from fighting symptoms to turning off the
|
|
<b>Delivered-To:</b> header:
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li>
|
|
|
|
Fortunately, many mail user agents have per-user or even system-wide
|
|
configuration files that can be set up to suppress <b>Delivered-To:</b>
|
|
headers (for example <b>~/.mailrc</b> and <b>/usr/lib/Mail.rc</b>).
|
|
|
|
<p>
|
|
|
|
<li>
|
|
|
|
With mailing lists, <b>Delivered-To:</b> can get in the way when
|
|
the list exploder uses a "secret" alias that should not be shown
|
|
in outbound mail. The recommended solution is to use a regular
|
|
expression-based filter at the SMTP port:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
smtpd_recipient_restrictions =
|
|
... regexp:/etc/postfix/access_regexp ...
|
|
smtpd_recipient_restrictions =
|
|
... pcre:/etc/postfix/access_regexp ...
|
|
|
|
/etc/postfix/access_regexp:
|
|
/^(.*)-outgoing@(.*)/ 554 Use $1@$2 instead
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
POSIX regular expression support (regexp) is enabled by default on
|
|
modern UNIX systems. Perl-compatible regular expression support
|
|
(pcre) is optional; see the PCRE_README file in the top-level
|
|
Postfix source directory.
|
|
|
|
<p>
|
|
|
|
<li>
|
|
|
|
The <b>prepend_delivered_header</b> configuration parameter controls
|
|
when <b>Delivered-To:</b> is prepended. The default setting is
|
|
<b>command, file, forward</b> (translation: prepend <b>Delivered-To:</b>
|
|
when delivering to command, when delivering to file, and when
|
|
forwarding mail). <i>Turning off <b>Delivered-To:</b> when forwarding
|
|
mail is not recommended</i>.
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
See also the FAQ item for problems with the <b>majordomo</b> <a
|
|
href="#majordomo-approve">approve</a> command.
|
|
|
|
<hr>
|
|
|
|
<a name="majordomo-approve"><h3>Postfix breaks the majordomo "approve"
|
|
command</h3> </a>
|
|
|
|
The Postfix local delivery agent prepends a <b>Delivered-To:</b>
|
|
message header to prevent mail forwarding loops. With <b>majordomo</b>
|
|
mailing lists, <b>Delivered-To:</b> gets in the way when the
|
|
moderator wants to approve postings that were sent to the list.
|
|
The Postfix system claims that the mail is looping.
|
|
|
|
<p>
|
|
|
|
Currently, the recommended workaround is to edit the <b>approve</b>
|
|
script to strip any header lines that match:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/delivered-to/i
|
|
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Yes, this assumes that the moderator knows what she is doing.
|
|
|
|
<p>
|
|
|
|
A less-preferred workaround is to not insert <b>Delivered-To:</b>
|
|
when delivering to commands such as majordomo. See the FAQ entry
|
|
titled "<a href="#delivered">Getting rid of the ugly Delivered-To:
|
|
header</a>".
|
|
|
|
<hr>
|
|
|
|
<a name="worm"><h3>Postfix accepts MAIL FROM and RCPT TO "| command"</h3>
|
|
|
|
With Postfix, | or / has special meaning only when it appears in
|
|
aliases, .forward files or in :include: files. It has no special
|
|
meaning in mail addresses.
|
|
|
|
|
|
<p>
|
|
|
|
If you must receive mail for systems with 10-year old vulnerabilities,
|
|
it is prudent to set up a regexp filter that rejects potentially
|
|
harmful MAIL FROM or RCPT TO commands.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
smtpd_sender_restrictions =
|
|
regexp:/etc/postfix/envelope-regexp
|
|
reject_unknown_sender_domain
|
|
smtpd_recipient_restrictions =
|
|
regexp:/etc/postfix/envelope-regexp
|
|
permit_mynetworks
|
|
check_relay_domains
|
|
|
|
/etc/postfix/envelope-regexp:
|
|
/[/|]/ REJECT
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
However, rejecting all envelope addresses with / causes trouble
|
|
with simple-minded X.400 to Internet address mappings that leave
|
|
the X.400 address structure exposed.
|
|
|
|
<p>
|
|
|
|
See also the documentation on <a href="uce.html#header_checks">header
|
|
checks</a> restrictions for message header contents. These restrictions
|
|
can be used to protect against attacks with command/file destinations
|
|
in, for example, Errors-To: or Return-Receipt_To: message headers.
|
|
|
|
<hr>
|
|
|
|
<a name="internal-list"><h3>Protecting internal email distribution lists</h3>
|
|
|
|
<blockquote>
|
|
|
|
We want to implement an internal email distribution list. Something
|
|
like all@our.domain.com, which aliases to all employees. My first
|
|
thought was to use the aliases map, but that would lead to "all"
|
|
being accessible from the "outside", and this is not desired...
|
|
:-)
|
|
|
|
</blockquote>
|
|
|
|
Postfix can implement per-address access controls. What follows
|
|
is based on the SMTP client IP address, and therefore is subject
|
|
to IP spoofing.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
smtpd_recipient_restrictions =
|
|
hash:/etc/postfix/access
|
|
..the usual stuff...
|
|
|
|
/etc/postfix/access:
|
|
all permit_mynetworks,reject
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Specify <B>dbm</b> instead of <b>hash</b> if your system uses
|
|
<b>dbm</b> files instead of <b>db</b> files. To find out what map
|
|
types Postfix supports, use the command <b>postconf -m</b>.
|
|
|
|
<p>
|
|
|
|
Now, that would be sufficient when your machine receives all Internet
|
|
mail directly from the Internet. That's unlikely if your network
|
|
is a bit larger than an office. For example your backup MX hosts
|
|
would "launder" the client IP address of mail from outside so it
|
|
would appear to come from a trusted machine.
|
|
|
|
<p>
|
|
|
|
In the general case you need two lookup tables: one table that
|
|
lists destinations that need to be protected, and one table that
|
|
lists domains that are allowed to send to the protected destinations.
|
|
|
|
<p>
|
|
|
|
What follows is based on the sender SMTP envelope address, and
|
|
therefore is subject to SMTP sender spoofing.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
smtpd_recipient_restrictions =
|
|
hash:/etc/postfix/protected_destinations
|
|
..the usual stuff...
|
|
|
|
smtpd_restriction_classes = insiders_only
|
|
insiders_only = check_sender_access hash:/etc/postfix/insiders, reject
|
|
|
|
/etc/postfix/protected_destinations:
|
|
all@my.domain insiders_only
|
|
all@my.hostname insiders_only
|
|
|
|
/etc/postfix/insiders:
|
|
my.domain OK
|
|
another.domain OK
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
The smtpd_restriction_classes verbiage is needed so that Postfix
|
|
knows what lookup tables to open before it goes to chroot jail.
|
|
It is only an artefact of the implementation.
|
|
|
|
<p>
|
|
|
|
Getting past this scheme is relatively easy, because all one has
|
|
to do is to spoof the SMTP sender address.
|
|
|
|
<p>
|
|
|
|
If the internal list is a low-volume one, perhaps it makes more
|
|
sense to make it moderated.
|
|
|
|
<hr>
|
|
|
|
<a name="unknown_virtual_accept"><h3>Postfix does not refuse mail for
|
|
unknown users in virtual domains</h3></a>
|
|
|
|
<a name="unknown_virtual_loop"><h3>Mail for unknown users in a
|
|
virtual domain fails with "mail loops back to myself"</h3></a>
|
|
|
|
<a name="virtual_relay"><h3>Postfix refuses mail for virtual
|
|
domains with "relay access denied"</h3></a>
|
|
|
|
Solution: specify a Postfix-style virtual domain or a Sendmail-style
|
|
virtual domain.
|
|
|
|
<p>
|
|
|
|
Sendmail-style virtual domains are not supported in Postfix versions
|
|
released before 20001118.
|
|
|
|
<p>
|
|
|
|
Be sure to follow instructions in the <a href="virtual.5.html">
|
|
virtual</a> manual page.
|
|
|
|
<hr>
|
|
|
|
<a name="virtual_command"><h3>Commands, mailing, and /file/name destinations don't work
|
|
in Postfix virtual maps</h3>
|
|
|
|
Short reply: specify a Sendmail-style <a href="virtual.5.html">virtual</a>
|
|
domain, and specify the command, mailing list, or /file/name
|
|
destination in the local <a href="aliases.5.html">aliases</a> file.
|
|
|
|
<p>
|
|
|
|
Long reply follows.
|
|
|
|
<p>
|
|
|
|
Delivering mail to a file or command is a security-sensitive
|
|
operation, because the operation must be executed with the right
|
|
privileges. Only <b>root</b>-privileged software such as the
|
|
Postfix local delivery agent can set the privileges for command
|
|
or file delivery.
|
|
|
|
<p>
|
|
|
|
For security reasons, Postfix tries to avoid using <b>root</b>
|
|
privileges where possible. In particular, Postfix virtual mapping
|
|
is done by an unprivileged daemon, so there is no secure way to
|
|
execute commands or to deliver to files specified in virtual maps.
|
|
|
|
<hr>
|
|
|
|
<a name="domain_mailbox"><h3>Receiving a virtual domain in a mailbox</h3>
|
|
|
|
Question: how to receive all mail for a domain in a mailbox without
|
|
losing the original recipient information? The Postfix Delivered-To:
|
|
mail header shows only the mailbox owner, not the virtual address
|
|
that the mail was sent to.
|
|
|
|
<p>
|
|
|
|
Answer: I hope we all agree that delivering a domain to a mailbox
|
|
is disgusting practice. Forwarding mail via SMTP or UUCP would be
|
|
a much better choice. Unfortunately, neither SMTP nor UUCP are a
|
|
usable alternative for legions of windows users. However, if this
|
|
is an option for you see the <a href="#uucp-tcp">UUCP over TCP</a>
|
|
guide below.
|
|
|
|
<p>
|
|
|
|
That said, it is possible to propagate the original virtual recipient
|
|
information to the Delivered-To: header. The trick is to use a
|
|
virtual map that uses regular expressions instead of the more
|
|
traditional indexed files.
|
|
|
|
<p>
|
|
|
|
The following delivers <i>username@virtual.domain</i> with a
|
|
Delivered-To: message header that contains <i>joe+username@your.domain</i>.
|
|
Postfix already puts the envelope sender address in the Return-Path:
|
|
header. The information in the Delivered-To: and Return-Path:
|
|
headers is sufficient to reliably implement a domain in a mailbox.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
recipient_delimiter = +
|
|
virtual_maps =
|
|
...non-regexp virtual maps...
|
|
regexp:/etc/postfix/virtual_regexp
|
|
|
|
/etc/postfix/virtual_regexp:
|
|
/^virtual\.domain$/ whatever
|
|
/^(.*)@virtual\.domain$/ joe+$1
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Notes:
|
|
|
|
<ul>
|
|
|
|
<li> Be sure to specify the <b>^</b> and <b>\</b> and <b>$</b> or
|
|
else you may have false hits.
|
|
|
|
<li> Maps with regular expressions are searched sequentially. This
|
|
can be expensive when you list many domains in regular expression
|
|
maps.
|
|
|
|
<li> Postfix has <b>regexp </b> map support only on modern UNIXes.
|
|
Instead of <b>regexp </b> maps your Postfix system may also support
|
|
<b>pcre</b> maps which have a similar syntax. To find out what maps
|
|
your system supports, use the command <b>postconf -m</b>.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="virtual_logging"><h3>Postfix logs delivery to virtual
|
|
address with the wrong name</h3></a>
|
|
|
|
When Postfix delivers mail for a virtual address <i>vuser@vdomain.name</i>
|
|
that is aliased to a local user, then Postfix logs the local username
|
|
instead of the virtual one.
|
|
|
|
<p>
|
|
|
|
Changing this requires non-trivial changes, because Postfix only
|
|
remembers the address that it delivers to, not the address that
|
|
was original specified in, for example, the SMTP MAIL FROM command.
|
|
|
|
<p>
|
|
|
|
A workaround exists. It uses regular expressions. This
|
|
can be expensive if you have many virtual domains.
|
|
|
|
<p>
|
|
<blockquote>
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
virtual_maps = regexp:/etc/postfix/virtual_regexp
|
|
recipient_delimiter = +
|
|
|
|
/etc/postfix/virtual_regexp:
|
|
/^vdomain\.name$/ whatever
|
|
/(.*)@vdomain\.name$/ localuser+$1=vdomain.name
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
This delivers the mail as
|
|
<i>localuser+vuser=vdomain.name@your.domain</i>.
|
|
|
|
<hr>
|
|
|
|
<a name="masquerade"><h3>Address masquerading with exceptions</h3></a>
|
|
|
|
For people outside your organization it can be desirable to only
|
|
see addresses of the form <i>user@company.com</i> rather than
|
|
addresses with individual internal host names. This can be achieved
|
|
with address masquerading.
|
|
|
|
<p>
|
|
|
|
Address masquerading is intended for use only on mail gateways.
|
|
|
|
<ul>
|
|
|
|
<li>In order to have all mail through the gateway host appear as
|
|
coming from <i>user@my.domain</i>, specify:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
masquerade_domains = $mydomain
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Note that the gateway should have <b><a
|
|
href="rewrite.html#append_dot_mydomain">append_dot_mydomain</a></b>
|
|
and <b><a href="rewrite.html#append_at_myorigin">append_at_myorigin</a></b>
|
|
turned on (which is the default setting) so that all addresses are
|
|
fully qualified before they are subjected to address masquerading.
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
In some cases, you may wish to have certain users or hosts exempted
|
|
from masquerading.
|
|
|
|
<ul>
|
|
|
|
<li>To exempt certain <i>users</i> from masquerading,
|
|
such as <b>root</b>, specify:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
masquerade_exceptions = root
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<li>To exempt certain <i>hosts</i> from masquerading, write
|
|
<b>masquerade_domains</b> as:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
masquerade_domains = somehost.my.domain otherhost.my.domain $mydomain
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Note that the order above is crucial: exemptions such as
|
|
<i>somehost.my.domain</i> must precede <i>$mydomain</i> in the
|
|
statement.
|
|
|
|
<p>
|
|
|
|
It should go without saying that if a particular host you wish to
|
|
exempt this way is originating mail as <i>user@my.domain</i> in
|
|
the first place, you can hardly exempt it.
|
|
|
|
<p>
|
|
|
|
</ul>
|
|
|
|
As usual, execute the command <b>postfix reload</b> to make the changes
|
|
effective.
|
|
|
|
<p>
|
|
|
|
<hr>
|
|
|
|
<a name="scanning"><h3>Support for virus scanning</h3> </a>
|
|
|
|
Would not it be great if operating systems and applications actually
|
|
worked the way they are supposed to, instead of being as fragile
|
|
as today's products? Well, we can solve only one problem at a time.
|
|
|
|
<p>
|
|
|
|
Currently, Postfix has no hooks to let other programs inspect every
|
|
message, so the scanning has to be done before mail enters Postfix
|
|
or while mail leaves Postfix, for example at mailbox delivery time.
|
|
|
|
<p>
|
|
|
|
Examples:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
mailbox_command = /some/program ...
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
This example specifies a command that delivers all local mail to
|
|
mailbox. See the sample <b>main.cf</b> file for examples. In
|
|
<b>/etc/aliases</b>, you must specify an alias for <b>root</b> that
|
|
directs mail to a real person, otherwise mail sent to <b>root</b>
|
|
will not work as expected.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
mailbox_transport = foo
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
This example delegates local mailbox delivery to the transport
|
|
<i>foo</i> as configured in <b>/etc/postfix/master.cf</b>. If you
|
|
follow this route you will build something around the pipe mailer.
|
|
See examples in <b>master.cf</b>.
|
|
|
|
<hr>
|
|
|
|
<a name="uucp-tcp"><h3>Using UUCP over TCP</h3>
|
|
|
|
This subject comes up whenever someone asks about a "domain in
|
|
a mailbox" solution. For first-hand information, see the guides
|
|
listed below.
|
|
|
|
<ul>
|
|
|
|
<li>Jim Seymour's guide for using <a
|
|
href="http://jimsun.LinxNet.com/jdp/uucp_over_tcp/index.html"> UUCP
|
|
over TCP</a>.
|
|
|
|
<p>
|
|
|
|
<li>Craig Sanders's guide for using <a
|
|
href="http://taz.net.au/postfix/uucp/"> SSL-encrypted UUCP over
|
|
tcp using stunnel</a>.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="internet-uucp"><h3>Setting up an Internet to UUCP gateway</h3> </a>
|
|
|
|
Here is how to set up a machine that sits on the Internet and that
|
|
delivers <i>some</i> but not all non-local mail via UUCP. See the
|
|
<a href="#uucp-only">UUCP-only</a> FAQ entry for setting a UUCP-only
|
|
host.
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li>You need an <b>rmail</b> program that extracts the sender
|
|
address from mail that arrives via UUCP, and that feeds the mail
|
|
into the Postfix <b>sendmail</b> command. Most UNIX systems come
|
|
with an <b>rmail</b> utility. If you're in a pinch, try the one
|
|
bundled with the Postfix source code in the <b>auxiliary</b>
|
|
directory. Some day Postfix may have its own <b>rmail</b> command.
|
|
|
|
<p>
|
|
|
|
<li>Specify that mail for, let's say, <i>some.domain</i>, should
|
|
be delivered via UUCP, for example, to a host named <i>uucp-host</i>:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/transport:
|
|
some.domain uucp:uucp-host
|
|
.some.domain uucp:uucp-host
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
See the <a href="transport.5.html">transport</a> manual page
|
|
for more details.
|
|
|
|
<p>
|
|
|
|
<li>Execute the command <b>postmap /etc/postfix/transport</b> whenever
|
|
you change the <b>transport</b> file.
|
|
|
|
<p>
|
|
|
|
<li>Enable <b>transport</b> table lookups:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
transport_maps = hash:/etc/postfix/transport
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Specify <B>dbm</b> instead of <b>hash</b> if your system uses
|
|
<b>dbm</b> files instead of <b>db</b> files. To find out what map
|
|
types Postfix supports, use the command <b>postconf -m</b>.
|
|
|
|
<p>
|
|
|
|
<li>Define a mail transport for delivery via UUCP:
|
|
|
|
<pre>
|
|
/etc/postfix/master.cf:
|
|
uucp unix - n n - - pipe
|
|
flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
This runs the <b>uux</b> command, and substitutes the next-hop
|
|
hostname (<i>uucp-host</i>) and the recipients before executing
|
|
the command. The <b>uux</b> command is executed without assistance
|
|
from the shell, so there are no problems with shell meta characters.
|
|
|
|
<p>
|
|
|
|
<li>Add <i>some.domain</i> to the list of domains that your site
|
|
is willing to relay mail for.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
relay_domains = some.domain $mydestination ...
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
See the <a href="uce.html#relay_domains">relay_domains</a>
|
|
configuration parameter description for details.
|
|
|
|
<p>
|
|
|
|
<li>Execute the command <b>postfix reload</b> to make the
|
|
changes effective.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="uucp-only"><h3>Using UUCP as the default transport</h3> </a>
|
|
|
|
Here is how to relay all your mail over a UUCP link. See the <a
|
|
href="#internet-uucp">Internet to UUCP</a> FAQ entry for setting
|
|
up a machine that gateways between UUCP and SMTP.
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li>There is no need for a <b>transport</b> table.
|
|
|
|
<p>
|
|
|
|
<li> Specify that all remote mail must be sent via the <b>uucp</b>
|
|
mail transport to your UUCP gateway host, say, <i>uucp-gateway</i>:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/main.cf:
|
|
relayhost = uucp-gateway
|
|
default_transport = uucp
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<li>Define a message transport for mail delivery via UUCP:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/master.cf:
|
|
uucp unix - n n - - pipe
|
|
flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
This runs the <b>uux</b> command, and substitutes the next-hop
|
|
hostname (<i>uucp-gateway</i>, or whatever you specified) and the
|
|
recipients before executing the command. The <b>uux</b> command
|
|
is executed without assistance from the shell, so there are no
|
|
problems with shell meta characters.
|
|
|
|
<p>
|
|
|
|
<li>Execute the command <b>postfix reload</b> to make the
|
|
changes effective.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="fax"><h3>Sending mail to a FAX machine</h3></a>
|
|
|
|
The following information is by Joerg Henne:
|
|
|
|
<p>
|
|
Over here we are using the scheme <fax number>@fax.our.domain
|
|
with Postfix and HylaFax. Here's the setup used:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
/etc/postfix/master.cf:
|
|
fax unix - n n - 1 pipe
|
|
flags= user=fax argv=/usr/bin/faxmail -d -n ${user}
|
|
|
|
/etc/postfix/transport:
|
|
fax.your.domain fax:localhost
|
|
|
|
/etc/postfix/main.cf:
|
|
transport_maps = hash:/etc/postfix/transport
|
|
fax_destination_recipient_limit = 1
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
The process limit of 1 in the <b>master.cf</b> file is necessary
|
|
with fax software that cannot handle multiple requests at the same
|
|
time. It won't hurt otherwise.
|
|
|
|
<p>
|
|
|
|
The <b>fax_destination_recipient_limit</b> entry (by Simon, Mr.
|
|
Simix) is necessary with fax software that can't have more than
|
|
one destination on its command line. It won't hurt otherwise.
|
|
|
|
<p>
|
|
|
|
Specify <B>dbm</b> instead of <b>hash</b> if your system uses
|
|
<b>dbm</b> files instead of <b>db</b> files. To find out what map
|
|
types Postfix supports, use the command <b>postconf -m</b>.
|
|
|
|
<p>
|
|
|
|
Note: be sure to not advertise <b>fax.your.domain</b> in the DNS :-)
|
|
|
|
<hr>
|
|
|
|
<a name="deleting"><h3>Deleting a message from the Postfix queue</h3></a>
|
|
|
|
As of Postfix version 20010502, the <b>postsuper</b> command
|
|
has an option to delete Postfix message queue files. To delete
|
|
the message with queue id ABCDEF, perhaps obtained from <b>mailq</b>
|
|
output, one would use:
|
|
|
|
<p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
# postsuper -d ABCDEF
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
To delete a large number of files one would use:
|
|
|
|
<p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
# postsuper -d - < <i>filename-with-queue-ids</i>
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
It is usually safe to do this while the Postfix system is running.
|
|
However, there is a small chance of deleting the wrong queue
|
|
file. The scenario goes like this:
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li>The Postfix queue manager deletes the file that <b>postsuper</b>
|
|
was supposed to delete, because Postfix was finished with the
|
|
message.
|
|
|
|
<p>
|
|
|
|
<li>New mail arrives, and the new message is given the same queue
|
|
ID as the message that <b>postsuper</b> was supposed to delete.
|
|
The probability for reusing a deleted queue ID is about 1 in
|
|
2<sup>15</sup> (the number of different microsecond values that
|
|
the system clock can distinguish).
|
|
|
|
<p>
|
|
|
|
<li><b>postsuper</b> deletes the new message file, instead of the
|
|
old file that should have been deleted.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="copying"><h3>Moving or restoring the Postfix queue</h3></a>
|
|
|
|
It is not safe to simply copy Postfix queue files from one file
|
|
system (or backup) to another file system. The reason for this is
|
|
that queue file names must be unique across the Postfix <b>incoming</b>,
|
|
<b>active</b> and <b>deferred</b> queue directories. If two queue
|
|
files have the same file (base) name, then one of the queue files
|
|
may be lost as files are moved from queue directory to queue
|
|
directory.
|
|
|
|
<p>
|
|
|
|
Postfix names a queue file after its inode number and after the
|
|
microsecond part of the time of day. Thus, if a queue file has a
|
|
name based on someone elses inode number there is a small chance
|
|
that the file name will collide with another queue file.
|
|
|
|
<p>
|
|
|
|
The text below describes two different procedures to restore
|
|
queue files from another machine or from backup.
|
|
|
|
<h4> Procedure 1: Your Postfix queue is empty, and you run Postfix
|
|
release 20010525 or later</h4>
|
|
|
|
<ul>
|
|
|
|
<li> Stop Postfix, if it was running.
|
|
|
|
<blockquote>
|
|
<pre>
|
|
# postfix stop
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
<li> Execute the <b>mailq</b> command. If there is any output, do
|
|
not complete this procedure, but use <b>procedure 2</b> instead.
|
|
|
|
<blockquote>
|
|
<pre>
|
|
# mailq
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
<li> Copy or restore the queue to the usual place.
|
|
|
|
<blockquote>
|
|
<pre>
|
|
# cd /var/spool/postfix
|
|
<i>...restore maildrop, incoming, active, deferred, defer, bounce here...</i>
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
<li> Run the <b>postsuper</b> command. This command will rename
|
|
queue files so that the file names match their message file inode
|
|
numbers.
|
|
|
|
<blockquote>
|
|
<pre>
|
|
# postsuper
|
|
</pre>
|
|
</blockquote>
|
|
|
|
</ul>
|
|
|
|
<h4> Procedure 2: Your Postfix queue is not empty, or you are
|
|
running a Postfix release prior to 20010525</h4>
|
|
|
|
<ul>
|
|
|
|
<li>Stop Postfix, if it was running.
|
|
|
|
<blockquote>
|
|
<pre>
|
|
# postfix stop
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
<li> To avoid queue file name collisions when restoring queue files,
|
|
copy or restore the incoming, active and deferred queue files under
|
|
the maildrop directory instead.
|
|
|
|
<blockquote>
|
|
<pre>
|
|
# cd /var/spool/postfix/maildrop
|
|
<i>...restore incoming, active, deferred here...</i>
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>
|
|
|
|
<li>While the next step is going on, don't submit new mail locally,
|
|
because that could collide with the files you are restoring under
|
|
the maildrop directory.
|
|
|
|
<p>
|
|
|
|
<li>As of late 2000, Postfix queues are all hashed (for example, file
|
|
ABCDEF is stored as A/B/ABCDEF), so you need an additional step to
|
|
move files down from their subdirectories.
|
|
|
|
<p>
|
|
<pre>
|
|
# find incoming active deferred -type f -exec mv '{}' . ';'
|
|
# rm -rf incoming active deferred
|
|
# postfix start
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<li>When Postfix is started, it will pick up queue files from the
|
|
maildrop directory and will give them proper queue file names.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<a name="bind"><h3>Undefined symbols: ___dn_expand, ___res_init etc.</h3></a>
|
|
|
|
Question: When I build Postfix I get the following errors:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
ld: Undefined symbol
|
|
___dn_expand
|
|
___res_init
|
|
___res_search
|
|
*** Error code 1
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Answer: you're mixing BIND version 8 include files with a
|
|
different version of the resolver library.
|
|
|
|
<p>
|
|
|
|
Fix: use the right include files. For example:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
<tt>make makefiles CCARGS="-I/usr/include"</tt>.
|
|
</pre>
|
|
|
|
<hr>
|
|
|
|
<a name="dbm_dirfno"><h3>Undefined symbols: dbm_pagfno, dbm_dirfno etc.</h3></a>
|
|
|
|
Question: When I build Postfix I get the following errors:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
Undefined first referenced
|
|
symbol in file
|
|
dbm_pagfno ../lib/libutil.a(dict_dbm.o)
|
|
dbm_dirfno ../lib/libutil.a(dict_dbm.o)
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Answer: instead of using <b>/usr/include/ndbm.h</b>, you're building
|
|
Postfix with some incompatible third-party file, typically
|
|
<b>/usr/local/include/ndbm.h</b>.
|
|
|
|
<p>
|
|
|
|
Fix: get rid of the third-party ndbm.h include file.
|
|
|
|
<hr>
|
|
|
|
<a name="db"><h3>Using third-party DB libraries</h3> </a>
|
|
|
|
The old <b>dbm</b> UNIX database has severe limitations when you
|
|
try to store lots of information. It breaks when the number of hash
|
|
collisions becomes so large that the entries no longer fit together
|
|
in a single disk block. The more modern <b>db</b> database does
|
|
not suffer these limitations. It is standard on 4.4BSD and Linux
|
|
systems.
|
|
|
|
<p>
|
|
|
|
In order to build Postfix with <b>db</b> support on UNIX systems
|
|
that do not have <b>db</b> support out of the box, you can use the
|
|
Berkeley DB source code from <a
|
|
href="http://www.sleepycat.com">www.sleepycat.com</a>. See the file
|
|
<b>DB_README</b> in the Postfix source code distribution for
|
|
instructions on how to build Postfix with Sleepycat's Berkeley DB.
|
|
|
|
<hr>
|
|
|
|
<a name="sgistruct">
|
|
|
|
<h3>IRIX problems translating IP address to string</h3>
|
|
|
|
<dl>
|
|
|
|
<dt>Question: <dd> While installing IRIX 6.5.7m on a clean disk
|
|
and no special options or software I stumbled upon the following
|
|
problem; the inet_ntoa() function seems to return INADDR_NONE
|
|
(malformed request?) for every call to it.
|
|
|
|
<p>
|
|
|
|
<dt>Answer: <dd>There is an incompatibility between gcc and system
|
|
libraries compiled with SGI's cc. See a description in <a
|
|
href="http://freeware.sgi.com/shared/howto.html">
|
|
http://freeware.sgi.com/shared/howto.html</a>.
|
|
|
|
<p>If you must use gcc, a possible workaround is to use the
|
|
inet_ntoa() routine from the BIND source code at <a
|
|
href="http://www.isc.org/"> http://www.isc.org/</a>.
|
|
|
|
</dl>
|
|
|
|
<hr>
|
|
|
|
<a name="compaq-chmod"><h3>Compaq mail blackhole problem</h3>
|
|
|
|
On some Compaq Tru64 UNIX configurations, Postfix will receive mail
|
|
and then nothing happens. The mail does not even show up with the
|
|
<b>mailq</b> command.
|
|
|
|
<p>
|
|
|
|
Postfix sets the execute bit on a queue file to indicate that it
|
|
is done receiving a message. As long as a queue file does not have
|
|
the execute bit set, Postfix will ignore it as "mail still being
|
|
received".
|
|
|
|
<p>
|
|
|
|
With enhanced security enabled, Compaq Tru64 UNIX has a feature
|
|
that disallows non-superuser attempts to set the execute bit on a
|
|
queuefile. Unfortunately, Postfix is never informed that such
|
|
attempts fail, and mail seems to disappear into a black hole.
|
|
|
|
<p>
|
|
|
|
Postfix could be modified to use some other bit than the execute
|
|
bit, but that might equally well fail on other systems. Another
|
|
possibility is to allow non-superusers to set the execute bit on
|
|
files, and to mount the Postfix queue file system with the
|
|
<b>noexec</b> option or equivalent.
|
|
|
|
<hr>
|
|
|
|
<a name="msql_limit"><h3>Too many connections</h3></a>
|
|
|
|
This message is produced by the MYQSL server. You need to increase
|
|
the number of connections that it can handle. Things to bear in
|
|
mind: the <b>virtual</b> and <b>canonical</b> maps are accessed by
|
|
every <b>smtpd</b> and <b>cleanup</b> process.
|
|
|
|
<hr>
|
|
|
|
<a name="reiser_bugs"><h3>write queue file: No such file or directory</h3></a>
|
|
|
|
<h3>write queue file: Unknown error 4294967289</h3>
|
|
|
|
Reiserfs reports the wrong error code when a message exceeds the
|
|
<b>message_size_limit</b> setting. As a result, the Postfix SMTP
|
|
server reports a "queue file write error" to the SMTP client, rather
|
|
than reporting a "file too large" condition. The client will keep
|
|
sending the same email again and again until the mail is too old.
|
|
|
|
<hr>
|
|
|
|
<a href="index.html">Up one level</a> | Postfix FAQ
|
|
|
|
</body>
|
|
|
|
</html>
|