Postfix Frequently Asked Questions Postfix Frequently Asked Questions
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.
Workstation:
Server:
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:
Server:
On some systems the alias database is not in /etc/aliases.
To find out the location for your system, execute the command
postconf alias_maps.
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.
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.
Example configurations
Sendmail incompatibility
Mail relaying
Remote delivery
Local (non-virtual) delivery
Mailing lists
Virtual domains
Address rewriting
Content filtering
Other transports: UUCP, FAX, etc.
Compiling and installing Postfix
Stand-alone machine
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.
Workstations and servers
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.
/etc/postfix/main.cf:
myorigin = $mydomain
/etc/postfix/main.cf:
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain, $mydomain
/etc/aliases:
joe: joe@joes.workstation
jane: jane@janes.workstation
Null clients
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.
/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
Running Postfix inside an intranet
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.
/etc/postfix/main.cf:
myorigin = $mydomain
/etc/postfix/main.cf:
relayhost = $mydomain
This assumes that your organization has set up internal MX records for the local domain.
If your intranet does not use MX records internally, you have to specify the intranet mail gateway host itself:
/etc/postfix/main.cf:
relayhost = host.my.domain
If your intranet does not use DNS internally, you have to disable DNS lookups as well:
/etc/postfix/main.cf:
disable_dns_lookups = yes
Specify routing information for the internal domain in the transport table, and enable transport table lookups.
/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
Important: do not omit the entries that deliver mail locally, or else mail will bounce with a "mail loops to myself" condition.
Specify dbm:/etc/postfix/transport if your system uses dbm files instead of db. To find out what map types Postfix supports, use the command postconf -m.
Execute the command postmap /etc/postfix/transport whenever you edit the transport table.
How to set up Postfix on the firewall machine so that it relays mail for my.domain to a gateway machine on the inside, and so that it refuses mail for *.my.domain? The problem is that the standard relay_domains mail relaying restriction allows mail to *.my.domain when you specify my.domain.
/etc/postfix/main.cf:
mydestination = $myhostname, my.domain, localhost.my.domain
relay_domains =
transport_maps = hash:/etc/postfix/transport
/etc/postfix/transport:
my.domain smtp:inside-gateway.my.domain (forwards user@domain)
.my.domain smtp:inside-gateway.my.domain (forwards user@firewall)
/etc/postfix/master.cf:
Comment out the local delivery agent
Specify dbm:/etc/postfix/transport if your system uses dbm files instead of db. To find out what map types Postfix supports, use the command postconf -m.
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 delivering some users locally while sending mail as user@domain.
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.
/etc/postfix/main.cf:
relayhost = smtprelay.someprovider.com
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.
/etc/postfix/main.cf:
defer_transports = smtp (Only for systems that use on-demand dialup IP)
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.
/etc/postfix/main.cf:
disable_dns_lookups = yes (Only for delivery across LANs that are disconnected most of the time)
When you disable DNS lookups, you must specify the relayhost 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).
Put the following command into your PPP or SLIP dialup scripts:
The exact location of the sendmail command is system-specific. With some UNIX versions, use /usr/lib/sendmail.
In order to find out if the mail queue is flushed, use something like:
#!/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
If you have disabled spontaneous SMTP mail delivery, 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.
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.
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.
When I was using Sendmail, after 4 hours, it would always send a receipt back to the sender saying mail delivery is delayed.
In order to make Postfix send "delayed mail" notifications after four hours, specify:
/etc/postfix/main.cf:
delay_warning_time = 4
With Postfix, delayed mail notices are turned off by default - people get enough mail already.
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.
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.
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.
>>> 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
Don't Panic! Upgrade to a Postfix version of 19991227 or later. To find out what Postfix version you have, execute the command postconf mail_version.
With earlier Postfix versions,
With newer Postfix versions,
To be precise, Postfix UCE restrictions refuse to forward source-routed addresses under the following conditions:
However, a Postfix primary MX host for still forwards source-routed addresses if received from a trusted client, just like it did before.
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:
/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.
This would be installed on all MX hosts.
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)
The most preferable way is to have users submit mail via some authenticated protocol instead of plain old SMTP.
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 DRAC maintains a Postfix-compatible access table with client IP address information:
/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
Specify dbm instead of hash if your system uses dbm files instead of db files. To find out what map types Postfix supports, use the command postconf -m.
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.
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.
/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
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.
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:
550 <user@remote>: Access denied
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.
The example assumes DB/DBM files, but this could also be done with LDAP or SQL.
/etc/postfix/main.cf:
smtpd_recipient_restrictions =
hash:/etc/postfix/restricted_senders
...other stuff...
restriction_classes = local_only
local_only = check_sender_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 (matches this.domain and subdomains)
that.domain OK (matches that.domain and subdomains)
Specify dbm instead of hash if your system uses dbm files instead of db files. To find out what map types Postfix supports, use the command postconf -m.
The restriction_classes verbiage exists so that Postfix can open /etc/postfix/local_domains.db before entering a chroot jail, so it is only an artefact of implementation.
This scheme does not authenticate the user, therefore it can be bypassed in several ways:
However, when you see mail deliveries fail consistently, you may have a different problem: broken path MTU discovery.
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.
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.
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.
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.
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.
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.
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 ndd command; other systems use different means such as sysctl to control kernel parameters on a running system.
Fix: find the router that drops the ICMP MUST FRAGMENT messages, and convince the person responsible for it to fix the configuration.
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.
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.
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.
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.
If such configurations are a problem for you, below are some controls that work around them.
/etc/postfix/main.cf:
smtp_skip_4xx_greeting = yes
smtp_skip_5xx_greeting = yes
The smtp_skip_5xx_greeting is present in Postfix releases later than 20000104. To find out what Postfix version you have, use the command postconf mail_version.
Execute the command postfix reload to make the change effective immediately.
Solution: just like you're not supposed to log in as root (except for unusual conditions), you're not supposed to receive mail as root.
/etc/aliases:
root: you
On some systems the alias database is not in /etc/aliases. To find out the location for your system, execute the command postconf alias_maps.
The information in this section applies to Postfix versions 19991216 and later. To find out what Postfix version you have, execute the command postconf mail_version.
By default, the Postfix SMTP server does not know what local users exist, and will happily accept mail for unknown@your.site. The reason is that different local delivery agents have different types of user databases.
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 local_recipient_maps parameter.
For example, if you use the default Postfix local delivery agent in /etc/postfix/master.cf, specify:
/etc/postfix/main.cf:
local_recipient_maps = $relocated_maps $alias_maps, unix:passwd.byname
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 /var/spool/postfix/etc). The only way to find out is to try.
By default, the Postfix SMTP server does know about Postfix virtual maps, and will reject mail for unknown@virtual.domain without further configuration.
/etc/postfix/main.cf:
myorigin = domain.name
/etc/postfix/main.cf:
virtual_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual:
root root@localhost
postmaster postmaster@localhost
Specify dbm instead of hash if your system uses dbm files instead of db files. To find out what map types Postfix supports, use the command postconf -m.
/etc/postfix/main.cf:
home_mailbox = Maildir/
Any relative pathname that ends in / turns on maildir delivery. The home_mailbox value is appended to the user's home directory pathname.
The maildir format is also supported with delivery via aliases or via .forward files. Specify /file/name/ as destination. The trailing / turns on maildir delivery.
/etc/postfix/main.cf:
mailbox_command = /path/to/procmail
/etc/postfix/main.cf:
mailbox_command = /path/to/procmail -a $EXTENSION
If you can, avoid using any shell meta characters or built-ins such as $ or " or IFS or &&, 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.
- DOMAIN
- The text to the right-hand side of the @ in the recipient address.
- EXTENSION
- Optional address extension part.
- HOME
- The recipient's home directory.
- LOCAL
- The text to the left-hand side of the @ in the recipient address, for example, $USER+$EXTENSION.
- LOGNAME
- The recipient username.
- RECIPIENT
- The entire recipient address, $LOCAL@$DOMAIN.
- SHELL
- The recipient's login shell.
- USER
- The recipient username.
Solutions, ranging from fighting symptoms to turning off the Delivered-To: header:
/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
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.
See also the FAQ item for problems with the majordomo approve command.
Currently, the recommended workaround is to edit the approve script to strip any header lines that match:
/delivered-to/i
Yes, this assumes that the moderator knows what she is doing.
A less-preferred workaround is to not insert Delivered-To: when delivering to commands such as majordomo. See the FAQ entry titled "Getting rid of the ugly Delivered-To: header".
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... :-)Postfix can implement per-address access controls. What follows is based on the SMTP client IP address, and therefore is subject to IP spoofing.
/etc/postfix/main.cf:
smtpd_recipient_restrictions =
hash:/etc/postfix/access
..the usual stuff...
/etc/postfix/access:
all permit_mynetworks,reject
Specify dbm instead of hash if your system uses dbm files instead of db files. To find out what map types Postfix supports, use the command postconf -m.
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.
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.
What follows is based on the sender SMTP envelope address, and therefore is subject to SMTP sender spoofing.
/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
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.
Getting past this scheme is relatively easy, because all one has to do is to spoof the SMTP sender address.
If the internal list is a low-volume one, perhaps it makes more sense to make it moderated.
Solution:
/etc/postfix/virtual:
virtual.domain whatever
For more information on how to set up virtual domains, see the virtual manual page.
For security reasons, Postfix tries to avoid using root 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.
Solution: specify a local alias instead. The Postfix local delivery agent has sufficient privilege to execute commands with the right privileges.
/etc/aliases:
name-virtual.domain "|/some/where/command..."
/etc/postfix/virtual:
virtual.domain whatever
name@virtual.domain name-virtual.domain
Note: on some systems the alias database is not in /etc/aliases. To find out the location for your system, execute the command postconf alias_maps.
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.
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.
The following delivers username@virtual.domain with a Delivered-To: message header that contains joe+username@your.domain. 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.
/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
Notes:
Address masquerading is intended for use only on mail gateways.
/etc/postfix/main.cf:
masquerade_domains = $mydomain
Note that the gateway should have append_dot_mydomain and append_at_myorigin turned on (which is the default setting) so that all addresses are fully qualified before they are subjected to address masquerading.
In some cases, you may wish to have certain users or hosts exempted from masquerading.
/etc/postfix/main.cf:
masquerade_exceptions = root
/etc/postfix/main.cf:
masquerade_domains = somehost.my.domain otherhost.my.domain $mydomain
Note that the order above is crucial: exemptions such as somehost.my.domain must precede $mydomain in the statement.
It should go without saying that if a particular host you wish to exempt this way is originating mail as user@my.domain in the first place, you can hardly exempt it.
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.
Examples:
/etc/postfix/main.cf:
mailbox_command = /some/program ...
This example specifies a command that delivers all local mail to mailbox. See the sample main.cf file for examples. In /etc/aliases, you must specify an alias for root that directs mail to a real person, otherwise mail sent to root will not work as expected.
/etc/postfix/main.cf:
mailbox_transport = foo
This example delegates local mailbox delivery to the transport foo as configured in /etc/postfix/master.cf. If you follow this route you will build something around the pipe mailer. See examples in master.cf.
/etc/postfix/transport:
some.domain uucp:uucp-host
.some.domain uucp:uucp-host
See the transport manual page for more details.
/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport
Specify dbm instead of hash if your system uses dbm files instead of db files. To find out what map types Postfix supports, use the command postconf -m.
/etc/postfix/master.cf:
uucp unix - n n - - pipe
flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
This runs the uux command, and substitutes the next-hop hostname (uucp-host) and the recipients before executing the command. The uux command is executed without assistance from the shell, so there are no problems with shell meta characters.
/etc/postfix/main.cf:
relay_domains = some.domain $mydestination ...
See the relay_domains configuration parameter description for details.
/etc/postfix/main.cf:
relayhost = uucp-gateway
default_transport = uucp
/etc/postfix/master.cf:
uucp unix - n n - - pipe
flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
This runs the uux command, and substitutes the next-hop hostname (uucp-gateway, or whatever you specified) and the recipients before executing the command. The uux command is executed without assistance from the shell, so there are no problems with shell meta characters.
Over here we are using the scheme
Specify dbm instead of hash if your system uses
dbm files instead of db files. To find out what map
types Postfix supports, use the command postconf -m.
Note: be sure to not advertise fax.your.domain in the DNS...
Answer: you're mixing BIND version 8 include files with a
different version of the resolver library.
Fix: use the right include files. For example:
Answer: instead of using /usr/include/ndbm.h, you're building
Postfix with some incompatible third-party file, typically
/usr/local/include/ndbm.h.
Fix: get rid of the third-party ndbm.h include file.
In order to build Postfix with db support on UNIX systems
that do not have db support out of the box, you need the
db-1.85 release, or the current
version which has a db-1.85 compatible interface.
To build with a third-party DB library, use the following commands
in the Postfix top-level directory.
On Solaris, the LD_LIBRARY_PATH unset commands may be required to
avoid linking in the wrong libraries.
Of course you will have to specify the actual location of the
include directory and of the object library.
One problem: older DB versions install a file
/usr/local/include/ndbm.h that is incompatible with
/usr/include/ndbm.h. Be sure to get rid of the bogus file.
See the FAQ entry titled "Undefined symbols:
dbm_pagfno, dbm_dirfno etc".
/etc/postfix/master.cf:
fax unix - n n - - 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
Undefined symbols: ___dn_expand, ___res_init etc.
Question: When I build Postfix I get the following errors:
ld: Undefined symbol
___dn_expand
___res_init
___res_search
*** Error code 1
make makefiles CCARGS="-I/usr/include".
Undefined symbols: dbm_pagfno, dbm_dirfno etc.
Question: When I build Postfix I get the following errors:
Undefined first referenced
symbol in file
dbm_pagfno ../lib/libutil.a(dict_dbm.o)
dbm_dirfno ../lib/libutil.a(dict_dbm.o)
Using third-party DB libraries
The old dbm 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 db database does
not suffer these limitations. It is standard on 4.4BSD and Linux
systems.
% 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
Up one level | Postfix FAQ