Полезная информация

Postfix Frequently Asked Questions


Up one level | Postfix FAQ

Table of contents

Example configurations

Sendmail incompatibility

Postfix performance

Receiving mail via the network

Mail relaying

Remote delivery

Local (non-virtual) delivery

Mailing lists

Virtual domains

Address rewriting

Content filtering

Other transports: UUCP, FAX, etc.

Postfix queue maintenance

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.

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:

    /etc/postfix/main.cf:
        myorigin = $mydomain

Server:

    /etc/postfix/main.cf:
        myorigin = $mydomain
        mydestination = $myhostname, localhost.$mydomain, $mydomain

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:

    /etc/aliases:
        joe:    joe@joes.workstation
        jane:   jane@janes.workstation

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.


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.

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.

    /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

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.


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.


Running Postfix on a firewall

Note: this text applies to Postfix versions dated 19991115 and later only. To find out what Postfix version you have, execute the command postconf mail_version.

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.


Running Postfix on a dialup machine

This section applies to dialup connections that are down most of the time. For dialup connections that are up 24x7, see the workstations and servers section instead.

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.


Postfix breaks "sendmail -v"

Some people will complain that sendmail -v no longer shows the actual mail delivery.

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.


Postfix sends no "delayed mail" notices

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.


Postfix sends duplicate mail

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:

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.


Postfix sends mail to every member of a distribution list

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.

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.


Postfix ignores the owner-list alias

Normally, when a local alias foo has a companion alias owner-foo, Postfix reports delivery errors to the owner address rather than the message originator.

However, as a result of a Postfix implementation artefact, the owner-foo alias takes effect only after the alias expansion is completed.

Delivery problems that happen while expanding the alias, including delivery to commands or files, are reported to the original sender envelope address.

The reason is that bounces are sent by the Postfix queue manager, which does not know that the sender address is being replaced.

This limitation will be fixed by changing how the Postfix local delivery agent deals with undeliverable mail.


Too much mail in the incoming queue

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?

Your problem could be that the disk is saturated with I/O from receiving mail, so that the Postfix queue manager gets insufficient chance to process the requests (many SMTP server processes are competing for disk access against one poor queue manager).

You solve the problem by getting faster disks.

I am still solving the scheduling problem from the software side.

Currently, the workaround is to configure multiple IP addresses per machine, and to run one Postfix instance per IP address. The Postfix instances can't share queue directories, but sharing mailbox directories is OK.

Just start each Postfix instance with a different configuration directory:

    # postfix -c config_directory start

Each main.cf file has a different $myhostname setting, depending on the interface that it is supposed to handle.

    queue_directory = /my/own/queue/directory
    myhostname = foo1.my.domain
    inet_interfaces = $myhostname

Postfix responds slowly to incoming SMTP connections

Question:
My Postfix server is too slow. When I telnet to the SMTP port (telnet hostname 25), the response comes after 40 seconds. On the other hand, when I telnet to the the POP port (telnet hostname 110) the response comes with no delay.

Answer:
This is a DNS configuration problem. Postfix tries to resolve the SMTP client IP address to a hostname. Apparently, your POP server does not look up POP clients.

The fix is to properly configure the naming service. If you can't have every host in the DNS, then configure the mail server to look in /etc/hosts before the DNS, and specify the clients in /etc/hosts.


Postfix logs SMTP clients as IP addresses

The Postfix SMTP server logs client connections with numerical IP addresses instead of resolving the hostname. When I use nslookup the address does resolve to a name.

You run the Postfix SMTP server inside a chroot 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:

    /var/spool/postfix/etc/resolv.conf
    /var/spool/postfix/etc/services

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.

For more details, see the files in the examples/chroot-setup directory of the Postfix source code distribution.


Help! Postfix is an open relay

According to some relay checking software, Postfix accepts mail for arbitrary non-local destinations:

    >>> 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,

  1. Good but confusing: a Postfix primary MX host for some.site accepts test@some.other.site@some.site then bounces it because test@some.other.site is not a known local username.
  2. Good: a Postfix primary MX host for some.site rejects other source-routed addresses such as test%some.other.site@some.site or some.other.site!test@some.site.
  3. Loophole: a Postfix backup MX host for some.site forwards source-routed addresses such as test@some.other.site@some.site or test%some.other.site@some.site to a primary MX host for some.site. Depending on the primary MX host's mailer configuration, the primary MX host could then spam the mail into the Internet.

With newer Postfix versions,

  1. A Postfix primary MX host for some.site host rejects test@some.other.site@some.site just like it rejects test%some.other.site@some.site. This ends the confusion mentioned in 1 above.
  2. A Postfix backup MX host for some.site host rejects source-routed addresses including test@some.other.site@some.site. This closes the loophole mentioned in 3 above.

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.


Relaying mail for mobile users

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 software maintains a Postfix-compatible access table with client IP address information. In order to make this work you need Postfix version 19991231 or later.

    /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.

N.B. Some non-Postfix software such as DRAC uses btree files instead of hash files. In that case, you will have to adjust the above check_client_access restriction accordingly.

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

Restricting what users can send mail to off-site destinations

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...

        smtpd_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 smtpd_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:


Configuring Postfix as backup MX host

When you are SECONDARY MX for some other domain this is all you need:

    DNS:
        the.backed-up.domain.name        IN      MX 100 your.machine.name

    /etc/postfix/main.cf:
        relay_domains = the.backed-up.domain.name

When you are PRIMARY MX for some other domain you also need:

    /etc/postfix/main.cf:
        transport_maps = hash:/etc/postfix/transport

    /etc/postfix/transport:
        the.backed-up.domain.name       smtp:[their.mail.host.name]

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.


All remote mail stays queued with: Host not found, try again

When I connect send mail to a remote address, the following happens:

    Jul 14 12:45:38 myhostname postfix/qmgr[2246]: 74FBF30501:
	from=<sender@sender.domain> size=309 (queue active)
    Jul 14 12:45:39 myhostname postfix/smtp[2349]: 74FBF30501:
	to=<recip@recip.domain> relay=none, delay=3944, status=deferred (Name
	service error for domain recip.domain: Host not found, try again)

Check out your Postfix master.cf 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 examples subdirectory.


Mail fails consistently with timeout or lost connection

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.

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.


Postfix does not try all the MX addresses

When delivering mail, Postfix tries all MX addresses in order of preference, and stops at the first server that speaks SMTP.

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.


Root's mail is delivered to nobody

If you use
procmail (or some other command) for local mail delivery, Postfix will not deliver mail as root. Instead, Postfix runs procmail (or whatever) as nobody. Perhaps some day Wietse will trust Postfix enough to run external commands as root.

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.

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.


Postfix accepts mail for non-existing local users

See elsewhere for how to reject mail for
unknown virtual users.

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 = $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.


Delivering some users locally while sending mail as user@domain


Support for maildir-style mailboxes

Maildir is a specific one-file-per-message organization that was introduced with the qmail system by Daniel Bernstein. In order to turn on maildir-style delivery, specify, for example:

    /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.


Using Procmail for system-wide local delivery

Warning: if you use procmail in this manner, you must set up an alias for root that forwards mail for root to a real user. See the FAQ entry titled "Mail for root is delivered to nobody". 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.

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.

Getting rid of the ugly Delivered-To: header

Some people will complain about the ugly Delivered-To: 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.

Solutions, ranging from fighting symptoms to turning off the Delivered-To: header:

See also the FAQ item for problems with the majordomo approve command.


Postfix breaks the majordomo "approve" command

The Postfix local delivery agent prepends a Delivered-To: message header to prevent mail forwarding loops. With majordomo mailing lists, Delivered-To: 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.

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".


Postfix accepts MAIL FROM and RCPT TO "| command"

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.

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.

    /etc/postfix/main.cf:
        smtpd_sender_restrictions =
            regexp:/etc/postfix/envelope-regexp
            reject_unknown_sender_domain
        smtpd_recipient_restrictions =
            regexp:/etc/postfix/envelope-regexp
            permit_mynetworks
            check_relay_domains

    /etc/postfix/envelope-regexp:
        /[/|]/  REJECT

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.

See also the documentation on header checks 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.


Protecting internal email distribution lists

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.


How to configure a Postfix virtual domain

Problem:

Solution:

For more information on how to set up virtual domains, see the virtual manual page.


Commands don't work in Postfix virtual maps

Delivering mail to a command is a security-sensitive operation, because the command must be executed with the right privileges. Only root-privileged software such as the Postfix local delivery agent can set the privileges for a command.

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.

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.


Receiving a virtual domain in a mailbox

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.

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 with exceptions

For people outside your organization it can be desirable to only see addresses of the form user@company.com rather than addresses with individual internal host names. This can be achieved with address masquerading.

Address masquerading is intended for use only on mail gateways.

In some cases, you may wish to have certain users or hosts exempted from masquerading.

As usual, execute the command postfix reload to make the changes effective.


Support for virus scanning

Would not it be great if operating systems and applications actually worked the way they are supposed to, instead of being as fragile as today's products? Well, we can solve only one problem at a time.

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.


Setting up an Internet to UUCP gateway

Here is how to set up a machine that sits on the Internet and that delivers some but not all non-local mail via UUCP. See the UUCP-only FAQ entry for setting a UUCP-only host.


Using UUCP as the default transport

Here is how to relay all your mail over a UUCP link. See the Internet to UUCP FAQ entry for setting up a machine that gateways between UUCP and SMTP.


Sending mail to a FAX machine

The following information is by Joerg Henne:

Over here we are using the scheme <fax number>@fax.our.domain with Postfix and HylaFax. Here's the setup used:

    /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
	fax_destination_recipient_limit = 1

The fax_destination_recipient_limit 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.

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...


Deleting a message from the Postfix queue

To delete ONE message with queue id ABCDEF from the Postfix queue, it is not necessary to stop Postfix.

    # cd /var/spool/postfix
    # find incoming active deferred -name ABCDEF -print | sed 1q | xargs rm

The above command is safe because it deletes at most one file. There is no risk of deleting newly arrived mail that happens to get the same queue file name.

If you have to delete a large amount of mail, it is safer to stop Postfix first.

    # postfix stop
    # cd /var/spool/postfix
    # find incoming active deferred defer -type f -print |
	fgrep -xf /file/with/queue-ids | xargs rm
    # postfix start

Do not use the above command on a running Postfix system, because it can delete files that belong to new mail that arrives while you are deleting queue files.


Moving or restoring the Postfix queue

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 incoming, active and deferred 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.

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.

To avoid queue file name collisions when copying queue files, restore queue files in the maildrop directory instead.

    # postfix stop
    ... restore queue files under the maildrop directory...
    # postfix start

When Postfix is started, it will pick up queue files from the maildrop directory and will give them proper queue file names.


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

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:

    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)

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.


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.

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.

    % 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

Of course you will have to specify the actual location of the include directory and of the object library.

When building with a third-party DB library you may into one of the following problems:


IRIX problems translating IP address to string

Question:
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.

Answer:
There is an incompatibility between gcc and system libraries compiled with SGI's cc. See a description in http://freeware.sgi.com/shared/howto.html.

If you must use gcc, a possible workaround is to use the inet_ntoa() routine from the BIND source code at http://www.isc.org/.


Up one level | Postfix FAQ