Postfix Frequently Asked Questions Postfix Frequently Asked QuestionsNote: this web page is no longer maintained. It exists only to avoid breaking links in web pages that describe earlier versions of the Postfix mail system.
Up one level | Postfix FAQ
Examples of software that is used successfully with Postfix:
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.
Workstation:
Server:
In an environment like this. either the mail spool directory is
shared via NFS, users access their mailboxes via POP, or each user
receives her mail on her own workstation. In the latter case, each
user has an alias on the server that forwards mail to the respective
workstation:
Server:
On some systems the alias database is not in /etc/aliases.
To find out the location for your system, execute the command
postconf alias_maps.
In the following example, mail is sent as user@domain, and all mail
is forwarded to the mail server that is responsible for the local
domain.
Since everything sends mail as user@domain, nothing sends mail as
user@nullclient, and therefore no special configuration needs to
be done on the mail server for mail addressed to user@nullclient.
This assumes that your organization has set up internal MX records
for the local domain.
If your intranet does not use MX records internally, you have to
specify the intranet mail gateway host itself:
If your intranet does not use DNS internally, you have to disable
DNS lookups as well:
Specify default routing information for the internal domain in the
transport table, and enable transport table lookups.
Important: do not specify a relayhost in main.cf, or else mail for
internal destinations will still be given to the relayhost.
Specify dbm instead of hash if your system uses
dbm files instead of db. To find out what map types
Postfix supports, use the command postconf -m.
Execute the command postmap /etc/postfix/transport whenever
you edit the transport table.
How to set up Postfix on the firewall machine so that it relays
mail for domain.com to a gateway machine on the inside, and
so that it refuses mail for *.domain.com? The problem is that
the default relay_domains
mail relaying restriction allows mail to *.domain.com when
you specify domain.com.
Specify explicit settings for smtpd_recipient_restrictions
and for mynetworks that allow
local systems to send mail anywhere, and that allow remote systems
to send mail only to [email protected].
Specify what recipients exist (so that your queue does not fill up
with undeliverable mail from spammers).
Specify local_recipient_maps = if maintaining recipient
information is not practical.
Specify dbm instead of hash if your system uses
dbm files instead of db. To find out what map types
Postfix supports, use the command postconf -m.
Postfix warnings and error messages
Example configurations
Sendmail incompatibility
Running hundreds of Postfix processes
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
Problems with specific Operating Systems
Problems with Compaq
Problems with IRIX
POP or IMAP problems
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.
Stand-alone machine
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.
Workstations and servers
This section describes a workstation-server environment. All systems
send mail as user@domain. All systems receive mail for user@hostname.
The server receives mail for user@domain, too.
/etc/postfix/main.cf:
myorigin = $mydomain
/etc/postfix/main.cf:
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain, $mydomain
/etc/aliases:
joe: [email protected]
jane: [email protected]
Null clients
A null client is a machine that can only send mail. It receives no
mail from the network, and it does not deliver any mail locally. A
null client typically uses POP or NFS for mailbox access.
/etc/postfix/main.cf:
myorigin = $mydomain
relayhost = $mydomain
local_transport = error:local delivery is disabled
/etc/postfix/master.cf:
Comment out the SMTP server entry
Comment out the local delivery agent entry
Running Postfix inside an intranet
The simplest way to set up Postfix on a host inside a firewalled
network is to send all your mail to an intranet mail gateway, and
to let that mail gateway take care of forwarding.
/etc/postfix/main.cf:
myorigin = $mydomain
/etc/postfix/main.cf:
relayhost = $mydomain
/etc/postfix/main.cf:
relayhost = host.my.domain
/etc/postfix/main.cf:
disable_dns_lookups = yes
/etc/postfix/transport:
my.domain :
.my.domain :
* smtp:gateway.my.domain
/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport
Running Postfix on a firewall
Note: this text applies to Postfix versions 2.0 and later. To find
out what Postfix version you have, execute the command postconf
mail_version.
/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 forwards [email protected]
/etc/postfix/master.cf:
Comment out the local delivery agent
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 [email protected], you should also study the the section on delivering some users locally while sending mail as user@domain.
If your machine is disconnected most of the time, there isn't a lot of opportunity for Postfix to deliver mail to hard-to-reach corners of the Internet. It's better to drop the mail to a machine that is connected all the time.
/etc/postfix/main.cf:
relayhost = smtprelay.someprovider.com
Normally, Postfix attempts to deliver outbound mail at its convenience. If your machine uses on-demand dialup IP, this causes your system to place a telephone call whenever you submit new mail, and whenever Postfix retries to deliver delayed mail. To prevent such telephone calls from being placed, disable spontaneous SMTP mail deliveries.
/etc/postfix/main.cf:
defer_transports = smtp (Only for systems that use on-demand dialup IP)
Some people use Postfix to deliver mail across a LAN that is disconnected most of the time. Under such conditions, mail delivery can suffer from delays while the Postfix SMTP client performs sender and recipient domain DNS lookups in order to be standards-compliant. To prevent these delays, disable all SMTP client DNS lookups.
/etc/postfix/main.cf:
disable_dns_lookups = yes (Only for delivery across LANs that are disconnected most of the time)
When you disable DNS lookups, you must specify the relayhost as either a numeric IP address, or as a hostname that resolves to one or more IP addresses (with DNS lookup disabled, Postfix does no MX lookup).
Put the following command into your PPP or SLIP dialup scripts:
The exact location of the sendmail command is system-specific. With some UNIX versions, use /usr/lib/sendmail.
In order to find out if the mail queue is flushed, use something like:
#!/bin/sh
# Start deliveries.
/usr/sbin/sendmail -q
# Allow deliveries to start.
sleep 10
# Loop until all messages have been tried at least once.
while mailq | grep '^[^ ]*\*' >/dev/null
do
sleep 10
done
If you have disabled spontaneous SMTP mail delivery, you also need to run the above command every now and then while the dialup link is up, so that newly-posted mail is flushed from the queue.
With a distributed mail system such as Postfix, this is difficult to implement. Unlike sendmail, no Postfix mail delivery process runs under control by a user. Instead, Postfix delivers mail with daemon processes that have no parent-child relationship with user processes. This eliminates a large variety of potential security exploits with environment variables, signal handlers, and with other process attributes that UNIX passes on from parent process to child process.
Postfix uses multiple processes in order to insulate subsystems from each other. Making the delivery agents talk directly to user processes would defeat a lot of the effort that went into making Postfix more secure than ordinary mailers.
When I was using Sendmail, after 4 hours, it would always send a receipt back to the sender saying mail delivery is delayed.
In order to make Postfix send "delayed mail" notifications after four hours, specify:
/etc/postfix/main.cf:
delay_warning_time = 4h
With Postfix, delayed mail notices are turned off by default - people get enough mail already.
Some people will even argue that this is the "right" behavior. It is probably more a matter of expectation and of what one is used to.
This can be "fixed" only by making Postfix slower. In the above examples, Postfix would first have to completely expand all distribution lists before starting any delivery. By design, Postfix delivers mail to different destinations in parallel, and local delivery is no exception. This is why Postfix can be faster than sendmail.
Wietse believes that Postfix implements the "right" behavior, and suspects that Sendmail's default behavior is a remnant from a dark past when Sendmail used some obscure algorithm to avoid aliasing loops.
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.
To fix the problem for Postfix execute the following command as root:
newaliases
This creates the aliases.db in the format that Postfix expects.
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.
On a properly installed system, including the file <db.h> and linking with -ldb should access files from the same Berkeley DB library version.
Unfortunately, some Linux systems have a helpful utility called linuxconf that automatically "fixes" file permissions to what they are supposed to be for Sendmail's sendmail command. Even when you reset the set-uid bit on the Postfix sendmail executable file, linuxconf will happily turn it on again for you.
On SuSE systems the file permission fixing utulity is called SuSEconfig. Other Linux systems may use different names. The usual disclaimers about mileages etc. apply.
# /etc/rc.d/init.d/linuxconf stop && rpm --erase linuxconf
and to make sure that in /etc/rc.config, PERMISSIONS_SECURITY mentions local last, EXAMPLE:/usr/sbin/sendmail root.root 755
CHECK_PERMISSIONS=set PERMISSION_SECURITY="secure local"
The envelope sender address is also the default value for the From: header address, when none is specified in the message.
To fix, specify the envelope sender address on the sendmail command line:
sendmail -f user@domain ...
To set the following kernel parameters at boot time, add the following lines to the /boot/loader.conf file (this is verified with FreeBSD 4.4):
kern.ipc.maxsockets="5000" kern.ipc.nmbclusters="65536" kern.maxproc="2048" kern.maxfiles="16384" kern.maxfilesperproc="16384"
With FreeBSD 4.2, the last three parameters cannot be set from /boot/loader.conf. To set the open file limits, execute the following commands as root:
# sysctl -w kern.maxfiles=16384 # sysctl -w kern.maxfilesperproc=16384
With FreeBSD 4.2, kern.maxproc can be set only by recompiling the kernel with a different maxusers setting in the kernel configuration file.
The following information is kernel version dependent.
To set parameters at boot time on Linux systems that have /etc/sysctl.conf, add the following lines:
fs.file-max = 16384 kernel.threads-max = 2048
To set kernel parameters at run time, execute the following commands as root:
# echo 16384 > /proc/sys/fs/file-max # echo 2048 > /proc/sys/kernel/threads-max
* set hard limit on file descriptors set rlim_fd_max = 4096 * set soft limit on file descriptors set rlim_fd_cur = 2048
% make tidy % make makefiles "CCARGS=-DFD_SETSIZE=2048" % make
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 one of several.
/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
/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
You solve the problem by getting faster disks, and/or by using different disk drives for logging, mail queue, and mailboxes.
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.
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.
/my/own/main.cf:
queue_directory = /my/own/queue/directory
myhostname = foo1.my.domain
inet_interfaces = $myhostname
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 POP port (telnet hostname 110) the response comes with no delay.
Answers:
1) You need to configure Postfix to run more SMTP server processes. Edit the smtpd entry in the master.cf file and asjust the process limit, or increase the default_process_limit setting in the main.cf file. Issue the command postfix reload to make the change effective.2) You have a name service problem.
Postfix calls the C library routines gethostbyname() and gethostbyaddr() 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.
Depending on your system, these controlling files can be named /etc/nsswitch.conf, /etc/svcorder, /etc/host.conf or otherwise. Those files specify whether the C library routines will use local /etc/hosts before or after DNS.
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 or have incorrect information. The command "postfix check" will report what files may have incorrect information. For example:
warning: /var/spool/postfix/etc/resolv.conf and /etc/resolv.conf differ warning: /var/spool/postfix/etc/localtime and /etc/localtime differ
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.
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.
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.
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.
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.
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.
/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
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 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
reject_unauth_destination
/etc/postfix/client_access:
11.22.33 OK
dialup.isp.com OK
/etc/postfix/sender_access:
[email protected] OK
[email protected] OK
How can I configure Postfix in a way that some users can send mail to the internet and other users not. The users with no access should receive a generic bounce message. Please don't discuss whether such access restrictions are necessary, it was not my decision.
Postfix has support for per-user restrictions. The restrictions are implemented by the SMTP server. Thus, users that violate the policy have their mail rejected by the SMTP server. Like this:
554 <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 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 =
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 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:
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
When you are primary mx for a remote site you also need:
/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport
/etc/postfix/transport:
the.backed-up.domain.tld relay:[their.mail.host.tld]
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.
When I send mail to a remote address, the following happens:
Jul 14 12:45:38 myhostname postfix/qmgr[2246]: 74FBF30501: from=<[email protected]> size=309 (queue active) Jul 14 12:45:39 myhostname postfix/smtp[2349]: 74FBF30501: to=<[email protected]> relay=none, delay=3944, status=deferred (Name service error for name=recip.domain type=MX: Host not found, try again)However, I can nslookup the hostname just fine.
There can be several different problems.
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.
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.
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.
When you connect to a mailer behind such a filter you see something like:
220 **************************************0******0*********20 ****200**0*********0*00
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: 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 ndd command; other systems use different means such as sysctl to control kernel parameters on a running system.
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.
Fix: find the router that drops the ICMP MUST FRAGMENT messages, and convince the person responsible for it to fix the configuration.
This will eventually be solved when Postfix implements SMTP connection caching.
Enabling chroot operation adds a non-trivial barrier for system penetrators.
Two solutions:
To find out the cause for the "unknown mail transport error", type the following command:
egrep '(warning|fatal|panic):' /var/log/maillog | lessPay particular attention to messages that are labeled as fatal and panic. These describe catastrophic failures that need to be addressed before Postfix is happy. Problems labeled as fatal are fixed by you, by adjusting configuration files, file permissions and so on. Problems labeled as panic are fixed by the Postfix author, by changing Postfix source code.
Solution: just like you're not supposed to log in as root (except for unusual conditions), you're not supposed to receive mail as root.
/etc/aliases:
root: you
On some systems the alias database is not in /etc/aliases. To find out the location for your system, execute the command postconf alias_maps.
The Postfix warning message means that new mail notification failed because the comsat network service is turned off.
To disable the comsat client code in the Postfix delivery agent, specify:
/etc/postfix/main.cf:
biff = no
Note: recent versions of procmail also produce biff notifications. To silence biff completely you may also have to update procmail configuration files.
To enable the comsat network service, uncomment the corresponding entry in the inetd.conf file, and kill -HUP the inetd process.
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.
To disable the NIS client code in the Postfix local delivery agent, update the corresponding section in the main.cf file and specify one of the following, depending on the type of aliases file:
/etc/postfix/main.cf:
alias_maps = $alias_database
This forces Postfix to use only the local aliases database, if one is defined.
The default local_recipient_maps setting assumes that you use the default Postfix local delivery agent:
/etc/postfix/main.cf:
local_recipient_maps = $alias_maps, proxy:unix:passwd.byname
You need the proxy: part only if master.cf specifies that the Postfix SMTP server runs chrooted. As distributed by the author, Postfix runs no daemons chrooted.
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.
To stop Postfix from rejecting local mail incorrectly:
To disable the local_recipient_maps feature, specify:
/etc/postfix/main.cf:
local_recipient_maps =
With this setting, the Postfix SMTP server will not reject mail for unknown local recipients.
/etc/postfix/main.cf:
myorigin = domain.tld
/etc/postfix/main.cf:
virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual:
root root@localhost
postmaster postmaster@localhost
Specify dbm instead of hash if your system uses dbm files instead of db files. To find out what map types Postfix supports, use the command postconf -m.
/etc/postfix/main.cf:
home_mailbox = Maildir/
Any relative pathname that ends in / turns on maildir delivery. The home_mailbox value is appended to the user's home directory pathname.
The maildir format is also supported with delivery via aliases or via .forward files. Specify /file/name/ as destination. The trailing / turns on maildir delivery.
/etc/postfix/main.cf:
mailbox_command = /path/to/procmail
/etc/postfix/main.cf:
mailbox_command = /path/to/procmail -a $EXTENSION
If you can, avoid using any shell meta characters or built-ins such as $ or " or IFS or &&, because they force Postfix to run an expensive shell process. However, procmail is a pig, and the gain of avoiding a shell can be unnoticeable.
- DOMAIN
- The text to the right-hand side of the @ in the recipient address.
- EXTENSION
- Optional address extension part.
- HOME
- The recipient's home directory.
- LOCAL
- The text to the left-hand side of the @ in the recipient address, for example, $USER+$EXTENSION.
- LOGNAME
- The recipient username.
- RECIPIENT
- The entire recipient address, $LOCAL@$DOMAIN.
- SENDER
- The complete sender address.
- SHELL
- The recipient's login shell.
- USER
- The recipient username.
/etc/postfix/main.cf:
local_recipient_maps = proxy:unix:passwd.byname $alias_maps ...
Solutions, ranging from fighting symptoms to turning off the Delivered-To: header:
/etc/postfix/main.cf:
smtpd_recipient_restrictions =
... regexp:/etc/postfix/access_regexp ...
smtpd_recipient_restrictions =
... pcre:/etc/postfix/access_regexp ...
/etc/postfix/access_regexp:
/^(.*)-outgoing@(.*)/ 554 Use $1@$2 instead
POSIX regular expression support (regexp) is enabled by default on modern UNIX systems. Perl-compatible regular expression support (pcre) is optional; see the PCRE_README file in the top-level Postfix source directory.
See also the FAQ item for problems with the majordomo approve command.
Currently, the recommended workaround is to edit the approve script to strip any header lines that match:
/delivered-to/i
Yes, this assumes that the moderator knows what she is doing.
A less-preferred workaround is to not insert Delivered-To: when delivering to commands such as majordomo. See the FAQ entry titled "Getting rid of the ugly Delivered-To: header".
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
reject_unauth_destination
/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.
We want to implement an internal email distribution list. Something like [email protected], 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:
[email protected] insiders_only
[email protected] 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.
If you want to deliver the domain via the Postfix virtual(8) mailbox delivery agent, then you should list the virtual domain name in the tables specified with the virtual_mailbox_domains parameter instead.
If you want to deliver the domain as a virtual(5) alias domain, where each address is aliased to a real local or remote address, then you should list the virtual domain name in the tables specified with the virtual_alias_domains parameter instead.
Quick answer: set up "punch through" virtual aliases that redirect the mail to local Postfix aliases:
/etc/postfix/main.cf:
virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual:
[email protected] listname
[email protected] owner-listname
[email protected] listname-request
/etc/aliases:
listname: "|whatever"
owner-listname: user@domain
listname-request: "|whatever"
This redirects mail for virtual address [email protected] etc. to local address [email protected] etc.. Mail for these local aliases is then delivered to external commands or files etc. by the Postfix local delivery agent.
Long answer:
Delivering mail to a file or command is a security-sensitive operation, because the operation must be executed with the right privileges. Only root-privileged software such as the Postfix local delivery agent can set the privileges for command or file delivery.
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 or to deliver to files specified in virtual maps.
Answer: Postfix logs the original recipient address in the X-Original-To: message header.
Address masquerading is intended for use only on mail gateways.
/etc/postfix/main.cf:
masquerade_domains = $mydomain
Note that the gateway should have append_dot_mydomain and append_at_myorigin turned on (which is the default setting) so that all addresses are fully qualified before they are subjected to address masquerading.
In some cases, you may wish to have certain users or hosts exempted from masquerading.
/etc/postfix/main.cf:
masquerade_exceptions = root
/etc/postfix/main.cf:
masquerade_domains = somehost.my.domain otherhost.my.domain $mydomain
Note that the order above is crucial: exemptions such as somehost.my.domain must precede $mydomain in the statement.
It should go without saying that if a particular host you wish to exempt this way is originating mail as [email protected] in the first place, you can hardly exempt it.
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.
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.
/etc/postfix/transport:
some.domain uucp:uucp-host
.some.domain uucp:uucp-host
See the transport manual page for more details.
/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport
Specify dbm instead of hash if your system uses dbm files instead of db files. To find out what map types Postfix supports, use the command postconf -m.
/etc/postfix/master.cf:
uucp unix - n n - - pipe
flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
This runs the uux command, and substitutes the next-hop hostname (uucp-host) and the recipients before executing the command. The uux command is executed without assistance from the shell, so there are no problems with shell meta characters.
/etc/postfix/main.cf:
relay_domains = some.domain $mydestination ...
See the relay_domains configuration parameter description for details.
/etc/postfix/main.cf:
relayhost = uucp-gateway
default_transport = uucp
/etc/postfix/master.cf:
uucp unix - n n - - pipe
flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
This runs the uux command, and substitutes the next-hop hostname (uucp-gateway, or whatever you specified) and the recipients before executing the command. The uux command is executed without assistance from the shell, so there are no problems with shell meta characters.
Over here we are using the scheme <fax number>@fax.our.domain with Postfix and HylaFax. Here's the setup used:
/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
The process limit of 1 in the master.cf file is necessary with fax software that cannot handle multiple requests at the same time. It won't hurt otherwise.
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 :-)
# postsuper -d ABCDEF
To delete a large number of files one would use:
# postsuper -d - < filename-with-queue-ids
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:
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.
The text below describes two different procedures to restore queue files from another machine or from backup.
# postfix stop
# mailq
# cd /var/spool/postfix ...restore maildrop, incoming, active, deferred, defer, bounce here...
# postsuper
# postfix stop
# cd /var/spool/postfix/maildrop ...restore incoming, active, deferred here...
# find incoming active deferred -type f -exec mv '{}' . ';'
# rm -rf incoming active deferred
# postfix start
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 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.
In order to build Postfix with db support on UNIX systems that do not have db support out of the box, you can use the Berkeley DB source code from www.sleepycat.com. See the file DB_README in the Postfix source code distribution for instructions on how to build Postfix with Sleepycat's Berkeley DB.
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/.
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".
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.
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 noexec option or equivalent.