2204 lines
54 KiB
HTML
2204 lines
54 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="#example_config">Example configurations</a>
|
|
|
|
<li><a href="#sendmail_incompatibility">Sendmail incompatibility</a>
|
|
|
|
<li><a href="#relaying">Mail relaying</a>
|
|
|
|
<li><a href="#remote_delivery">Delivery to remote systems</a>
|
|
|
|
<li><a href="#local_delivery">Delivery to local (non-virtual) addresses</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="#compiling_installing">Compiling and installing Postfix</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>
|
|
|
|
<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="#worm">Postfix accepts MAIL FROM/RCPT TO "|command"</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_setup">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>
|
|
|
|
</ul>
|
|
|
|
<a name="remote_delivery"><h3>Delivery to remote systems</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#timeouts">Mail fails consistently with timeout or lost connection</a>
|
|
|
|
</ul>
|
|
|
|
<a name="local_delivery"><h3>Delivery to local (non-virtual) addresses</h3>
|
|
|
|
<ul>
|
|
|
|
<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="#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>
|
|
|
|
</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>
|
|
|
|
</ul>
|
|
|
|
<a name="virtual_domains"><h3>Virtual domains</h3>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#virtual_setup">How to configure a Postfix virtual domain</a>
|
|
|
|
<li><a href="#virtual_setup">Postfix does not refuse mail for
|
|
unknown virtual users</a>
|
|
|
|
<li><a href="#virtual_setup">Mail for unknown virtual users fails
|
|
with "mail loops back to myself"</a>
|
|
|
|
<li><a href="#virtual_setup">Postfix refuses mail for virtual
|
|
domains with "user unknown"</a>
|
|
|
|
<li><a href="#virtual_setup">Postfix refuses mail for virtual
|
|
domains with "relay access denied"</a>
|
|
|
|
<li><a href="#command">Commands don't work in Postfix virtual maps</a>
|
|
|
|
<li><a href="#domain_mailbox">Receiving a virtual domain in a
|
|
mailbox</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="#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="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 DB libraries on Solaris etc.</a>
|
|
|
|
</ul>
|
|
|
|
<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 is 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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
myorigin = $mydomain
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Server:
|
|
<pre>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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>
|
|
<b>/etc/aliases</b>:
|
|
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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
myorigin = $mydomain
|
|
relayhost = $mydomain
|
|
|
|
<b>/etc/postfix/master.cf</b>:
|
|
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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
myorigin = $mydomain
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<li>Forward <i>all</i> mail to an intranet mail gateway, except
|
|
for mail for the local machine:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
relayhost = host.my.domain
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
If your intranet does not use DNS internally, you have to disable
|
|
DNS lookups as well:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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>
|
|
<b>/etc/postfix/transport</b>:
|
|
my.domain smtp:
|
|
.my.domain smtp:
|
|
thishost.my.domain local: <blink>!important!</blink>
|
|
localhost.my.domain local: <blink>!important!</blink>
|
|
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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:/etc/postfix/transport</b> if your system
|
|
uses <b>dbm</b> files instead of <b>db</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>my.domain</i> to a gateway machine on the inside, and
|
|
so that it refuses mail for <i>*.my.domain</i>? The problem is that
|
|
the standard <a href="uce.html#relay_domains">relay_domains</a>
|
|
mail relaying restriction allows mail to <i>*.my.domain</i> when
|
|
you specify <i>my.domain</i>.
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li>Specify a null <a href="uce.html#relay_domains">relay_domains</a>
|
|
parameter plus a <a href="transport.5.html">transport</a> table to
|
|
route mail for <i>my.domain</i> to the inside machine:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
mydestination = $myhostname, my.domain, localhost.my.domain
|
|
relay_domains =
|
|
transport_maps = hash:/etc/postfix/transport
|
|
|
|
<b>/etc/postfix/transport</b>:
|
|
my.domain smtp:inside-gateway.my.domain (forwards user@domain)
|
|
.my.domain smtp:inside-gateway.my.domain (forwards user@firewall)
|
|
|
|
<b>/etc/postfix/master.cf</b>:
|
|
Comment out the local delivery agent
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Specify <b>dbm:/etc/postfix/transport</b> if your system uses <b>dbm</b>
|
|
files instead of <b>db</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>
|
|
<b>/etc/postfix/main.cf:</b>
|
|
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>
|
|
<b>/etc/postfix/main.cf:</b>
|
|
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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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>
|
|
<b>/etc/postfix/main.cf</b>
|
|
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="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.
|
|
|
|
<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>:
|
|
reject when the destination is not local.
|
|
|
|
<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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
smtpd_recipient_restrictions =
|
|
regexp:/etc/postfix/regexp_access
|
|
<i>...other restrictions...</i>
|
|
|
|
<b>/etc/postfix/regexp_access</b>:
|
|
/[%!@].*[%!@]/ 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 non-Postfix software such as <a
|
|
href="http://www.mbnet.mb.ca/howto/dynamic.htm">DRAC</a> maintains
|
|
a Postfix-compatible access table with client IP address information:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
smtpd_recipient_restrictions =
|
|
permit_mynetworks
|
|
check_client_access hash:/etc/postfix/client_access
|
|
check_relay_domains
|
|
|
|
<b>/etc/postfix/client_access</b>:
|
|
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.
|
|
|
|
<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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
smtpd_recipient_restrictions =
|
|
permit_mynetworks
|
|
check_client_access hash:/etc/postfix/client_access
|
|
check_sender_access hash:/etc/postfix/sender_access
|
|
check_relay_domains
|
|
|
|
<b>/etc/postfix/client_access</b>:
|
|
11.22.33 OK
|
|
dialup.isp.com OK
|
|
|
|
<b>/etc/postfix/sender_access</b>:
|
|
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>
|
|
550 <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 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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
smtpd_recipient_restrictions =
|
|
hash:/etc/postfix/restricted_senders
|
|
...other stuff...
|
|
|
|
restriction_classes = local_only
|
|
local_only = check_recipient_access hash:/etc/postfix/local_domains, reject
|
|
|
|
<b>/etc/postfix/restricted_senders</b>:
|
|
foo@domain local_only
|
|
bar@domain local_only
|
|
|
|
<b>/etc/postfix/local_domains</b>:
|
|
this.domain OK (matches this.domain and subdomains)
|
|
that.domain OK (matches that.domain and subdomains)
|
|
</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.
|
|
|
|
<p>
|
|
|
|
The <b>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="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.
|
|
|
|
<p>
|
|
|
|
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 sendmail, every command and every response
|
|
is sent as a separate packet, because sendmail cannot implement
|
|
ESMTP command pipelining.
|
|
|
|
<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="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>
|
|
<b>/etc/aliases:</b>
|
|
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="bogus"><h3>Postfix accepts mail for non-existing local users</h3>
|
|
|
|
The information in this section applies to Postfix versions 19991216
|
|
and later. See elsewhere for <a href="#virtual_setup">unknown
|
|
virtual</a> users.
|
|
|
|
<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>
|
|
|
|
<pre>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
local_recipient_maps = $alias_maps, unix:passwd.byname
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
The above should work on UNIX systems, provided that you use the
|
|
Postfix local delivery agent. 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>).
|
|
|
|
<p>
|
|
|
|
By default, the Postfix SMTP server does know about Postfix <a
|
|
href="virtual.5.html">virtual</a> maps, and will reject mail for
|
|
<i>unknown@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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
virtual_maps = hash:/etc/postfix/virtual
|
|
|
|
<b>/etc/postfix/virtual</b>:
|
|
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.
|
|
|
|
<p>
|
|
|
|
<li>Execute the command <b>postmap /etc/postfix/virtual</b> whenever
|
|
you edit the 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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
mailbox_command = /path/to/procmail
|
|
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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>
|
|
|
|
<dl>
|
|
|
|
<dt><b>/etc/postfix/main.cf:</b>
|
|
|
|
<dl>
|
|
|
|
<dt><tt>smtpd_recipient_restrictions = ... regexp:/etc/postfix/access_regexp ...</tt>
|
|
|
|
<dt><tt>smtpd_recipient_restrictions = ... pcre:/etc/postfix/access_regexp ...</tt>
|
|
|
|
</dl>
|
|
|
|
<p>
|
|
|
|
<dt><b>/etc/postfix/access_regexp:</b>
|
|
|
|
<dl>
|
|
|
|
<dt><tt>/^(.*)-outgoing@(.*)/ 554 Use $1@$2 instead</tt>
|
|
|
|
</dl>
|
|
|
|
</dl>
|
|
|
|
<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>
|
|
|
|
<dl>
|
|
|
|
<dd><b>/delivered-to/i</b>
|
|
|
|
</dl>
|
|
|
|
<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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
smtpd_recipient_restrictions =
|
|
hash:/etc/postfix/access
|
|
..the usual stuff...
|
|
|
|
<b>/etc/postfix/access</b>:
|
|
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.
|
|
|
|
<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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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
|
|
|
|
<b>/etc/postfix/protected_destinations</b>:
|
|
all@my.domain insiders_only
|
|
all@my.hostname insiders_only
|
|
|
|
<b>/etc/postfix/insiders</b>:
|
|
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="virtual_setup"><h3>How to configure a Postfix virtual domain</h3>
|
|
|
|
Problem:
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li>Postfix does not refuse mail for unknown virtual users.
|
|
|
|
<li>Mail for unknown virtual users fails with "mail loops back to
|
|
myself".
|
|
|
|
<li>Postfix refuses mail for virtual domains with "user unknown".
|
|
|
|
<li>Postfix refuses mail for virtual domains with "relay access
|
|
denied".
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
Solution:
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li> Add a magical entry to the Postfix virtual maps for
|
|
each Postfix virtual domain:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
<b>/etc/postfix/virtual</b>:
|
|
virtual.domain whatever
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<li> Do not list Postfix virtual domains in the <a
|
|
href="basic.html#mydestination">mydestination</a> parameter.
|
|
|
|
<li> Do not list Postfix virtual maps in the <b>local_recipient_maps</b>
|
|
parameter.
|
|
|
|
<li>As of Postfix version 19991226 it is no longer necessary to
|
|
specify virtual maps in the <a
|
|
href="uce.html#relay_domains">relay_domains</a> parameter.
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
For more information on how to set up virtual domains, see the <a
|
|
href="virtual.5.html">virtual</a> manual page.
|
|
|
|
<hr>
|
|
|
|
<a name="command"><h3>Commands don't work in Postfix virtual maps</h3>
|
|
|
|
Delivering mail to a command is a security-sensitive operation,
|
|
because the command 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 a command.
|
|
|
|
<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 found in virtual maps.
|
|
|
|
<p>
|
|
|
|
Solution: specify a local alias instead. The Postfix local delivery
|
|
agent has sufficient privilege to execute commands with the right
|
|
privileges.
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
|
|
<li>Set up a local alias that executes the command:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
<b>/etc/aliases</b>:
|
|
name-virtual.domain "|/some/where/command..."
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<li>Execute the command <b>newaliases</b> whenever you edit the
|
|
alias database.
|
|
|
|
<p>
|
|
|
|
<li>Forward mail for the virtual address to the local alias:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
<b>/etc/postfix/virtual</b>:
|
|
virtual.domain whatever
|
|
name@virtual.domain name-virtual.domain
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<li>Execute the command <b>postmap /etc/postfix/virtual</b> whenever
|
|
you edit the virtual database.
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
|
|
Note: 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="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.
|
|
|
|
<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>
|
|
<b>/etc/postfix/main.cf</b>
|
|
recipient_delimiter = +
|
|
virtual_maps =
|
|
<i>...non-regexp virtual maps...</i>
|
|
regexp:/etc/postfix/virtual_regexp
|
|
|
|
<b>/etc/postfix/virtual_regexp</b>
|
|
/^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="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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
masquerade_exceptions = root
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<li>To exempt certain <i>hosts</i> from masquerading, write
|
|
<b>masquerade_domains</b> as:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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="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>
|
|
<b>/etc/postfix/transport</b>:
|
|
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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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.
|
|
|
|
<p>
|
|
|
|
<li>Define a mail transport for delivery via UUCP:
|
|
|
|
<pre>
|
|
<b>/etc/postfix/master.cf</b>:
|
|
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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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>
|
|
<b>/etc/postfix/main.cf</b>:
|
|
relayhost = uucp-gateway
|
|
default_transport = uucp
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
<li>Define a message transport for mail delivery via UUCP:
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
<b>/etc/postfix/master.cf</b>:
|
|
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>
|
|
<b>/etc/postfix/master.cf</b>:
|
|
fax unix - n n - - pipe
|
|
flags= user=fax argv=/usr/bin/faxmail -d -n ${user}
|
|
|
|
<b>/etc/postfix/transport</b>:
|
|
fax.your.domain fax:localhost
|
|
|
|
<b>/etc/postfix/main.cf</b>:
|
|
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.
|
|
|
|
<p>
|
|
|
|
Note: be sure to not advertise <b>fax.your.domain</b> in the DNS...
|
|
|
|
<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 DB libraries on Solaris etc.</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 need the
|
|
db-1.85 release, or <a href="http://www.sleepycat.com">the current
|
|
version</a> which has a db-1.85 compatible interface.
|
|
|
|
<p>
|
|
|
|
Use the following commands in the Postfix top-level directory.
|
|
The LD_LIBRARY_PATH unset commands may be required to avoid linking
|
|
in the wrong libraries.
|
|
|
|
<p>
|
|
|
|
<pre>
|
|
% LD_LIBRARY_PATH= (Bourne-shell syntax)
|
|
% unsetenv LD_LIBRARY_PATH (C-shell syntax)
|
|
% make tidy
|
|
% make makefiles CCARGS="-DHAS_DB -DPATH_DB_H='<db_185.h>' -I/some/where/include" AUXLIBS=/some/where/libdb.a
|
|
% make
|
|
</pre>
|
|
|
|
<p>
|
|
|
|
Of course you will have to specify the actual location of the
|
|
include directory and of the object library.
|
|
|
|
<p>
|
|
|
|
One problem: older DB versions install a file
|
|
<b>/usr/local/include/ndbm.h</b> that is incompatible with
|
|
<b>/usr/include/ndbm.h</b>. Be sure to get rid of the bogus file.
|
|
See the FAQ entry titled "<a href="#dbm_dirfno">Undefined symbols:
|
|
dbm_pagfno, dbm_dirfno etc</a>".
|
|
|
|
<hr>
|
|
|
|
<a href="index.html">Up one level</a> | Postfix FAQ
|
|
|
|
</body>
|
|
|
|
</html>
|