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