Postfix Master (Documentation)

The Postfix Home Page
The Postfix Home Page

All programmers are optimists -- Frederick P.
Brooks, Jr.
QUICK LINKS First of all, thank you for your interest in the Postfix project.
Home
Non-English Info What is Postfix? It is Wietse Venema's mailer that started life as
Web sites (text) an alternative to the widely-used Sendmail program.
Download (source)
Mailing lists Postfix attempts to be fast, easy to administer, and secure, while
Press and Interviews at the same time being sendmail compatible enough to not upset
Documentation existing users. Thus, the outside has a sendmail-ish flavor, but the
Howtos and FAQs inside is completely different.
Add-on Software
Packages and Ports
Becoming a mirror site
Search
http://www.subneural.net/postfix-master/01/16/2005 15:45:43
Non-English Postfix Information
Non-English Postfix
Information
To have information listed on this page, please send mail to
QUICK LINKS wietse@porcupine.org.
Home
brazilian | chinese | french | german | indonesian |
Non-English Info
Web sites (text) italian | japanese | korean | russian | spanish |
Download (source) turkish |
Mailing lists
Press and Interviews Brazilian
Documentation
Howtos and FAQs ● Brazilian Postfix mailing list.
Add-on Software ● Postfix+Clamav howto by
Packages and Ports
Gleydson Soares.
Becoming a mirror site ● Manual do Postfix (Postfix
configuration guide).
Search
● Postfix+PostgreSQL virtual
domain howto by Leandro
Mendes.
● Postfix howtos and
documentation by Deives
Michellis.
● Postfix, Sasl2, Courier-Imap,
Quota and PostgreSQL howto by
William da Rocha.
● Postfix mail relaying with SASL
authentication howto by William
da Rocha.
Chinese
● Postfix China home page.
http://www.subneural.net/postfix-master/non-english.html (1 of 4)01/16/2005 15:45:45

French
● Postfix documentation by Xavier

Guimard.
● SASL+LDAP howto for
FreeBSD by Bruno Bonfils.
● Postfix+MySQL+Courier-IMAP
+SpamAssassin howto by
Alexandre.
German
● Postfix UCE howto by Istvan

Sebestyen.
● SMTP AUTH und Client
Zertifikat basiertes relayen by
Patrick Ben Koetter.
● de.comm.software.mailserver
newsgroup.
● Postfixbuch mailing list, for the
book by Peer Heinlein.
Indonesian
● Postfix Indonesia user group,

mailing list, documentation and
more.
● Alternate Postfix Indonesia site.

Italian
● Un pinguino per postino (Italian

Postfix howto) by Tommaso DI
Donato.
● Postfix virtual domains, vm-
pop3d, amavisd, spamassassin
and openwebmail howto by
Manuel (RTF format).
● Postfix+MySQL+Mac OS howto
by Davide Cantaluppi.
● Postfix antispam/antivirus howto
by Davide Cantaluppi.
● Postfix+LDAP+Courier-IMAP
+JAMM howto by Mirko Grava.
Japanese
● Documentation, mailing list and

user group.
● VineLinux (Japanese localised)
packages by Keitaro Yoshimura.
Korean
● Korea Postfix user group.

Spanish
● RPM's, mailing lists, and other

resources by Simon J. Mudd.
● Notas para configurar Postfix by
Guillermo Ballester Valor.
● FreeBSD+Postfix, by Andrés
Gallo.
● Postfix+TLS/SSL+amavis (using
clamav and spamassasin) howto
by Fernando Jose Pereda
Garcimartin.
Russian
● Postfix howto document by

Beshkov Andrewa.
Turkish
● Postfix, MySQL, SASL howto by

Umut Besler.
● Postfix, anti-virus/spam howto by
Deniz Akkus Kanca.

Please choose a Postfix Web Site
Please choose a Postfix Web

Site
Mirror status report
QUICK LINKS
Europe: Slovak Republic, Central
Home Kosice America:
Non-English Info Austria, Vienna Slovenia, Ljubljana
Web sites (text) Belgium, Brussels Costa Rica
Spain, Madrid
Download (source)
Czech Republic, Sweden, Stockholm
Mailing lists
Prague Sweden, Uppsala South America:
Press and Interviews
Denmark, Switzerland, Basel
Documentation
Copenhagen Switzerland, Argentina,
Howtos and FAQs
Denmark, Krusaa Solothurn Pergamino
Add-on Software
Estonia, Tallinn Switzerland, Zurich Argentina,
Packages and Ports
Becoming a mirror site Estonia, somewhere UK, Cambridge Buenos Aires
France, Angers UK, London Brazil, Sao Paulo
Search France, Chatenois UK, London
France, Paris Middle East/
France, Poitiers Africa:
North America:
France, Saint-Denis
East Asia/
Germany, Hamburg Canada, Alberta,
Pacific:
Germany, Frankfurt Edmonton
am Main Canada, BC,
Australia, Sydney
Germany, Frankfurt Vancouver
China, Beijing
am Main Canada, ON,
China, Nanjing
Germany, Frankfurt Gloucester
China, Shanghai
am Main USA, CA, Bay area
Indonesia,
Germany, Munich USA, CA, Bay area
Bandung
Hungary, Budaors USA, IL, Chicago
Indonesia, Jakarta
Greece, Athens USA, IL, Chicago
Indonesia, Jakarta
Italy, Milan USA, MN, Brainerd
Malaysia, Kuala
Italy, Savona USA, MO
Lumpur
Lithuania, Vilnius USA, NH, New
South Korea,
Netherlands, Durham
Seoul
Amsterdam USA, NJ, Newark
South Korea,
Netherlands, USA, NY, White
Seoul
http://www.subneural.net/postfix-master/web-sites.html (1 of 2)01/16/2005 15:45:46

Please choose a Postfix Web Site
Amsterdam Plains Japan, Tokyo

Netherlands, USA, PA, Japan, Tokyo
Amsterdam Philadelphia Taiwan, NCTU
Netherlands, USA, PA, Pittsburgh Taiwan, NSYSU
Amsterdam USA, PA, Pittsburgh CDPA
Netherlands, USA, TX, Corpus Taiwan,
Apeldoorn Christi Providence
Netherlands, USA, UT, Salt Lake
Apeldoorn City
Netherlands, USA, WA, Monroe
Hoofddorp
Netherlands, Utrecht Wietse's own site
Netherlands, Arnhem
Norway, Oslo
Poland, Poznan
Poland, Warsaw
Romania, Bucharest
Russia, Novosibirsk
http://www.subneural.net/postfix-master/web-sites.html (2 of 2)01/16/2005 15:45:46

Please choose a Postfix Download Site
Please choose a Postfix

Download Site
Mirror status report
QUICK LINKS
Europe Russia, Novosibirsk Central America
Home Russia, Saint
Non-English Info Austria, Vienna Costa Rica
Peterburg
Web sites (text) Belgium, Brussels Slovak Republic,
Download (source)
Czech republic, Kosice South America
Mailing lists
Prague Slovenia, Ljubljana
Denmark, Spain, Madrid Argentina,
Documentation
Copenhagen Sweden, Stockholm Pergamino
Howtos and FAQs
Add-on Software Estonia, Tallinn Sweden, Uppsala Argentina,
Packages and Ports Estonia, somewhere Sweden, Uppsala Buenos Aires
Becoming a mirror site France, Angers Switzerland, Basel Brazil, Brasilia
France, Paris Switzerland, Brazil, Curitiba
Search France, Paris Solothurn Brazil, Sao Paulo
France, Paris Switzerland, Zurich
France, Poitiers Turkey, Ankara Africa
France, Saint-Denis UK, Cambridge
Germany, Berlin UK, London South Africa
Germany, Bonn UK, London
Germany, Frankfurt UK, London Middle East
am Main
Germany, Frankfurt North America Israel, Tel Aviv
am Main
Germany, Frankfurt Canada, Alberta, East Asia/Pacific
am Main Edmonton
Germany, Goettingen Canada, BC, Australia,
Germany, Hamburg Vancouver AARNet
Germany, Hamburg Canada, Ontario, China, Beijing
Germany, Munich Toronto China, Hong
Greece, Athens Canada, Ontario, Kong
Hungary, Budapest Toronto China, Nanjing
Hungary, Budaors USA, OR China, Shanghai
Ireland, Dublin USA, CA, Bay area Indonesia, Jakarta
http://www.subneural.net/postfix-master/download.html (1 of 2)01/16/2005 15:45:46

Please choose a Postfix Download Site
Latvia, Riga USA, CA, Bay area Indonesia, Jakarta

Lithuania, Vilnius USA, CA, Mountain Japan, Ibaraki
Netherlands, View Japan, Saitama
Amsterdam USA, CA, San Jose Japan, Tokyo
Netherlands, USA, CA, San Japan, Tokyo
Amsterdam Francisco (IPv4/6) Malaysia, Kuala
Netherlands, USA, CT, Bethel Lumpur
Amsterdam USA, FL, Miami South Korea,
Netherlands, USA, IL, Chicago Seoul
Amsterdam USA, IL, Chicago South Korea,
Netherlands, USA, IN, Seoul
Apeldoorn Indianapolis Taiwan, Hsinchu
Netherlands, USA, MN, Brainerd Taiwan, NSYSU
Apeldoorn USA, MO CDPA
Netherlands, USA, NJ, Newark Taiwan,
Hoofddorp USA, NY, New York Providence
Netherlands, USA, NY, White
Hoofddorp Plains
Netherlands, Utrecht USA, OH, Columbus
Netherlands, Arnhem USA, PA,
Norway, Oslo Philadelphia
Poland, Poznan USA, PA, Pittsburgh
Portugal, Porto USA, PA, Pittsburgh
Romania, Brasov USA, VA, Merrifield
Romania, Bucharest USA, UT, Salt Lake
City
USA, WA, Monroe
Wietse's own site
http://www.subneural.net/postfix-master/download.html (2 of 2)01/16/2005 15:45:46

Postfix Mailing Lists

wietse@porcupine.org.
QUICK LINKS on-line archives | mailing list subscription | non-english

Home lists
Non-English Info
Web sites (text) On-line postfix-users@postfix.org mailing list archives
Download (source)
Mailing lists ● http://archives.neohapsis.com/archives/postfix/
Press and Interviews ● http://news.gmane.org/index.php?prefix=gmane.mail.
Documentation postfix
Howtos and FAQs ● http://groups.yahoo.com/group/postfix-users/
Add-on Software ● http://groups.google.com/groups?group=mailing.postfix.
Packages and Ports
users
● http://marc.theaimsgroup.com/?l=postfix-users
Search
Subscriptions to postfix-users@postfix.org and related
mailing lists
● Send mail to majordomo@postfix.org with content (not

subject):
[un]subscribe postfix-announce [ you@domain.tld ]
[un]subscribe postfix-users [ you@domain.tld ]
[un]subscribe postfix-users-digest [ you@domain.tld ]
[un]subscribe postfix-devel [ you@domain.tld ]
Note: you do not need to specify the [ and ] or the text

between them.
● postfix-announce@postfix.org: READ-ONLY list for

announcements of Postfix releases and updates.
Open subscription, no posting.
● postfix-users@postfix.org: General discussions about the

use of and experiences with the Postfix mail system.
http://www.subneural.net/postfix-master/lists.html (1 of 2)01/16/2005 15:45:47

Open subscription, unmoderated posting by members

only.
● postfix-users-digest@postfix.org: daily mailing of articles

that were sent out via the postfix-users mailing list.
Open subscription, no posting.
● postfix-devel@postfix.org: for people who design,

implement or maintain Postfix source code. NOT for
questions, problem reports and feature requests;
tresspassers will be removed from the mailing list.
Open subscription, unmoderated posting by members

only.
Non-English
● Brazilian: http://listas.softwarelivre.org/mailman/listinfo/
postfix-br/.
● German: Postfixbuch mailing list, for the book by Peer

Heinlein.
● Indonesian: http://www.postfix.or.id/lists.html.
● Japanese: http://www.postfix-jp.info/ML/.
● Spanish: http://postfix.WL0.org/es/listas/.
http://www.subneural.net/postfix-master/lists.html (2 of 2)01/16/2005 15:45:47

Postfix in the Press

Recent documents.
● Duane Dunston: "Catching up with Wietse Venema,

QUICK LINKS creator of Postfix and TCP Wrapper". Linuxsecurity.com,
Home July 2004. http://www.linuxsecurity.com/feature_stories/
Non-English Info feature_story-169.html (backup copy )
Web sites (text)
Download (source) ● Ludovic Marcotte, "HEC Montréal: Deployment of a
Mailing lists Large-Scale Mail In stallation". Linux Journal, May 2004.
Press and Interviews http://www.linuxjournal.com/article.php?sid=7323
Documentation ( backup copy ), and a follow-up article with statistics of
Howtos and FAQs blocked mail: http://www.linuxjournal.com/article.php?
Add-on Software sid=7524 (backup copy )
Packages and Ports
Older documents.
Search
● John Markoff: "Sharing Software, IBM to Release Mail
Program Blueprint". New York Times, December 1998.
http://www.nytimes.com/library/tech/98/12/biztech/
articles/14blue.html (backup copy)
This is the New York Times article that put Open Source
on the radar of IBM CEO Lou Gerstner. He called around,
found that IBM had no open source strategy, and tasked
people to come up with one. And the rest is history.
● Elinor Abreu: "Behind the Big Blue Wall". The Industry

Standard, January 22-29, 2001, page 62. http://www.
thestandard.com/article/display/0,1151,21395-0,00.html
(backup copy)
How the release of Postfix (Secure Mailer) helped IBM to

develop its open source strategy.
● Andrew Leonard: "How Big Blue fell for Linux". Salon

Technology, September 2000. http://salon.com/tech/
fsp/2000/09/12/chapter_7_part_one/index.html (backup
http://www.subneural.net/postfix-master/press.html (1 of 3)01/16/2005 15:45:47

copy)
This is the first article that recognizes Postfix (Secure

Mailer) as the project that accelerated IBM's Open Source
strategy. Unfortunately, the text contains factual errors. In
particular, Postfix development started after I came to
IBM, not before.
● Cameron Laird and Kathryn Soraiz: "Postfix and Mailman

deliver enhanced e-mail security and performance".
SunWorld, March 1999. http://www.sunworld.com/swol-
03-1999/swol-03-mailtools.html (backup copy)
● Kurt Seifried: "Postfix - the Sendmail replacement". Kurt's

Closet, September 1999. http://www.securityportal.com/
closet/closet19990915.html (backup copy)
● Kurt Seifried: "Postfix - The Sendmail Replacement, Part

II". Kurt's Closet, November 2000. http://securityportal.
com/closet/closet20001122.html (backup copy)
● Cameron Laird: "Venema aims to make network software

safe". Developer.com Journal, October 1998. http://
developer.earthweb.com/journal/profiles/100298_venema.
html (backup copy)
● Mark Durham: "Q&A: Wietse Venema". Sendmail.net,

April 2000. http://sendmail.net/interviews/
interviewvenema.shtml (backup copy)
● Gregor Longariva: "Postfix - der Sendmail-Ersatz?

Modular und sicher". LINUX Magazin, May 2000. http://
www.linux-magazin.de/ausgabe/2000/06/Postfix/postfix.
html (backup copy)
● Mick Bauer and Brenno de Winter: "Using Postfix for

Secure SMTP Gateways". Linux Journal, October 2000.
http://www.linuxjournal.com/lj-issues/issue78/4241.html
(backup copy)

● Kyle Dent: "IBM's Secure Mailer". SysAdmin magazine,

January 2000. http://www.samag.com/documents/s=1171/
sam9912a/9912a.htm (backup copy)

Postfix Documentation
General configuration SMTP Relay/access Specific environments
control
QUICK LINKS ● Basic ● Linux issues
configuration ● Relay/access ● NFS issues
Home
● Standard control ● Ultrix support
Non-English Info
Web sites (text) configuration overview
examples ● Access policy Other mail delivery
Download (source)
Mailing lists ● Address delegation agents
Press and Interviews rewriting ● Address
verification ● Cyrus (*)

Documentation ● Virtual domain
● Maildrop
Howtos and FAQs hosting ● Per-client/user/
Add-on Software ● LMTP (*)

● SASL etc. access
Packages and Ports Authentication ● ETRN
Becoming a mirror site Support Other topics

● IP Version 6
Support ● LAN
Search ● Architecture
● TLS Encryption connected via
overview
and UUCP
● All main.cf
authentication
parameters
● Installation from Lookup tables
● All Postfix
source code (databases)
manual pages
● Rejecting
● Lookup table
Problem solving
overview Unknown Local
● CDB Howto
Recipients
● Bottleneck
● Address Classes
● Berkeley DB
analysis
● Guidelines for
● Performance Howto
● LDAP Howto
Package
tuning
● MySQL
Builders
● Debugging
● Queue
strategies Howto
● PCRE Howto
Scheduler
● Error messages
● XCLIENT
(*) ● PostgreSQL
Howto Command
● XFORWARD
Content inspection
Mailing list support Command
● Content
inspection ● qmail/ezmlm
overview support (*)
● Stopping ● VERP
Support
http://www.subneural.net/postfix-master/documentation.html (1 of 2)01/16/2005 15:45:47

backscatter mail
● Built-in content
inspection
● After-queue
content filter
● Before-queue
content Filter
(*) These documents will be made available via http://www.postfix.org/ and

mirror sites.
http://www.subneural.net/postfix-master/documentation.html (2 of 2)01/16/2005 15:45:47

Postfix Howtos and FAQs

wietse@porcupine.org. The information listed here is maintained
by the respective authors. It is listed without formal evaluation, in
QUICK LINKS other words, no implied warranty of any kind.
Home
Non-English Info FAQs
Web sites (text)
Download (source) ● Kyle Dent's Postfix resources.
Mailing lists ● Ralf Hildebrandt's Postfix shrine.
Documentation Training
Howtos and FAQs
Add-on Software ● Guru Labs class GL275 covers Postfix, email theory,
Packages and Ports DNS, SMTP Auth, STARTTLS, SpamAssassin, POP3/
Becoming a mirror site IMAP4 daemons, and Webmail with Squirrelmail.
Search MS Exchange Integration
The following documents describe how to build the list of valid

Exchange recipients for a Postfix 2.x "front end" MTA, so that
you don't clog the Postfix mail queue with undeliverable
MAILER-DAEMON messages.
● Running commands on the Exchange server and then

copying the result to the Postfix box (by Steve Friedl).
● Running a PERL-based LDAP client on the Postfix box
that queries the Active Directory domain controllers (by
Chris Covington).
TLS
● Postfix SASL Authentication and TLS howto by Patrick

Koetter.
● Supplement to Patrick Koetter's document by Adam
Shostack.
● Postfix SASL + TLS + OpenBSD howto by Jeffrey
Posluns.
http://www.subneural.net/postfix-master/docs.html (1 of 4)01/16/2005 15:45:48

● Postfix SASL + TLS + FreeBSD howto by Tim Yocum.
SASL
● Postfix SASL Authentication and TLS howto by Patrick

Koetter.
● Postfix SASL + TLS + OpenBSD howto by Jeffrey
Posluns.
● Postfix SASL + TLS + FreeBSD howto by Tim Yocum.
● Postfix SMTP Authentication howto by Devin L. Ganger.
● Postfix + SASL howto, useful for Mandrake and other
systems.
● Cyrus+SASL howto by Haim R. Dimermanas.
● Postfix+SASL+OpenSSL howto for Solaris 8 by Andy
Barclay.
Adding disclaimers
● Altermime system to alter mime-encoded messages. With

Postfix, use this as an external content filter in order to
mutilate transit mail.
UCE/Virus
● Postfix Anti-UCE Cheat-Sheet by Jim Seymour.

● My Understanding Of How UCE Actually Works by
Meng Wong.
● Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-
new, SpamAssassin, Razor and DCC by Scott Vintinner.
● Postfix UCE/anti-spam guide by Jeffrey Posluns.
● UCE and other howtos by Ralf Hildebrandt.
● Header/body junk mail patterns by Jesus Climent.
● See also the add-on software page for SpamAssassin etc.
POP/IMAP and the kitchen sink
● MAC OS X howto for using Postfix with the (ugh) UW

IMAP server.
● GNU pop3d howto by Jørgen Thomsen.

● RedHat 7.1 + Postfix + Courier Maildrop + Courier IMAP

howto by Robin Whittle.
● Cyrus+SASL howto by Haim R. Dimermanas.
● Postfix+Cyrus+Web-cyradm howto by Luc de Louw.
● Postfix+LDAP+Courier-IMAP howto by Jeroen
Vriesman.
● Postfix+MySQL+Courier-IMAP howto by Mischa Peters.
● Postfix+MySQL+Courier-IMAP howto by Kirby Menzel
and Lucas Peet.
● Postfix+MySQL+Courier-IMAP howto by Keith
Matthews and contributors.
● Postfix+MySQL+Courier-IMAP+Maildrop
+SpamAssassin howto by Serge Stepanov.
● Postfix+MySQL+Courier-IMAP+Amavis howto by
Christoph Haas.
● Postfix+MySQL+Courier-IMAP+Amavis howto by
Martin List-Petersen.
● Postfix+MySQL+Courier+Pop-before-SMTP+Amavisd-
new+SpamAssassin+ClamAV howto for GNU/Linux by
Ivar Abrahamsen
● Postfix+MySQL+Courier+SpamAssassin+Clamav
+Amavisd-new+SASL+Maildrop+Squirrelmail howto by
Genco YILMAZ. Uses the postfixmanager user
management tool.
Miscellaneous
● Multiple Postfix instances howto by Derrick Webber.

● RedHat 7.3 laptop howto by Mark Frazer.
● Postfix Howtos by Ralf Hildebrandt.
● Postfix Howtos by Matthias Andree.
● Virtual+mysql howto by Daniel V. Pedersen.
General Email/System Administration
● Fixing common DNS problems (bind8nt.meiway.com)

● Simplifying Mailer Daemons and Associated Tools by
Chuck S. Mead, Jr.
● Configuring large-scale UNIX/Linux servers (www.kegel.

com)
● HA mail system tutorial by Damir Horvat.

Postfix Add-on Software

Home
Non-English Info starttls + ipv6 | PGP/SMIME gateways | policy servers/
Web sites (text) libraries | open proxy/relay detection | before smtp auth
Download (source) | certified email | configuration/user mgt | virus/spam
Mailing lists content filters | fax<->mail | list managers | logfile
Press and Interviews analysis | lookup tables | pop/imap | webmail | package
Documentation mgt | autoreply | quota | miniature clients | other
Howtos and FAQs
Add-on Software This page lists tools, add-ons and howtos by subject. Just to be
Packages and Ports clear on what I am talking about, here is a brief definition of the
Becoming a mirror site terminology that is used below:
Search ● Utility, system - requires no change to Postfix source

code.
● Patch - requires making changes to Postfix source code.
● Howto - examples of using add-on software with Postfix.
STARTTLS and IPv6
STARTTLS and IPv6 support is being integrated as part of the

Postfix 2.2 development cycle.
● TLS patch by Lutz Jaenicke.

● TLS web page mirror.
● TLS download mirror.
● IPV6 and IPV6+TLS patch Dean Strik.
● IPV6 patch by Jun-ichiro itojun Hagino of the KAME
project.
PGP/SMIME Gateways
● Z1 SecureMail Gateway Security server for email using S/

MIME and PGP.
http://www.subneural.net/postfix-master/addon.html (1 of 8)01/16/2005 15:45:49

Policy servers/libraries
● gld greylist server with MySQL database by Salim Gasmi.

● gps greylist policy server in C++ using MySql, Postgres,
or SQLite by Michael Moritz.
● smtpd-policy-template skeleton policy server in Perl by
Michael Tokarev.
● Postgrey greylist policy server in Perl by David
Schweikert.
● policyd policy server in C which provides greylisting,
sender throttling (on mail messages/size per hour) and
spamtraps by Cami.
● libspf library and patch.
● libspf2 patch by Dean Strik.
Note: Postfix already ships with SPF support, in the form of a

plug-in policy daemon. This is the preferred integration model, at
least until SPF is mandated by standards.
Open relay/proxy detection
● grinch utility by Daniel Mack. On request by Postfix, it

finds out if a host is an open mail relay and caches the
result.
● proxycheck open proxy detection utility by Michael
Tokarev. Some additional scripting is required to integrate
with Postfix.
Before SMTP authentication
● pop-before-smtp utility by Bennett Todd.

● whoson patch by Laurent Wacrenier.
● pop-before-smtp howto by Ralf Hildebrandt.
● DRAC howto by Ralf Hildebrandt.
Certified email
● OpenPec Certified email system by Ksolutions S.p.A.

(Italian site).
Configuration/user management
● Postfix enabler utility for Mac OS X. Sets up SMTP,

POP3, IMAP, SSL support, SASL (client or server).
● Web-cyradm.org Web Based Management tool for
Postfix, Cyrus IMAP, and MySQL or PostgreSQL by Luc
de Louw.
● Postfix Admin a Web Based Management tool for Virtual
Domains and Virtual Users that are stored in MySQL.
● webmin system has a Postfix configuration module.
● webmin system documentation.
● tequila ( backup link) system for Postfix configuration
management, including mail forwarding and autoreply.
● postfixmanager user management tool for Postfix by
Genco YILMAZ.
● BASH script for automatic completion of postconf
commands by Carsten Hoeger.
● SUSE Openexchange Server.

● Trustix Mail Server.
● POSTCONF Mail Server.
Virus/SPAM content filters
● Xamime email content management system.

● Postfix+Amavis+ClamAV+Spamassassin howto by
Tobias Rice.
● renattach rename or delete attachments by file name or file
type, by Jem Berkes. Beware: prior to version 1.2.2 the "-
p" or "--pipe" command-line option is not safe and may
result in munged addresses.
● spampd spam filtering, transparent SMTP/LMTP proxy
using SpamAssassin, in Perl by Maxim Paperno.
● amavisd-new utility, a high-performance interface
between MTA and virus/SPAM scanners.
● Anti-spam gateway howto using OpenBSD, Postfix,
amavisd-new, SpamAssassin, Razor and DCC.

● SpamAssassin mail labeling system.

● per-user SpamAssassin filtering by Mikko Pikarinen.
● amavisd-new/Razor/SpamAssassin setup tutorial by Scott
Henderson.
● amavis system, works with Postfix and other MTAs.
● mailscanner system, works with Postfix and other MTAs.
This uses unsupported methods to manipulate Postfix
queue files, and there are multiple reports of message
duplication and/or delivery of truncated messages.
● avcheck utility by Michael Tokarev. Interfaces to several
virus scanning engines.
● sophie system, works with Postfix and other MTAs.
● maildrop howto by Matthias Andree. The maildrop
delivery agent is part of the Courier mail server software.
● anomy email sanitizer system.
● anomy howto by Derrick Webber.
● avpcheck howto by Ralf Hildebrandt.
● smtpprox generic SMTP filtering proxy by Bennett Todd.
● Vexira MailArmor virus scanner, works with Postfix on
Linux, FreeBSD and OpenBSD.
● procmail howto for sanitizing email by John D. Hardin.
● crm114 mail content inspection system.
● crm114 Postfix howto by Eugene Borukhovich.
● Tagged Message Delivery Agent (TMDA) by Jason R.
Mastaler, a system that requires unknown senders to send
confirmation before they are put on a whitelist.
● html-trap utility by Samuel Seay for procmail-based
content filtering.
● Postfix Anti-UCE Cheat-Sheet by Jim Seymour.

● UCE and other howtos by Ralf Hildebrandt.
● ORDB (open relay database) configuration tips.
● Per-user UCE controls patch by Jozsef Kadlecsik.
● RBL+ howto by Furio Ercolessi; uses Jozsef Kadlecsik's
patch.
● RBL analysis tools by Craig Sanders.
● concierge utility by Rich Graves. Analyses Postfix logs
and sends mail to users whose mail was rejected by
Postfix content filtering.

Fax<->Email software
● FaxmimumFax Messaging Server (FMS) integrates with

Postfix and other MTAs and provides email-to-fax and fax-
to-email gateways.
List managers
● Ecartis mailing list manager system (formerly: Listar).

● Listar howto by Craig Sanders.
● Mailman howto by Dax Kelson.
● Mailman, the GNU Mailing List Management System.
● majordomo howto by Jon Parise.
● SmartList Mailing List Management System howto.
Logfile analysis
● pflogsumm logfile analyzer utility by Jim Seymour.

● AWStats logfile analyzer system.
● Anteater logfile analysis system by Tobias Erbsland.
● mailgraph, an RRDtool frontend utility by David
Schweikert.
● mailstats logfile analyzer utility by Craig Sanders.
● LogReport logfile analyzer system. On-line log report
processing is available at log@postfix.logreport.org.
● Logrep logfile analyzer system.
● Isoqlog logfile analyzer system (also supports qmail and
Sendmail).
Lookup tables
● pam lookup table by Andrew I Baznikin; for example, use

this to implement local_recipient_maps with RADIUS.
● cidr2abc utility by Gjermund Sorseth to convert arbitary
net/mask patterns into octet based patterns such as used in
Postfix access maps.
● NIS+ patch by Geoff Gibbs.
● cdb patch by Michael Tokarev.

● tinycdb Michael Tokarev's own CDB implementation.

● Mysql howto by Daniel V. Pedersen. Uses the Postfix
virtual(8) delivery agent.
POP/IMAP servers
For howto documents, see Howtos and FAQs.
● perdition system is a smart POP/IMAP proxy that

connects users to the "right" POP/IMAP server.
● Cyrus IMAP system implements IMAP, POP3, and
KPOP, later versions also support TLS. This software
implements its own private mail database system. Not for
beginners.
● vmail admin a set of PHP and PERL scripts for
administering virtual domains on a pop toaster that uses
Postfix, Postfix virtual or Courier IMAP, and MYSQL.
● Courier-Imap system 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).
● Qpopper system supports POP3, TLS (SSL), and uses the
traditional UNIX-style mailbox format (multiple messages
per file, each message starts with "From sender date...").
Webmail
● phpGroupWare multi-user groupware suite written in

PHP.
● Squirrelmail PHP4 based system.
● OpenWebmail system.
● @Mail system (also for wireless telephone).
● IMP system.
● NeoMail system.
● CAMAS system, an IMHO variant.
● IMHO system.
Package management

● Solaris utility to create Postfix installable packages.
Autoreply software
● yaa! (yet another autoresponder) autoreply utility by

Branko Grac. This can run as a one-time command at the
end of a pipe, or as a resident server.
● Autoreply system architecture by Joshua E. Warchol. You
still need to provide the PERL script that does the actual
responding.
● gnarwl autoreply utility by Patrick Ahlbrecht. This uses
LDAP instead of .forward+vacation.
Quota software
● Per-user mailbox quota patch by Keith Stevenson. Not

part of Postfix because it does not work with maildir files
and because users with .forward files can bypass quota
restrictions.
● PostmMon Postfix Mail Box Monitor by Eduardo Mendes
and Ricardo Malafaia. This sends mail notifications when
a user has too much mail.
● Postfix virtual delivery agent patches with additional
features including quota by Anderson Nadal.
Miniature client software
● mini_sendmail utility by Jef Poskanzer, a minimal

program to submit mail over SMTP, for example, from a
chrooted WWW server.
● nbSMTP (no-brainer SMTP) utility by Fernando Jose
Pereda Garcimartin.
Other software
● Multi-line SMTP banners patch by Simon J Mudd.

Grumble.
● Patches by Michael Tokarev.
● Patches by Ragnar Kurm.

● Patches by Cygnus: mail spool hashing, mailbox size

limit, maildir size limit.

Postfix Packages and Ports
Postfix Packages and Ports

Home
Non-English Info ● Mandrake Linux ships with Postfix built in.
Web sites (text) ● RedHat Linux ships with Postfix built in.
Download (source) ● NetBSD ships with Postfix built in.
Mailing lists ● SuSE Linux ships with Postfix built in.
Press and Interviews ● Conectiva Linux ships with Postfix builtin.
Documentation ● FreeBSD port of Postfix source code.
Howtos and FAQs ● OpenBSD port of Postfix source code.
Add-on Software ● RedHat Linux packages archive by Simon J Mudd for
Packages and Ports
Intel, Alpha and for System 390 :-).
● Debian Linux packages.
● Slackware Linux packages.
Search
● VineLinux (Japanese localised) packages by Keitaro
Yoshimura.
● Mac OS X packages.
● HP-UX packages by Ralf Hildebrandt.
● Solaris packages by Joost van Baal.
http://www.subneural.net/postfix-master/packages.html01/16/2005 15:45:49
Becoming a Postfix mirror site
Becoming a Postfix mirror site

In order to have your Postfix mirror site listed on the Postfix web
site, please send mail to wietse@porcupine.org that answers the
following questions.
QUICK LINKS
Home Please note: Wietse often saves up the website updates for a week
Non-English Info or more before going through them.
Web sites (text)
Download (source) ● Timeliness: specify your mirroring frequency. Use a
Mailing lists mirroring procedure that:
Documentation ❍runs as a CRON job
Howtos and FAQs ❍ runs least once a day.
Add-on Software ● Accuracy: specify what mirroring software will you be

Packages and Ports using. Use mirroring software that:
❍ downloads only the new files
Search ❍ removes all files that no longer exist on the primary
server.
Wietse's preferred mirroring utility is at http://www.

sunsite.org.uk/packages/mirror/
● What: specify what files you are going to mirror:
source code: ftp://ftp.porcupine.org/mirrors/postfix-

❍
release/
❍ web pages: ftp://ftp.porcupine.org/mirrors/postfix-
master/
● Where: specify at what URLs the information will be
made available.
● Location: specify what city/country should be listed on the

Postfix web site.
http://www.subneural.net/postfix-master/mirror.html01/16/2005 15:45:49
Postfix Basic Configuration
Introduction
Postfix has several hundred configuration parameters that are controlled via the main.cf file.
Fortunately, all parameters have sensible default values. In many cases, you need to configure
only two or three parameters before you can start to play with the mail system. Here's a quick
introduction to the syntax:
● Postfix configuration files
The text below assumes that you already have Postfix installed on the system, either by
compiling the source code yourself (as described in the INSTALL file) or by installing an
already compiled version.
This document covers basic Postfix configuration. Information about how to configure Postfix
for specific applications such as mailhub, firewall or dial-up client can be found in the
STANDARD_CONFIGURATION_README file. But don't go there until you already have
covered the material presented below.
The first parameters of interest specify the machine's identity and role in the network.
● What domain name to use in outbound mail
● What domains to receive mail for
● What clients to relay mail from
● What destinations to relay mail to
● What delivery method: direct or indirect
http://www.subneural.net/postfix-master/BASIC_CONFIGURATION_README.html (1 of 12)01/16/2005 15:45:50

The default values for many other configuration parameters are derived from just these.
The next parameter of interest controls the amount of mail sent to the local postmaster:
● What trouble to report to the postmaster
Be sure to set the following correctly if you're behind a proxy or network address translator,
and you are running a backup MX host for some other domain:
● Proxy/NAT external network addresses
Postfix daemon processes run in the background, and log problems and normal activity to the
syslog daemon. Here are a few things that you need to be aware of:
● What you need to know about Postfix logging
If your machine has unusual security requirements you may want to run Postfix daemon
processes inside a chroot environment.
● Running Postfix daemon processes chrooted
If you run Postfix on a virtual network interface, or if your machine runs other mailers on
virtual interfaces, you'll have to look at the other parameters listed here as well:
● My own hostname
● My own domain name
● My own network addresses
Postfix configuration files

By default, Postfix configuration files are in /etc/postfix. The two most important files are main.
cf and master.cf; these files must be owned by root. Giving someone else write permission to
main.cf or master.cf (or to their parent directories) means giving root privileges to that person.
In /etc/postfix/main.cf you will have to set up a minimal number of configuration parameters.

Postfix configuration parameters resemble shell variables, with two important differences: the
first one is that Postfix does not know about quotes like the UNIX shell does.

You specify a configuration parameter as:
/etc/postfix/main.cf:
parameter = value
and you use it by putting a "$" character in front of its name:
other_parameter = $parameter
You can use $parameter before it is given a value (that is the second main difference with
UNIX shell variables). The Postfix configuration language uses lazy evaluation, and does not
look at a parameter value until it is needed at runtime.
Postfix uses database files for access control, address rewriting and other purposes. The
DATABASE_README file gives an introduction to how Postfix works with Berkeley DB,
LDAP or SQL and other types. Here is a common example of how Postfix invokes a database:
virtual_alias_maps = hash:/etc/postfix/virtual
Whenever you make a change to the main.cf or master.cf file, execute the following command
as root in order to refresh a running mail system:
# postfix reload
What domain name to use in outbound mail

The myorigin parameter specifies the domain that appears in mail that is posted on this
machine. The default is to use the local machine name, $myhostname, which defaults to the
name of the machine. Unless you are running a really small site, you probably want to change
that into $mydomain, which defaults to the parent domain of the machine name.
For the sake of consistency between sender and recipient addresses, myorigin also specifies the
domain name that is appended to an unqualified recipient address.
Examples (specify only one of the following):

myorigin = $myhostname (default: send mail as

"user@$myhostname")
myorigin = $mydomain (probably desirable: "user@
$mydomain")
What domains to receive mail for

The mydestination parameter specifies what domains this machine will deliver locally, instead
of forwarding to another machine. The default is to receive mail for the machine itself. See the
VIRTUAL_README file for how to configure Postfix for hosted domains.
You can specify zero or more domain names, "/file/name" patterns and/or "type:table" lookup
tables (such as hash:, btree:, nis:, ldap:, or mysql:), separated by whitespace and/or commas. A
"/file/name" pattern is replaced by its contents; "type:table" requests that a table lookup is done
and merely tests for existence: the lookup result is ignored.
IMPORTANT: If your machine is a mail server for its entire domain, you must list $mydomain
as well.
Example 1: default setting.
mydestination = $myhostname localhost.$mydomain
localhost
Example 2: domain-wide mail server.
localhost $mydomain
Example 3: host with multiple DNS A records.
localhost
www.$mydomain ftp.$mydomain
Caution: in order to avoid mail delivery loops, you must list all hostnames of the machine,

including $myhostname, and localhost.$mydomain.
What clients to relay mail from

By default, Postfix will forward mail from clients in authorized network blocks to any
destination. Authorized networks are defined with the mynetworks configuration parameter.
The default is to authorize all clients in the IP subnetworks that the local machine is attached
to.
IMPORTANT: If your machine is connected to a wide area network then your default
mynetworks setting may be too friendly.
mynetworks_style = subnet (default: authorize
subnetworks)
mynetworks_style = host (safe: authorize local
machine only)
mynetworks = 127.0.0.0/8 (safe: authorize local
machine only)
mynetworks = 127.0.0.0/8 168.100.189.2/32
(authorize local machine)
You can specify the trusted networks in the main.cf file, or you can let Postfix do the work for
you. The default is to let Postfix do the work. The result depends on the mynetworks_style
parameter value.
● Specify "mynetworks_style = host" when Postfix should forward mail from only the
local machine.
● Specify "mynetworks_style = subnet" (the default) when Postfix should forward mail
from SMTP clients in the same IP subnetworks as the local machine. On Linux, this
works correctly only with interfaces specified with the "ifconfig" command.
● Specify "mynetworks_style = class" when Postfix should forward mail from SMTP
clients in the same IP class A/B/C networks as the local machine. Don't do this with a
dialup site - it would cause Postfix to "trust" your entire provider's network. Instead,
specify an explicit mynetworks list by hand, as described below.

Alternatively, you can specify the mynetworks list by hand, in which case Postfix ignores the
mynetworks_style setting. To specify the list of trusted networks by hand, specify network
blocks in CIDR (network/mask) notation, for example:
mynetworks = 168.100.189.0/28, 127.0.0.0/8
You can also specify the absolute pathname of a pattern file instead of listing the patterns in the
main.cf file.
What destinations to relay mail to

By default, Postfix will forward mail from strangers (clients outside authorized networks) to
authorized remote destinations only. Authorized remote destinations are defined with the
relay_domains configuration parameter. The default is to authorize all domains (and
subdomains) of the domains listed with the mydestination parameter.
relay_domains = $mydestination (default)
relay_domains = (safe: never forward
mail from strangers)
relay_domains = $mydomain (forward mail to my
domain and subdomains)
What delivery method: direct or indirect

By default, Postfix tries to deliver mail directly to the Internet. Depending on your local
conditions this may not be possible or desirable. For example, your system may be turned off
outside office hours, it may be behind a firewall, or it may be connected via a provider who
does not allow direct mail to the Internet. In those cases you need to configure Postfix to
deliver mail indirectly via a relay host.
relayhost = (default: direct
delivery to Internet)

relayhost = $mydomain (deliver via local

mailhub)
relayhost = [mail.$mydomain] (deliver via local
mailhub)
relayhost = [mail.isp.tld] (deliver via
provider mailhub)
The form enclosed with [] eliminates DNS MX lookups. Don't worry if you don't know what
that means. Just be sure to specify the [] around the mailhub hostname that your ISP gave to
you, otherwise mail may be mis-delivered.
The STANDARD_CONFIGURATION_README file has more hints and tips for firewalled
and/or dial-up networks.
What trouble to report to the postmaster

You should set up a postmaster alias in the aliases(5) table that directs mail to a human person.
The postmaster address is required to exist, so that people can report mail delivery problems.
While you're updating the aliases(5) table, be sure to direct mail for the super-user to a human
person too.
/etc/aliases:
postmaster: you
root: you
Execute the command "newaliases" after changing the aliases file. Instead of /etc/aliases, your
alias file may be located elsewhere. Use the command "postconf alias_maps" to find out.
The Postfix system reports problems to the postmaster alias. You may not be interested in all
types of trouble reports, so this reporting mechanism is configurable. The default is to report
only serious problems (resource, software) to postmaster:
Default setting:
notify_classes = resource, software
The meaning of the classes is as follows:
bounce

Inform the postmaster of undeliverable mail. Either send the postmaster a

copy of undeliverable mail that is returned to the sender, or send a
transcript of the SMTP session when Postfix rejected mail. For privacy
reasons, the postmaster copy of undeliverable mail is truncated after the
original message headers. This implies "2bounce" (see below). See also
the luser_relay feature. The notification is sent to the address specified
with the bounce_notice_recipient configuration parameter (default:
postmaster).
2bounce
When Postfix is unable to return undeliverable mail to the sender, send it
to the postmaster instead (without truncating the message after the
primary headers). The notification is sent to the address specified with the
2bounce_notice_recipient configuration parameter (default: postmaster).
delay
Inform the postmaster of delayed mail. In this case, the postmaster
receives message headers only. The notification is sent to the address
specified with the delay_notice_recipient configuration parameter
(default: postmaster).
policy
Inform the postmaster of client requests that were rejected because of
(UCE) policy restrictions. The postmaster receives a transcript of the
SMTP session. The notification is sent to the address specified with the
error_notice_recipient configuration parameter (default: postmaster).
protocol
Inform the postmaster of protocol errors (client or server side) or attempts
by a client to execute unimplemented commands. The postmaster receives
a transcript of the SMTP session. The notification is sent to the address
specified with the error_notice_recipient configuration parameter
resource
Inform the postmaster of mail not delivered due to resource problems (for
example, queue file write errors). The notification is sent to the address
specified with the error_notice_recipient configuration parameter
software
Inform the postmaster of mail not delivered due to software problems.
The notification is sent to the address specified with the
Proxy/NAT external network addresses

Some mail servers are connected to the Internet via a network address translator (NAT) or
proxy. This means that systems on the Internet connect to the address of the NAT or proxy,
instead of connecting to the network address of the mail server. The NAT or proxy forwards
the connection to the network address of the mail server, but Postfix does not know this.
If you run a Postfix server behind a proxy or NAT, you need to configure the proxy_interfaces
parameter and specify all the external proxy or NAT addresses that Postfix receives mail on.
You may specify symbolic hostnames instead of network addresses.
IMPORTANT: You must specify your proxy/NAT external addresses when your system is a
backup MX host for other domains, otherwise mail delivery loops will happen when the
primary MX host is down.
Example: host behind NAT box running a backup MX host.
proxy_interfaces = 1.2.3.4 (the proxy/NAT
external network address)
What you need to know about Postfix logging

syslog daemon. The syslogd process sorts events by class and severity, and appends them to
logfiles. The logging classes, levels and logfile names are usually specified in /etc/syslog.conf.
At the very least you need something like:
/etc/syslog.conf:
mail.err /dev/
console
mail.debug /var/
log/maillog
After changing the syslog.conf file, send a "HUP" signal to the syslogd process.
IMPORTANT: many syslogd implementations will not create files. You must create files
before (re)starting syslogd.
IMPORTANT: on Linux you need to put a "-" character before the pathname, e.g., -/var/log/
maillog, otherwise the syslogd process will use more system resources than Postfix.

Hopefully, the number of problems will be small, but it is a good idea to run every night before
the syslog files are rotated:
# postfix check
# egrep '(reject|warning|error|fatal|panic):' /some/
log/file
● The first line (postfix check) causes Postfix to report file permission/ownership
discrepancies.
● The second line looks for problem reports from the mail software, and reports how
effective the relay and junk mail access blocks are. This may produce a lot of output.
You will want to apply some postprocessing to eliminate uninteresting information.
The DEBUG_README document describes the meaning of the "warning" etc. labels in
Postfix logging.
Running Postfix daemon processes chrooted

Postfix daemon processes can be configured (via the master.cf file) to run in a chroot jail. The
processes run at a fixed low privilege and with file system access limited to the Postfix queue
directories (/var/spool/postfix). This provides a significant barrier against intrusion. The barrier
is not impenetrable (chroot limits file system access only), but every little bit helps.
With the exception of Postfix daemons that deliver mail locally and/or that execute non-Postfix
commands, every Postfix daemon can run chrooted.
Sites with high security requirements should consider to chroot all daemons that talk to the
network: the smtp(8) and smtpd(8) processes, and perhaps also the lmtp(8) client. The author's
own porcupine.org mail server runs all daemons chrooted that can be chrooted.
The default /etc/postfix/master.cf file specifies that no Postfix daemon runs chrooted. In order
to enable chroot operation, edit the file /etc/postfix/master.cf, and follow instructions in the file.
When you're finished, execute "postfix reload" to make the change effective.
Note that a chrooted daemon resolves all filenames relative to the Postfix queue directory (/var/
spool/postfix). For successful use of a chroot jail, most UNIX systems require you to bring in
some files or device nodes. The examples/chroot-setup directory in the source code distribution
has a collection of scripts that help you set up Postfix chroot environments on different
operating systems.

Additionally, you almost certainly need to configure syslogd so that it listens on a socket inside
the Postfix queue directory. Examples of syslogd command line options that achieve this for
specific systems:
FreeBSD: syslogd -l /var/spool/postfix/var/run/log
Linux, OpenBSD: syslogd -a /var/spool/postfix/dev/log
My own hostname
The myhostname parameter specifies the fully-qualified domain name of the machine running
the Postfix system. $myhostname appears as the default value in many other Postfix
configuration parameters.
By default, myhostname is set to the local machine name. If your local machine name is not in
fully-qualified domain name form, or if you run Postfix on a virtual interface, you will have to
specify the fully-qualified domain name that the mail system should use.
Alternatively, if you specify mydomain in main.cf, then Postfix will use its value to generate a
fully-qualified default value for the myhostname parameter.
myhostname = host.local.domain (machine name is
not FQDN)
myhostname = host.virtual.domain (virtual
interface)
myhostname = virtual.domain (virtual interface)
My own domain name

The mydomain parameter specifies the parent domain of $myhostname. By default, it is
derived from $myhostname by stripping off the first part (unless the result would be a top-level
domain).
Conversely, if you specify mydomain in main.cf, then Postfix will use its value to generate a
fully-qualified default value for the myhostname parameter.

mydomain = local.domain
mydomain = virtual.domain (virtual interface)
My own network addresses

The inet_interfaces parameter specifies all network interface addresses that the Postfix system
should listen on; mail addressed to "user@[network address]" will be delivered locally, as if it
is addressed to a domain listed in $mydestination.
You can override the inet_interfaces setting in the Postfix master.cf file by prepending an IP
address to a server name.
The default is to listen on all active interfaces. If you run mailers on virtual interfaces, you will
have to specify what interfaces to listen on.
IMPORTANT: If you run MTAs on virtual interfaces you must specify explicit inet_interfaces
values for the MTA that receives mail for the machine itself: this MTA should never listen on
the virtual interfaces or you would have a mailer loop when a virtual MTA is down.
Example: default setting.
inet_interfaces = all
Example: host running one or more virtual mailers. For each Postfix instance, specify only one
of the following.
inet_interfaces = virtual.host.tld
(virtual Postfix)
inet_interfaces = $myhostname localhost... (non-
virtual Postfix)
Note: you need to stop and start Postfix after changing this parameter.

Postfix Installation From Source Code
Postfix Installation From

Source Code
1 - Purpose of this document

This is a bootstrap document that helps you get Postfix up and running from scratch with the
minimal number of steps. If you are using a pre-compiled version of Postfix, you should be
reading the general Postfix documentation which aims to describe the system in more detail.
This bootstrap document should not be considered part of the general Postfix documentation.
This document describes how to build, install and configure a Postfix system so that it can do
one of the following:
● Send mail only, without changing an existing Sendmail installation.

● Send and receive mail via a virtual host interface, still without any change to an existing
Sendmail installation.
● Run Postfix instead of Sendmail.
Topics covered in this document:
1. Purpose of this document

2. Typographical conventions
3. Documentation
4. Building on a supported system
5. Porting Postfix to an unsupported system
6. Installing the software after successful compilation
7. Configuring Postfix to send mail only
8. Configuring Postfix to send and receive mail via virtual interface
9. Running Postfix instead of Sendmail
10. Mandatory configuration file edits
11. To chroot or not to chroot
http://www.subneural.net/postfix-master/INSTALL.html (1 of 17)01/16/2005 15:45:51

12. Care and feeding of the Postfix system
2 - Typographical conventions
In the instructions below, a command written as
# command
should be executed as the superuser.
A command written as
% command
should be executed as an unprivileged user.
3 - Documentation
Documentation is available as README files (start with the file README_FILES/
AAAREADME), as HTML web pages (point your browser to "html/index.html") and as UNIX-
style manual pages.
You should view the README files with a pager such as more(1) or less(1), because the files
use backspace characters in order to produce bold font. To print a README file without
backspace characters, use the col(1) command. For example:
% col -bx <file | lpr
In order to view the manual pages before installing Postfix, point your MANPATH
environment variable to the "man" subdirectory; be sure to use an absolute path.
% export MANPATH; MANPATH="`pwd`/man:$MANPATH"

% setenv MANPATH "`pwd`/man:$MANPATH"
Of particular interest is the postconf(5) manual page that lists all the 300+ configuration
parameters. The HTML version of this text makes it easy to navigate around.
All Postfix source files have their own built-in manual page. Tools to extract those embedded
manual pages are available in the mantools directory.

4 - Building on a supported system

At some point in time, a version of Postfix was supported on:
AIX 3.2.5, 4.1.x, 4.2.0, 4.3.x, 5.2

BSD/OS 2.x, 3.x, 4.x
Darwin 1.x
FreeBSD 2.x, 3.x, 4.x, 5.x
HP-UX 9.x, 10.x, 11.x
IRIX 5.x, 6.x
Linux Debian 1.3.1, 2.x, 3.x
Linux RedHat 3.x (January 2004) - 9.x
Linux Slackware 3.x, 4.x, 7.x
Linux SuSE 5.x, 6.x, 7.x
Mac OS X
NEXTSTEP 3.x
NetBSD 1.x
OPENSTEP 4.x
OSF1.V3 - OSF1.V5 (Digital UNIX)
Reliant UNIX 5.x
Rhapsody 5.x
SunOS 4.1.4 (April 2004)
SunOS 5.4 - 5.9 (Solaris 2.4..9)
Ultrix 4.x (well, that was long ago)
or something closely resemblant.
4.1 - Getting started
On Solaris, the "make" command and other utilities for software development are in /usr/ccs/
bin, so you MUST have /usr/ccs/bin in your command search path.
If you need to build Postfix for multiple architectures, use the "lndir" command to build a
shadow tree with symbolic links to the source files. "lndir" is part of X11R6.
If at any time in the build process you get messages like: "make: don't know how to ..." you
should be able to recover by running the following command from the Postfix top-level
directory:
% make -f Makefile.init makefiles

If you copied the Postfix source code after building it on another machine, it is a good idea to
cd into the top-level directory and first do this:
% make tidy
This will get rid of any system dependencies left over from compiling the software elsewhere.
4.2 - What compiler to use
To build with GCC, or with the native compiler if people told me that is better for your system,
just cd into the top-level Postfix directory of the source tree and type:
% make
To build with a non-default compiler, you need to specify the name of the compiler. Here are a
few examples:
% make makefiles CC=/opt/SUNWspro/bin/cc

(Solaris)
% make
% make makefiles CC="/opt/ansic/bin/cc -Ae" (HP-

UX)
% make
% make makefiles CC="purify cc"

% make
and so on. In some cases, optimization is turned off automatically.
4.3 - Building with optional extensions
By default, Postfix builds as a mail system with relatively few bells and whistles. Support for
third-party databases etc. must be configured when Postfix is compiled. The following
documents describe how to build Postfix with support for extensions:
Postfix extension Document Availability

Berkeley DB database DB_README Postfix 1.0
LDAP database LDAP_README Postfix 1.0

MySQL database MYSQL_README Postfix 1.0

Perl compatible regular expression PCRE_README Postfix 1.0
PostgreSQL database PGSQL_README Postfix 2.0
SASL authentication SASL_README Postfix 1.0
STARTTLS session encryption TLS_README Postfix 2.2
Note: IP version 6 is still separate from Postfix but is expected to be merged soon.
4.4 - Overriding built-in parameter default settings
All Postfix configuration parameters can be changed by editing a Postfix configuration file,
except for one: the parameter that specifies the location of Postfix configuration files. In order
to build Postfix with a configuration directory other than /etc/postfix, use:
% make makefiles CCARGS='-DDEF_CONFIG_DIR=\"/some/

where\"'
% make
IMPORTANT: Be sure to get the quotes right. These details matter a lot.
Parameters whose defaults can be specified in this way are:
Macro name default value for typical default

DEF_COMMAND_DIR command_directory /usr/sbin
DEF_CONFIG_DIR config_directory /etc/postfix
DEF_DAEMON_DIR daemon_directory /usr/libexec/postfix
DEF_MAILQ_PATH mailq_path /usr/bin/mailq
DEF_HTML_DIR html_directory no
DEF_MANPAGE_DIR manpage_directory /usr/local/man
DEF_NEWALIAS_PATH newaliases_path /usr/bin/newaliases
DEF_QUEUE_DIR queue_directory /var/spool/postfix
DEF_README_DIR readme_directory no
DEF_SENDMAIL_PATH sendmail_path /usr/sbin/sendmail

4.5 - Support for thousands of processes
In order to build Postfix for very large applications, where you expect to run more than 1000
mail delivery processes, you may need to override the definition of the FD_SETSIZE macro to
make select() work correctly:
% make makefiles CCARGS=-DFD_SETSIZE=2048
Warning: the above has no effect on some Linux versions. Apparently, on these systems the
FD_SETSIZE value can be changed only by using undocumented interfaces. Currently, that
means including <bits/types.h> directly (which is not allowed) and overriding the
__FD_SETSIZE macro. Beware, undocumented interfaces can change at any time and without
warning.
4.6 - Compiling Postfix, at last
If the command
% make
is successful, then you can proceed to install Postfix (section 6).
If the command produces compiler error messages, it may be time to search the web or to ask
the postfix-users@postfix.org mailing list, but be sure to search the mailing list archives first.
Some mailing list archives are linked from http://www.postfix.org/.
5 - Porting Postfix to an unsupported system

Each system type that Postfix knows is identified by a unique name. Examples: SUNOS5,
FREEBSD4, and so on. When porting Postfix to a new system, the first step is to choose a
SYSTEMTYPE name for the new system. You must use a name that includes at least the major
version of the operating system (such as SUNOS4 or LINUX2), so that different releases of the
same system can be supported without confusion.
Add a case statement to the "makedefs" shell script in the source code top-level directory that
recognizes the new system reliably, and that emits the right system-specific information. Be
sure to make the code robust against user PATH settings; if the system offers multiple UNIX
flavors (e.g. BSD and SYSV) be sure to build for the native flavor, instead of the emulated one.
Add an "#ifdef SYSTEMTYPE" section to the central util/sys_defs.h include file. You may

have to invent new feature macro names. Please choose sensible feature macro names such as
HAS_DBM or FIONREAD_IN_SYS_FILIO_H.
I strongly recommend against using "#ifdef SYSTEMTYPE" in individual source files. While
this may look like the quickest solution, it will create a mess when newer versions of the same
SYSTEMTYPE need to be supported. You're likely to end up placing "#ifdef" sections all over
the source code again.
6 - Installing the software after successful compilation

This text describes how to install Postfix from source code. See the PACKAGE_README file
if you are building a package for distribution to other systems. See auxiliary/MacOSX/
README-INSTALL.OSX for information about installing Postfix from source on Mac OS X.
6.1 - Save existing Sendmail binaries
IMPORTANT: if you are REPLACING an existing Sendmail installation with Postfix, you
may need to keep the old sendmail program running for some time in order to flush the mail
queue. As superuser, execute the following commands (your sendmail, newaliases and mailq
programs may be in a different place):
# mv /usr/sbin/sendmail /usr/sbin/sendmail.OFF
# mv /usr/bin/newaliases /usr/bin/newaliases.OFF
# mv /usr/bin/mailq /usr/bin/mailq.OFF
# chmod 755 /usr/sbin/sendmail.OFF /usr/bin/
newaliases.OFF \
/usr/bin/mailq.OFF
6.2 - Create account and groups
Before you install Postfix for the first time you need to create an account and a group:
● Create a user account "postfix" with a user id and group id that are not used by any
other user account. Preferably, this is an account that no-one can log into. The account
does not need an executable login shell, and needs no existing home directory. My
password and group file entries look like this:
/etc/passwd:
postfix:*:12345:12345:postfix:/no/where:/no/
shell

/etc/group:
postfix:*:12345:
Note: there should be no whitespace before "postfix:".
● Make sure there is a "postfix" alias in /etc/aliases, or whatever the pathname of your
aliases file is; the command "postconf alias_maps" will tell you.
/etc/aliases:
postfix: root
Note: there should be no whitespace before "postfix:".
● Create a group "postdrop" with a group id that is not used by any other user account.
Not even by the postfix user account. My group file entry looks like:
/etc/group:
postdrop:*:54321:
Note: there should be no whitespace before "postdrop:".
6.3 - Install Postfix
To install or upgrade Postfix from compiled source code, run one of the following commands
as the super-user:
# make install (interactive version, first time

install)
# make upgrade (non-interactive version, for

upgrades)
● The non-interactive version ("make upgrade") needs the /etc/postfix/main.cf file from a
previous installation. If the file does not exist, use interactive installation ("make
install") instead.
● The interactive version offers suggestions for pathnames that you can override
interactively, and stores your preferences in /etc/postfix/main.cf for convenient future
upgrades.

6.4 - Configure Postfix
Proceed to the section on how you wish to run Postfix on your particular machine:
● Send mail only, without changing an existing Sendmail installation (section 7).
Sendmail installation (section 8).
● Run Postfix instead of Sendmail (section 9).
7 - Configuring Postfix to send mail only

If you are going to use Postfix to send mail only, there is no need to change your existing
sendmail setup. Instead, set up your mail user agent so that it calls the Postfix sendmail
program directly.
Follow the instructions in the "Mandatory configuration file edits" in section 10, and review the
"To chroot or not to chroot" text in section 11.
You MUST comment out the "smtp inet" entry in /etc/postfix/master.cf, in order to avoid
conflicts with the real sendmail. Put a "#" character in front of the line that defines the smtpd
service:
/etc/postfix/master.cf:
#smtp inet n - n -
- smtpd
Start the Postfix system:
# postfix start
or, if you feel nostalgic, use the Postfix sendmail command:
# sendmail -bd -qwhatever
and watch your maillog file for any error messages. The pathname is /var/log/maillog, /var/log/
mail, /var/log/syslog, or something else. Typically, the pathname is defined in the /etc/syslog.
conf file.

% egrep '(reject|warning|error|fatal|panic):' /some/

log/file
Note: the most important error message is logged first. Later messages are not as useful.
In order to inspect the mail queue, use one of the following commands:
% mailq
% sendmail -bp
% postqueue -p
See also the "Care and feeding" section 12 below.
8 - Configuring Postfix to send and receive mail via virtual

interface
Alternatively, you can use the Postfix system to send AND receive mail while leaving your
Sendmail setup intact, by running Postfix on a virtual interface address. Simply configure your
mail user agent to directly invoke the Postfix sendmail program.
In the /etc/postfix/main.cf file, I would specify
myhostname = virtual.host.tld
inet_interfaces = $myhostname
mydestination = $myhostname
Follow the instructions in the "Mandatory configuration file edits" in section 10, and review the
"To chroot or not to chroot" text in section 11.
Start the Postfix system:
# postfix start

mail, /var/log/syslog, or something else. Typically, the pathname is defined in the /etc/syslog.
conf file.

log/file
% mailq
% sendmail -bp
% postqueue -p
9 - Running Postfix instead of Sendmail

Prior to installing Postfix you should save any existing sendmail program files as described in
section 6. Be sure to keep the old sendmail running for at least a couple days to flush any
unsent mail. To do so, stop the sendmail daemon and restart it as:
# /usr/sbin/sendmail.OFF -q
Note: this is old sendmail syntax. Newer versions use separate processes for mail submission
and for running the queue.
After you have visited the "Mandatory configuration file edits" section below, you can start the
Postfix system with:
# postfix start

mail, /var/log/syslog, or someting else. Typically, the pathname is defined in the /etc/syslog.
conf file.

log/file
% mailq
% sendmail -bp
% postqueue -p
10 - Mandatory configuration file edits

Note: the material covered in this section is covered in more detail in the
BASIC_CONFIGURATION_README document. The information presented below is
targeted at experienced system administrators.
10.1 - Postfix configuration files
By default, Postfix configuration files are in /etc/postfix. The two most important files are main.
cf and master.cf; these files must be owned by root. Giving someone else write permission to
main.cf or master.cf (or to their parent directories) means giving root privileges to that person.
In /etc/postfix/main.cf, you will have to set up a minimal number of configuration parameters.

Postfix configuration parameters resemble shell variables, with two important differences: the
first one is that Postfix does not know about quotes like the UNIX shell does.
You specify a configuration parameter as:
parameter = value

and you use it by putting a "$" character in front of its name:
other_parameter = $parameter
You can use $parameter before it is given a value (that is the second main difference with
UNIX shell variables). The Postfix configuration language uses lazy evaluation, and does not
look at a parameter value until it is needed at runtime.
Whenever you make a change to the main.cf or master.cf file, execute the following command
in order to refresh a running mail system:
# postfix reload
10.2 - Default domain for unqualified addresses
First of all, you must specify what domain will be appended to an unqualified address (i.e. an
address without @domain.tld). The "myorigin" parameter defaults to the local hostname, but
that is probably OK only for very small sites.
Some examples (use only one):
myorigin = $myhostname (send mail as "user@
$myhostname")
myorigin = $mydomain (send mail as "user@
$mydomain")
10.3 - What domains to receive locally
Next you need to specify what mail addresses Postfix should deliver locally.
mydestination = $myhostname, localhost.$mydomain,
localhost
localhost, $mydomain

The first example is appropriate for a workstation, the second is appropriate for the mailserver
for an entire domain. The third example should be used when running on a virtual host
interface.
10.4 - Proxy/NAT interface addresses
The proxy_interfaces parameter specifies all network addresses that Postfix receives mail on by
way of a proxy or network address translation unit. You may specify symbolic hostnames
instead of network addresses.
IMPORTANT: You must specify your proxy/NAT external addresses when your system is a
backup MX host for other domains, otherwise mail delivery loops will happen when the
Example: host behind NAT box running a backup MX host.
proxy_interfaces = 1.2.3.4 (the proxy/NAT
external network address)
10.5 - What local clients to relay mail from
If your machine is on an open network then you must specify what client IP addresses are
authorized to relay their mail through your machine into the Internet. The default setting
includes all subnetworks that the machine is attached to. This may give relay permission to too
many clients. My own settings are:
mynetworks = 168.100.189.0/28, 127.0.0.0/8
10.6 - What relay destinations to accept from strangers
If your machine is on an open network then you must also specify whether Postfix will forward
mail from strangers. The default setting will forward mail to all domains (and subdomains of)
what is listed in $mydestination. This may give relay permission for too many destinations.
Recommended settings (use only one):
relay_domains = (do not forward mail

from strangers)
relay_domains = $mydomain (my domain and
subdomains)
relay_domains = $mydomain, other.domain.tld, ...
10.7 - Optional: configure a smart host for remote delivery
If you're behind a firewall, you should set up a relayhost. If you can, specify the organizational
domain name so that Postfix can use DNS lookups, and so that it can fall back to a secondary
MX host when the primary MX host is down. Otherwise just specify a hard-coded hostname.
relayhost = $mydomain
relayhost = [mail.$mydomain]
The form enclosed with [] eliminates DNS MX lookups.
By default, the SMTP client will do DNS lookups even when you specify a relay host. If your
machine has no access to a DNS server, turn off SMTP client DNS lookups like this:
disable_dns_lookups = yes
The STANDARD_CONFIGURATION_README file has more hints and tips for firewalled
and/or dial-up networks.
10.8 - Create the aliases database
Finally, if you haven't used Sendmail prior to using Postfix, you will have to build the alias
database with one of the following commands:
# newaliases
# sendmail -bi
Be sure to set up aliases for root and postmaster that forward mail to a real person. Postfix has
a sample aliases file /etc/postfix/aliases that you can adapt to local conditions.

11 - To chroot or not to chroot

Postfix daemon processes can be configured (via master.cf) to run in a chroot jail. The
processes run at a fixed low privilege and with access only to the Postfix queue directories (/
var/spool/postfix). This provides a significant barrier against intrusion. The barrier is not
impenetrable, but every little bit helps.
With the exception of Postfix daemons that deliver mail locally and/or that execute non-Postfix
commands, every Postfix daemon can run chrooted.
Sites with high security requirements should consider to chroot all daemons that talk to the
network: the smtp(8) and smtpd(8) processes, and perhaps also the lmtp(8) client. The author's
own porcupine.org mail server runs all daemons chrooted that can be chrooted.
The default /etc/postfix/master.cf file specifies that no Postfix daemon runs chrooted. In order
to enable chroot operation, edit the file /etc/postfix/master.cf. Instructions are in the file.
Note that a chrooted daemon resolves all filenames relative to the Postfix queue directory (/var/
spool/postfix). For successful use of a chroot jail, most UNIX systems require you to bring in
some files or device nodes. The examples/chroot-setup directory in the source code distribution
has a collection of scripts that help you set up Postfix chroot environments on different
operating systems.
Additionally, you almost certainly need to configure syslogd so that it listens on a socket inside
the Postfix queue directory. Examples for specific systems:
FreeBSD:
# mkdir -p /var/spool/postfix/var/run
# syslogd -l /var/spool/postfix/var/run/log
Linux, OpenBSD:
# mkdir -p /var/spool/postfix/dev
# syslogd -a /var/spool/postfix/dev/log
12 - Care and feeding of the Postfix system

syslog daemon. The names of logfiles are specified in /etc/syslog.conf. At the very least you

need something like:
/etc/syslog.conf:
mail.err /dev/
console
mail.debug /var/
log/maillog
IMPORTANT: the syslogd will not create files. You must create them before (re)starting
syslogd.
IMPORTANT: on Linux you need to put a "-" character before the pathname, e.g., -/var/log/
maillog, otherwise the syslogd will use more system resources than Postfix does.
Hopefully, the number of problems will be small, but it is a good idea to run every night before
the syslog files are rotated:
# postfix check
# egrep '(reject|warning|error|fatal|panic):' /some/
log/file
● The first line (postfix check) causes Postfix to report file permission/ownership
discrepancies.
● The second line looks for problem reports from the mail software, and reports how
effective the relay and junk mail access blocks are. This may produce a lot of output.
You will want to apply some postprocessing to eliminate uninteresting information.
The DEBUG_README document describes the meaning of the "warning" etc. labels in
Postfix logging.

Postfix Configuration Parameters
Postfix Configuration
Parameters
Postfix main.cf file format

The Postfix main.cf configuration file specifies a very small subset of all the parameters that
control the operation of the Postfix mail system. Parameters not explicitly specified are left at
their default values.
The general format of the main.cf file is as follows:
● Each logical line is in the form "parameter = value". Whitespace around the "=" is
ignored, as is whitespace at the end of a logical line.
● Empty lines and whitespace-only lines are ignored, as are lines whose first non-
whitespace character is a `#'.
● A logical line starts with non-whitespace text. A line that starts with whitespace
continues a logical line.
● A parameter value may refer to other parameters.
❍ The expressions "$name", "${name}" or "$(name)" are recursively replaced by

the value of the named parameter.
❍ The expression "${name?value}" expands to "value" when "$name" is non-

empty.
❍ The expression "${name:value}" expands to "value" when "$name" is empty.
● When the same parameter is defined multiple times, only the last instance is
http://www.subneural.net/postfix-master/postconf.5.html (1 of 128)01/16/2005 15:45:58

remembered.
● Otherwise, the order of main.cf parameter definitions does not matter.
The remainder of this document is a description of all Postfix configuration parameters.

Default values are shown after the parameter name in parentheses, and can be looked up with
the postconf -d command.
Note: this is not an invitation to make changes to Postfix configuration parameters.

Unnecessary changes are likely to impair the operation of the mail system.
2bounce_notice_recipient (default: postmaster)
The recipient of undeliverable mail that cannot be returned to the sender. This feature is
enabled with the notify_classes parameter.
access_map_reject_code (default: 554)
The numerical Postfix SMTP server response code when a client is rejected by an access
(5) map restriction.
Do not change this unless you have a complete understanding of RFC 821.
address_verify_default_transport (default: $default_transport)
Overrides the default_transport parameter setting for address verification probes.
This feature is available in Postfix 2.1 and later.
address_verify_local_transport (default: $local_transport)
Overrides the local_transport parameter setting for address verification probes.
address_verify_map (default: empty)
Optional lookup table for persistent address verification status storage. The table is
maintained by the verify(8) service, and is opened before the process releases privileges.

By default, the information is kept in volatile memory, and is lost after "postfix reload"
or "postfix stop".
Specify a location in a file system that will not fill up. If the database becomes
corrupted, the world comes to an end. To recover delete the file and do "postfix
reload".
Examples:
address_verify_map = hash:/etc/postfix/verify
address_verify_map = btree:/etc/postfix/verify
address_verify_negative_cache (default: yes)
Enable caching of failed address verification probe results. When this feature is enabled,
the cache may pollute quickly with garbage. When this feature is disabled, Postfix will
generate an address probe for every lookup.
address_verify_negative_expire_time (default: 3d)
The time after which a failed probe expires from the address verification cache.
Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).
address_verify_negative_refresh_time (default: 3h)
The time after which a failed address verification probe needs to be refreshed.
address_verify_poll_count (default: 3)

How many times to query the verify(8) service for the completion of an address
verification request in progress.
The default poll count is 3.
Specify 1 to implement a crude form of greylisting, that is, always defer the first
delivery request for a never seen before address.
Example:
address_verify_poll_count = 1
address_verify_poll_delay (default: 3s)
The delay between queries for the completion of an address verification request in
progress.
The default polling delay is 3 seconds.
address_verify_positive_expire_time (default: 31d)
The time after which a successful probe expires from the address verification cache.
address_verify_positive_refresh_time (default: 7d)
The time after which a successful address verification probe needs to be refreshed. The
address verification status is not updated when the probe fails (optimistic caching).

address_verify_relay_transport (default: $relay_transport)
Overrides the relay_transport parameter setting for address verification probes.
address_verify_relayhost (default: $relayhost)
Overrides the relayhost parameter setting for address verification probes.
address_verify_sender (default: postmaster)
The sender address to use in address verification probes. To avoid problems with
address probes that are sent in response to address probes, the Postfix SMTP server
excludes the probe sender address from all SMTPD access blocks.
Specify an empty value (address_verify_sender =) or <> if you want to use the null
sender address. Beware, some sites reject mail from <>, even though RFCs require that
such addresses be accepted.
Examples:
address_verify_sender = <>
address_verify_sender = postmaster@my.domain
address_verify_service_name (default: verify)
The name of the verify(8) address verification service. This service maintains the status
of sender and/or recipient address verification probes, and generates probes on request
by other Postfix processes.
address_verify_transport_maps (default: $transport_maps)

Overrides the transport_maps parameter setting for address verification probes.
address_verify_virtual_transport (default: $virtual_transport)
Overrides the virtual_transport parameter setting for address verification probes.
alias_database (default: see "postconf -d" output)
The alias databases for local(8) delivery that are updated with "newaliases" or with
"sendmail -bi".
This is a separate configuration parameter because not all the tables specified with
$alias_maps have to be local files.
Examples:
alias_database = hash:/etc/aliases
alias_database = hash:/etc/mail/aliases
alias_maps (default: see "postconf -d" output)
The alias databases that are used for local(8) delivery. See aliases(5) for syntax details.
The default list is system dependent. On systems with NIS, the default is to search the
local alias database, then the NIS alias database.
If you change the alias database, run "postalias /etc/aliases" (or wherever your system
stores the mail alias file), or simply run "newaliases" to build the necessary DBM or
DB file.
Examples:
alias_maps = hash:/etc/aliases, nis:mail.aliases

alias_maps = hash:/etc/aliases

allow_mail_to_commands (default: alias, forward)
Restrict local(8) mail delivery to external commands. The default is to disallow delivery
to "|command" in :include: files (see aliases(5) for the text that defines this
terminology).
Specify zero or more of: alias, forward or include, in order to allow commands in
aliases(5), .forward files or in :include: files, respectively.
Example:
allow_mail_to_commands = alias,forward,include
allow_mail_to_files (default: alias, forward)
Restrict local(8) mail delivery to external files. The default is to disallow "/file/name"
destinations in :include: files (see aliases(5) for the text that defines this terminology).
Specify zero or more of: alias, forward or include, in order to allow "/file/name"
destinations in aliases(5), .forward files and in :include: files, respectively.
Example:
allow_mail_to_files = alias,forward,include
allow_min_user (default: no)
Allow a recipient address to have `-' as the first character. By default, this is not
allowed, to avoid accidents with software that passes email addresses via the command
line. Such software would not be able to distinguish a malicious address from a bona
fide command-line option. Although this can be prevented by inserting a "--" option
terminator into the command line, this is difficult to enforce consistently and globally.
allow_percent_hack (default: yes)
Enable the rewriting of the form "user%domain" to "user@domain". This is enabled by

default.
Example:

allow_percent_hack = no
allow_untrusted_routing (default: no)
Forward mail with sender-specified routing (user[@%!]remote[@%!]site) from

untrusted clients to destinations matching $relay_domains.
By default, this feature is turned off. This closes a nasty open relay loophole where a
backup MX host can be tricked into forwarding junk mail to a primary MX host which
then spams it out to the world.
This parameter also controls if non-local addresses with sender-specified routing can
match Postfix access tables. By default, such addresses cannot match Postfix access
tables, because the address is ambiguous.
alternate_config_directories (default: empty)
A list of non-default Postfix configuration directories that may be specified with "-c
config_directory" on the command line, or via the MAIL_CONFIG environment
parameter.
This list must be specified in the default Postfix configuration directory, and is used by
set-gid Postfix commands such as postqueue(1) and postdrop(1).
always_bcc (default: empty)
Optional address that receives a "blind carbon copy" of each message that is received by
the Postfix mail system.
NOTE: if mail to the BCC address bounces it will be returned to the sender.
NOTE: automatic BCC recipients are produced only for new mail. To avoid mailer
loops, automatic BCC recipients are not generated for mail that Postfix forwards
internally, nor for mail that Postfix generates itself.
anvil_rate_time_unit (default: 60s)
The time unit over which client connection rates and other rates are calculated.
This feature is implemented by the anvil(8) service which is not part of the stable

Postfix 2.1 release.
The default interval is relatively short. Because of the high frequency of updates, the
anvil(8) server uses volatile memory only. Thus, information is lost whenever the
process terminates.
Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). The default time
unit is s (seconds).
anvil_status_update_time (default: 600s)
How frequently the anvil(8) connection and rate limiting server logs peak usage
information.
This feature is implemented by the anvil(8) service which is not part of the stable
Postfix 2.1 release.
append_at_myorigin (default: yes)
With locally submitted mail, append the string "@$myorigin" to mail addresses without
domain information. With remotely submitted mail, append the string "@
$remote_header_rewrite_domain" instead.
This feature is enabled by default and must not be turned off. Postfix does not support
domain-less addresses.
append_dot_mydomain (default: yes)
With locally submitted mail, append the string ".$mydomain" to addresses that have no
".domain" information. With remotely submitted mail, append the string ".
$remote_header_rewrite_domain" instead.
This feature is enabled by default. If disabled, users will not be able to send mail to
"user@partialdomainname" but will have to specify full domain names instead.
application_event_drain_time (default: 100s)

How long the postkick(1) command waits for a request to enter the server's input buffer
before giving up.
authorized_flush_users (default: static:anyone)
List of users who are authorized to flush the queue.
By default, all users are allowed to flush the queue. Access is always granted if the
invoking user is the super-user or the $mail_owner user. Otherwise, the real UID of the
process is looked up in the system password file, and access is granted only if the
corresponding login name is on the access list. The username "unknown" is used for
processes whose real UID is not found in the password file.
Specify a list of user names, "/file/name" or "type:table" patterns, separated by commas

and/or whitespace. The list is matched left to right, and the search stops on the first
match. Specify "!name" to exclude a name from the list. A "/file/name" pattern is
replaced by its contents; a "type:table" lookup table is matched when a name matches a
lookup key (the lookup result is ignored). Continue long lines by starting the next line
with whitespace.
authorized_mailq_users (default: static:anyone)
List of users who are authorized to view the queue.
By default, all users are allowed to view the queue. Access is always granted if the
invoking user is the super-user or the $mail_owner user. Otherwise, the real UID of the
process is looked up in the system password file, and access is granted only if the
corresponding login name is on the access list. The username "unknown" is used for
processes whose real UID is not found in the password file.


with whitespace.
authorized_submit_users (default: static:anyone)
List of users who are authorized to submit mail with the sendmail(1) command (and
with the privileged postdrop(1) helper command).
By default, all users are allowed to submit mail. Otherwise, the real UID of the process
is looked up in the system password file, and access is granted only if the corresponding
login name is on the access list. The username "unknown" is used for processes whose
real UID is not found in the password file. To deny mail submission access to all users
specify an empty list.

with whitespace.
authorized_verp_clients (default: $mynetworks)
What SMTP clients are allowed to specify the XVERP command. This command
requests that mail be delivered one recipient at a time with a per recipient return
address.
By default, only trusted clients are allowed to specify XVERP.
This parameter was introduced with Postfix version 1.1. Postfix version 2.1 renamed
this parameter to smtpd_authorized_verp_clients and changed the default to none.
Specify a list of network/netmask patterns, separated by commas and/or whitespace.

The mask specifies the number of bits in the network part of a host address. You can
also specify hostnames or .domain names (the initial dot causes the domain to match

any name below it), "/file/name" or "type:table" patterns. A "/file/name" pattern is

replaced by its contents; a "type:table" lookup table is matched when a table entry
matches a lookup string (the lookup result is ignored). Continue long lines by starting
the next line with whitespace.
backwards_bounce_logfile_compatibility (default: yes)
Produce additional bounce(8) logfile records that can be read by older Postfix versions.
The current and more extensible "name = value" format is needed in order to implement
more sophisticated functionality.
berkeley_db_create_buffer_size (default: 16777216)
The per-table I/O buffer size for programs that create Berkeley DB hash or btree tables.
Specify a byte count.
berkeley_db_read_buffer_size (default: 131072)
The per-table I/O buffer size for programs that read Berkeley DB hash or btree tables.
Specify a byte count.
best_mx_transport (default: empty)
Where the Postfix SMTP client should deliver mail when it detects a "mail loops back
to myself" error condition. This happens when the local MTA is the best SMTP mail
exchanger for a destination not listed in $mydestination, $inet_interfaces,
$proxy_interfaces, $virtual_alias_domains, or $virtual_mailbox_domains. By default,
the Postfix SMTP client returns such mail as undeliverable.
Specify, for example, "best_mx_transport = local" to pass the mail from the SMTP
client to the local(8) delivery agent. You can specify any message delivery "transport"
or "transport:nexthop" that is defined in the master.cf file. See the transport(5) manual
page for the syntax and meaning of "transport" or "transport:nexthop".

However, this feature is expensive because it ties up a Postfix SMTP client process
while the local(8) delivery agent is doing its work. It is more efficient (for Postfix) to
list all hosted domains in a table or database.
biff (default: yes)
Whether or not to use the local biff service. This service sends "new mail" notifications
to users who have requested new mail notification with the UNIX command "biff y".
For compatibility reasons this feature is on by default. On systems with lots of

interactive users, the biff service can be a performance drain. Specify "biff = no" to
disable.
body_checks (default: empty)
Optional lookup tables for content inspection as specified in the body_checks(5) manual
page.
Note: with Postfix versions before 2.0, these rules inspect all content after the primary
message headers.
body_checks_size_limit (default: 51200)
How much text in a message body segment (or attachment, if you prefer to use that
term) is subjected to body_checks inspection. The amount of text is limited to avoid
scanning huge attachments.
bounce_notice_recipient (default: postmaster)
The recipient of postmaster notifications with the message headers of mail that Postfix
did not deliver and of SMTP conversation transcripts of mail that Postfix did not
receive. This feature is enabled with the notify_classes parameter.
bounce_queue_lifetime (default: 5d)
The maximal time a bounce message is queued before it is considered undeliverable. By

default, this is the same as the queue life time for regular mail.

unit is d (days).
Specify 0 when mail delivery should be tried only once.
bounce_service_name (default: bounce)
The name of the bounce(8) service. This service maintains a record of failed delivery
attempts and generates non-delivery notifications.
bounce_size_limit (default: 50000)
The maximal amount of original message text that is sent in a non-delivery notification.
Specify a byte count. If you increase this limit, then you should increase the
mime_nesting_limit value proportionally.
broken_sasl_auth_clients (default: no)
Enable inter-operability with SMTP clients that implement an obsolete version of the
AUTH command (RFC 2554). Examples of such clients are MicroSoft Outlook Express
version 4 and MicroSoft Exchange version 5.0.
Specify "broken_sasl_auth_clients = yes" to have Postfix advertise AUTH support in a

non-standard way.
canonical_classes (default: envelope_sender, envelope_recipient, header_sender,

header_recipient)
What addresses are subject to canonical_maps address mapping. By default,

canonical_maps address mapping is applied to envelope sender and recipient addresses,
and to header sender and header recipient addresses.
Specify one or more of: envelope_sender, envelope_recipient, header_sender,

header_recipient

canonical_maps (default: empty)
Optional address mapping lookup tables for message headers and envelopes. The
mapping is applied to both sender and recipient addresses, in both envelopes and in
headers, as controlled with the canonical_classes parameter. This is typically used to
clean up dirty addresses from legacy mail systems, or to replace login names by
Firstname.Lastname. The table format and lookups are documented in canonical(5).
If you use this feature, run "postmap /etc/postfix/canonical" to build the necessary
DBM or DB file after every change. The changes will become visible after a minute or
so. Use "postfix reload" to eliminate the delay.
Examples:
canonical_maps = dbm:/etc/postfix/canonical
canonical_maps = hash:/etc/postfix/canonical
cleanup_service_name (default: cleanup)
The name of the cleanup(8) service. This service rewrites addresses into the standard
form, and performs canonical(5) address mapping and virtual(5) aliasing.
command_directory (default: see "postconf -d" output)
The location of all postfix administrative commands.
command_execution_directory (default: empty)
The local(8) delivery agent working directory for delivery to external command. Failure
to change directory causes the delivery to be deferred.
The following $name expansions are done on command_execution_directory before the

directory is changed. Expansion happens in the context of the delivery request. The
result of $name expansion is filtered with the character set that is specified with the
execution_directory_expansion_filter parameter.
$user

The recipient's username.

$shell
The recipient's login shell pathname.
$home
The recipient's home directory.
$recipient
The full recipient address.
$extension
The optional recipient address extension.
$domain
The recipient domain.
$local
The entire recipient localpart.
$recipient_delimiter
The system-wide recipient address extension delimiter.
${name?value}
Expands to value when $name is non-empty.
${name:value}
Expands to value when $name is empty.
Instead of $name you can also specify ${name} or $(name).
command_expansion_filter (default: see "postconf -d" output)
Restrict the characters that the local(8) delivery agent allows in $name expansions of
$mailbox_command. Characters outside the allowed set are replaced by underscores.
command_time_limit (default: 1000s)
Time limit for delivery to external commands. This limit is used by the local(8) delivery
agent, and is the default time limit for delivery by the pipe(8) delivery agent.
Note: if you set this time limit to a large value you must update the global ipc_timeout
parameter as well.
config_directory (default: see "postconf -d" output)
The default location of the Postfix main.cf and master.cf configuration files. This can be
overruled via the following mechanisms:

❍ The MAIL_CONFIG environment variable (daemon processes and commands).
❍ The "-c" command-line option (commands only).
With Postfix command that run with set-gid privileges, a config_directory override
requires either root privileges, or it requires that the directory is listed with the
alternate_config_directories parameter in the default main.cf file.
content_filter (default: empty)
The name of a mail delivery transport that filters mail after it is queued.
This parameter uses the same syntax as the right-hand side of a Postfix transport(5)
table. This setting has a lower precedence than a content filter that is specified with an
access(5) table or in a header_checks(5) or body_checks(5) table.
daemon_directory (default: see "postconf -d" output)
The directory with Postfix support programs and daemon programs. These should not
be invoked directly by humans. The directory must be owned by root.
daemon_timeout (default: 18000s)
How much time a Postfix daemon process may take to handle a request before it is
terminated by a built-in watchdog timer.
debug_peer_level (default: 2)
The increment in verbose logging level when a remote client or server matches a pattern
in the debug_peer_list parameter.
debug_peer_list (default: empty)
Optional list of remote client or server hostname or network address patterns that cause
the verbose logging level to increase by the amount specified in $debug_peer_level.

Specify domain names, network/netmask patterns, "/file/name" patterns or "type:table"

lookup tables. The right-hand side result from "type:table" lookups is ignored.
Pattern matching of domain names is controlled by the

parent_domain_matches_subdomains parameter.
Examples:
debug_peer_list = 127.0.0.1
debug_peer_list = some.domain
debugger_command (default: empty)
The external command to execute when a Postfix daemon program is invoked with the -
D option.
Use "command .. & sleep 5" so that the debugger can attach before the process marches
on. If you use an X-based debugger, be sure to set up your XAUTHORITY environment
variable before starting Postfix.
Example:
debugger_command =
PATH=/usr/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id &
sleep 5
default_database_type (default: see "postconf -d" output)
The default database type for use in newaliases(1), postalias(1) and postmap(1)
commands. On many UNIX systems the default type is either dbm or hash. The default
setting is frozen when the Postfix system is built.
Examples:
default_database_type = hash
default_database_type = dbm
default_delivery_slot_cost (default: 5)

How often the Postfix queue manager's scheduler is allowed to preempt delivery of one
message with another.
Each transport maintains a so-called "available delivery slot counter" for each message.
One message can be preempted by another one when the other message can be delivered
using no more delivery slots (i.e., invocations of delivery agents) than the current
message counter has accumulated (or will eventually accumulate - see about slot loans
below). This parameter controls how often is the counter incremented - it happens after
each default_delivery_slot_cost recipients have been delivered.
The cost of 0 is used to disable the preempting scheduling completely. The minimum
value the scheduling algorithm can use is 2 - use it if you want to maximize the message
throughput rate. Although there is no maximum, it doesn't make much sense to use
values above say 50.
The only reason why the value of 2 is not the default is the way this parameter affects
the delivery of mailing-list mail. In the worst case, their delivery can take somewhere
between (cost+1/cost) and (cost/cost-1) times more than if the preemptive scheduler was
disabled. The default value of 5 turns out to provide reasonable message response times
while making sure the mailing-list deliveries are not extended by more than 20-25
percent even in the worst case.
Examples:
default_delivery_slot_cost = 0
default_delivery_slot_cost = 2
default_delivery_slot_discount (default: 50)
The default value for transport-specific _delivery_slot_discount settings.
This parameter speeds up the moment when a message preemption can happen. Instead
of waiting until the full amount of delivery slots required is available, the preemption
can happen when transport_delivery_slot_discount percent of the required amount plus
transport_delivery_slot_loan still remains to be accumulated. Note that the full amount
will still have to be accumulated before another preemption can take place later.
default_delivery_slot_loan (default: 3)
The default value for transport-specific _delivery_slot_loan settings.

This parameter speeds up the moment when a message preemption can happen. Instead
of waiting until the full amount of delivery slots required is available, the preemption
can happen when transport_delivery_slot_discount percent of the required amount plus
transport_delivery_slot_loan still remains to be accumulated. Note that the full amount
will still have to be accumulated before another preemption can take place later.
default_destination_concurrency_limit (default: 20)
The default maximal number of parallel deliveries to the same destination. This is the
default limit for delivery via the lmtp(8), pipe(8), smtp(8) and virtual(8) delivery agents.
default_destination_recipient_limit (default: 50)
The default maximal number of recipients per message delivery. This is the default limit
for delivery via the lmtp(8), pipe(8), smtp(8) and virtual(8) delivery agents.
Setting this parameter to a value of 1 changes the meaning of the corresponding per-
destination concurrency limit from concurrency per domain into concurrency per
recipient.
default_extra_recipient_limit (default: 1000)
The default value for the extra per-transport limit imposed on the number of in-memory
recipients. This extra recipient space is reserved for the cases when the Postfix queue
manager's scheduler preempts one message with another and suddenly needs some extra
recipients slots for the chosen message in order to avoid performance degradation.
default_minimum_delivery_slots (default: 3)
How many recipients a message must have in order to invoke the Postfix queue
manager's scheduling algorithm at all. Messages which would never accumulate at least
this many delivery slots (subject to slot cost parameter as well) are never preempted.
default_privs (default: nobody)
The default rights used by the local(8) delivery agent for delivery to external file or
command. These rights are used when delivery is requested from an aliases(5) file that
is owned by root, or when delivery is done on behalf of root. DO NOT SPECIFY A
PRIVILEGED USER OR THE POSTFIX OWNER.

default_process_limit (default: 100)
The default maximal number of Postfix child processes that provide a given service.
This limit can be overruled for specific services in the master.cf file.
default_rbl_reply (default: see "postconf -d" output)
The default SMTP server response template for a request that is rejected by an RBL-
based restriction. This template can be overruled by specific entries in the optional
rbl_reply_maps lookup table.
The template is subject to exactly one level of $name substitution:
$client
The client hostname and IP address, formatted as name[address].
$client_address
The client IP address.
$client_name
The client hostname or "unknown".
$helo_name
The hostname given in HELO or EHLO command or empty string.
$rbl_class
The blacklisted entity type: Client host, Helo command, Sender address, or
Recipient address.
$rbl_code
The numerical SMTP response code, as specified with the maps_rbl_reject_code
configuration parameter.
$rbl_domain
The RBL domain where $rbl_what is blacklisted.
$rbl_reason
The reason why $rbl_what is blacklisted, or an empty string.
$rbl_what
The entity that is blacklisted (an IP address, a hostname, a domain name, or an
email address whose domain was blacklisted).
$recipient
The recipient address or <> in case of the null address.
$recipient_domain
The recipient domain or empty string.
$recipient_name
The recipient address localpart or <> in case of null address.

$sender
The sender address or <> in case of the null address.
$sender_domain
The sender domain or empty string.
$sender_name
The sender address localpart or <> in case of the null address.
${name?text}
Expands to `text' if $name is not empty.
${name:text}
Expands to `text' if $name is empty.
default_recipient_limit (default: 10000)
The default per-transport upper limit on the number of in-memory recipients. These
limits take priority over the global qmgr_message_recipient_limit after the message has
been assigned to the respective transports. See also default_extra_recipient_limit and
qmgr_message_recipient_minimum.
default_transport (default: smtp)
The default mail delivery transport for domains that do not match $mydestination,
$inet_interfaces, $proxy_interfaces, $virtual_alias_domains,
$virtual_mailbox_domains, or $relay_domains. This information can be overruled with
the transport(5) table.
Specify a string of the form transport:nexthop, where transport is the name of a mail
delivery transport defined in master.cf. The :nexthop part is optional. For more details
see the transport(5) manual page.
Example:
default_transport = uucp:relayhostname
default_verp_delimiters (default: +=)
The two default VERP delimiter characters. These are used when no explicit delimiters
are specified with the SMTP XVERP command or with the "sendmail -V" command-
line option. Specify characters that are allowed by the verp_delimiter_filter setting.

defer_code (default: 450)
The numerical Postfix SMTP server response code when a remote SMTP client request
is rejected by the "defer" restriction.
defer_service_name (default: defer)
The name of the defer(8) service. This service maintains a record of failed delivery
attempts and generates non-delivery notifications.
defer_transports (default: empty)
The names of message delivery transports that should not be delivered to unless
someone issues "sendmail -q" or equivalent. Specify zero or more names of mail
delivery transports names that appear in the first field of master.cf.
Example:
defer_transports = smtp
delay_notice_recipient (default: postmaster)
The recipient of postmaster notifications with the message headers of mail that cannot
be delivered within $delay_warning_time time units.
This feature is enabled with the delay_warning_time parameter.
delay_warning_time (default: 0h)
The time after which the sender receives the message headers of mail that is still
queued.
To enable this feature, specify a non-zero integral value.

unit is h (hours).
deliver_lock_attempts (default: 20)
The maximal number of attempts to acquire an exclusive lock on a mailbox file or

bounce(8) logfile.
deliver_lock_delay (default: 1s)
The time between attempts to acquire an exclusive lock on a mailbox file or bounce(8)
logfile.
disable_dns_lookups (default: no)
Disable DNS lookups in the Postfix SMTP and LMTP clients. When disabled, hosts are
looked up with the gethostbyname() system library routine which normally also looks
in /etc/hosts.
DNS lookups are enabled by default.
disable_mime_input_processing (default: no)
Turn off MIME processing while receiving mail. This means that no special treatment is
given to Content-Type: message headers, and that all text after the initial message
headers is considered to be part of the message body.
Mime input processing is enabled by default, and is needed in order to recognize MIME
headers in message content.
disable_mime_output_conversion (default: no)
Disable the conversion of 8BITMIME format to 7BIT format. Mime output conversion
is needed when the destination does not advertise 8BITMIME support.

disable_verp_bounces (default: no)
Disable sending one bounce report per recipient.
The default, one per recipient, is what ezmlm needs.
disable_vrfy_command (default: no)
Disable the SMTP VRFY command. This stops some techniques used to harvest email
addresses.
Example:
disable_vrfy_command = no
dont_remove (default: 0)
Don't remove queue files and save them to the "saved" mail queue. This is a debugging
aid. To inspect the envelope information and content of a Postfix queue file, use the
postcat(1) command.
double_bounce_sender (default: double-bounce)
The sender address of postmaster notifications that are generated by the mail system.
All mail to this address is silently discarded, in order to terminate mail bounce loops.
duplicate_filter_limit (default: 1000)
The maximal number of addresses remembered by the address duplicate filter for aliases
(5) or virtual(5) alias expansion, or for showq(8) queue displays.
empty_address_recipient (default: MAILER-DAEMON)
The recipient of mail addressed to the null address. Postfix does not accept such
addresses in SMTP commands, but they may still be created locally as the result of
configuration or software error.

enable_errors_to (default: no)
Report mail delivery errors to the address specified with the non-standard Errors-To:
message header, instead of the envelope sender address. This support is disabled by
default with Postfix 2.1 and later, and is always turned on with older Postfix versions.
enable_original_recipient (default: yes)
Enable support for the X-Original-To message header. This header is needed for multi-
recipient mailboxes.
When this parameter is set to yes, the cleanup(8) daemon performs duplicate
elimination on distinct pairs of (original recipient, rewritten recipient), and generates
non-empty original recipient queue file records.
When this parameter is set to no, the cleanup(8) daemon performs duplicate elimination
on the rewritten recipient address only, and generates empty original recipient queue file
records.
This feature is available in Postfix 2.1 and later. With Postfix 2.0, support for the X-
Original-To message header is always turned on. Postfix versions before 2.0 have no
support for the X-Original-To message header.
error_notice_recipient (default: postmaster)
The recipient of postmaster notifications about mail delivery problems that are caused
by policy, resource, software or protocol errors. These notifications are enabled with the
notify_classes parameter.
error_service_name (default: error)
The name of the error(8) pseudo delivery agent. This service always returns mail as
undeliverable.
execution_directory_expansion_filter (default: see "postconf -d" output)

$command_execution_directory. Characters outside the allowed set are replaced by

underscores.
expand_owner_alias (default: no)
When delivering to an alias "aliasname" that has an "owner-aliasname" companion

alias, set the envelope sender address to the expansion of the "owner-aliasname" alias.
Normally, Postfix sets the envelope sender address to the name of the "owner-
aliasname" alias.
export_environment (default: see "postconf -d" output)
The list of environment variables that a Postfix process will export to non-Postfix
processes. The TZ variable is needed for sane time keeping on System-V-ish systems.
Specify a list of names and/or name=value pairs, separated by whitespace or comma.

The name=value form is supported with Postfix 2.1 and later.
Example:
export_environment = TZ PATH=/bin:/usr/bin
extract_recipient_limit (default: 10240)
The maximal number of recipient addresses that Postfix will extract from message
headers when mail is submitted with "sendmail -t".
This feature was removed in Postfix 2.1.
fallback_relay (default: empty)
Optional list of relay hosts for SMTP destinations that can't be found or that are
unreachable.
By default, mail is returned to the sender when a destination is not found, and delivery
is deferred if a destination is unreachable.
The fallback relays must be SMTP destinations. Specify a domain, host, host:port,

[host]:port, [address] or [address]:port; the form [host] turns off MX lookups. If you
specify multiple SMTP destinations, Postfix will try them in the specified order.
fallback_transport (default: empty)
Optional message delivery transport that the local(8) delivery agent should use for
names that are not found in the aliases(5) database or in the UNIX passwd database.
fast_flush_domains (default: $relay_domains)
Optional list of destinations that are eligible for per-destination logfiles with mail that is
queued to those destinations.
By default, Postfix maintains "fast flush" logfiles only for destinations that the Postfix
SMTP server is willing to relay to (i.e. the default is: "fast_flush_domains =
$relay_domains"; see the relay_domains parameter in the postconf(5) manual).
Specify a list of hosts or domains, "/file/name" patterns or "type:table" lookup tables,

separated by commas and/or whitespace. Continue long lines by starting the next line
with whitespace. A "/file/name" pattern is replaced by its contents; a "type:table" lookup
table is matched when the domain or its parent domain appears as lookup key.
Specify "fast_flush_domains =" to disable the feature altogether.
fast_flush_purge_time (default: 7d)
The time after which an empty per-destination "fast flush" logfile is deleted.
You can specify the time as a number, or as a number followed by a letter that indicates
the time unit: s=seconds, m=minutes, h=hours, d=days, w=weeks. The default time unit
is days.
fast_flush_refresh_time (default: 12h)
The time after which a non-empty but unread per-destination "fast flush" logfile needs
to be refreshed. The contents of a logfile are refreshed by requesting delivery of all
messages listed in the logfile.
You can specify the time as a number, or as a number followed by a letter that indicates
the time unit: s=seconds, m=minutes, h=hours, d=days, w=weeks. The default time unit

is hours.
fault_injection_code (default: 0)
Force specific internal tests to fail, to test the handling of errors that are difficult to
reproduce otherwise.
flush_service_name (default: flush)
The name of the flush(8) service. This service maintains per-destination logfiles with
the queue file names of mail that is queued for those destinations.
fork_attempts (default: 5)
The maximal number of attempts to fork() a child process.
fork_delay (default: 1s)
The delay between attempts to fork() a child process.
forward_expansion_filter (default: see "postconf -d" output)
$forward_path. Characters outside the allowed set are replaced by underscores.
forward_path (default: see "postconf -d" output)
The local(8) delivery agent search list for finding a .forward file with user-specified
delivery methods. The first file that is found is used.
The following $name expansions are done on forward_path before the search actually
happens. The result of $name expansion is filtered with the character set that is
specified with the forward_expansion_filter parameter.
$user


$shell
The recipient's login shell pathname.
$home
$recipient
$extension
$domain
$local
The entire recipient localpart.
${name?value}
Expands to value when $name is non-empty.
${name:value}
Expands to value when $name is empty.
Examples:
forward_path = /var/forward/$user
forward_path =
/var/forward/$user/.forward$recipient_delimiter
$extension,
/var/forward/$user/.forward
hash_queue_depth (default: 1)
The number of subdirectory levels for queue directories listed with the
hash_queue_names parameter.
After changing the hash_queue_names or hash_queue_depth parameter, execute the

command "postfix reload".
hash_queue_names (default: see "postconf -d" output)
The names of queue directories that are split across multiple subdirectory levels.

After changing the hash_queue_names or hash_queue_depth parameter, execute the

command "postfix reload".
header_address_token_limit (default: 10240)
The maximal number of address tokens are allowed in an address message header.
Information that exceeds the limit is discarded. The limit is enforced by the cleanup(8)
server.
header_checks (default: empty)
Optional lookup tables for content inspection of primary non-MIME message headers,
as specified in the header_checks(5) manual page.
header_size_limit (default: 102400)
The maximal amount of memory in bytes for storing a message header. If a header is
larger, the excess is discarded. The limit is enforced by the cleanup(8) server.
helpful_warnings (default: yes)
Log warnings about problematic configuration settings, and provide helpful

suggestions.
home_mailbox (default: empty)
Optional pathname of a mailbox file relative to a local(8) user's home directory.
Specify a pathname ending "/" for qmail-style delivery.
The precedence of local(8) delivery features from high to low is: aliases, .forward files,
mailbox_transport, mailbox_command_maps, mailbox_command, home_mailbox,
mail_spool_directory, fallback_transport and luser_relay.
Examples:

home_mailbox = Mailbox
home_mailbox = Maildir/
hopcount_limit (default: 50)
The maximal number of Received: message headers that is allowed in the primary
message headers. A message that exceeds the limit is bounced, in order to stop a mailer
loop.
html_directory (default: see "postconf -d" output)
The location of Postfix HTML files that describe how to build, configure or operate a
specific Postfix subsystem or feature.
ignore_mx_lookup_error (default: no)
Ignore DNS MX lookups that produce no response. By default, the Postfix SMTP client
defers delivery and tries again after some delay. This behavior is required by the SMTP
standard.
Specify "ignore_mx_lookup_error = yes" to force a DNS A record lookup instead.

This violates the SMTP standard and can result in mis-delivery of mail.
import_environment (default: see "postconf -d" output)
The list of environment parameters that a Postfix process will import from a non-Postfix
parent process. Examples of relevant parameters:
TZ
Needed for sane time keeping on most System-V-ish systems.
DISPLAY
Needed for debugging Postfix daemons with an X-windows debugger.
XAUTHORITY
Needed for debugging Postfix daemons with an X-windows debugger.
MAIL_CONFIG
Needed to make "postfix -c" work.
Specify a list of names and/or name=value pairs, separated by whitespace or comma.

The name=value form is supported with Postfix 2.1 and later.
in_flow_delay (default: 1s)

Time to pause before accepting a new message, when the message arrival rate exceeds
the message delivery rate. This feature is turned on by default (it's disabled on SCO
UNIX due to an SCO bug).
With the default 100 SMTP server process limit, "in_flow_delay = 1s" limits the mail
inflow to 100 messages per second above the number of messages delivered per second.
Specify 0 to disable the feature. Valid delays are 0..10.
inet_interfaces (default: all)
The network interface addresses that this mail system receives mail on. By default, the
software claims all active interfaces on the machine. The parameter also controls
delivery of mail to user@[ip.address].
When inet_interfaces consists of just one IP address that is not a loopback (net 127)
address, the Postfix SMTP client will use this address as the IP source address for
outbound mail.
On a multi-homed firewall with separate Postfix instances listening on the "inside" and
"outside" interfaces, this can prevent each instance from being able to reach servers on
the "other side" of the firewall. Setting smtp_bind_address to 0.0.0.0 avoids the
potential problem.
A better solution is to leave inet_interfaces at the default value and instead use explicit
IP addresses in master.cf. This preserves SMTP loop detection, by ensuring that each
side of the firewall knows that the other IP address is still the same host. Setting
$inet_interfaces to a single IP address is primarily useful with virtual hosting of
domains on secondary IP addresses, when each IP address serves a different domain
(and has a different $myhostname setting).
See also the proxy_interfaces parameter, for network addresses that are forwarded to us
by way of a proxy or address translator.
Note: you need to stop and start Postfix when this parameter changes.
initial_destination_concurrency (default: 5)
The initial per-destination concurrency level for parallel delivery to the same

destination. This limit applies to delivery via smtp(8), and via the pipe(8) and virtual(8)
delivery agents.
Warning: with concurrency of 1, one bad message can be enough to block all mail to a
site.
invalid_hostname_reject_code (default: 501)
The numerical Postfix SMTP server response code when the client HELO or EHLO
command parameter is rejected by the reject_invalid_hostname restriction.
ipc_idle (default: 100s)
The time after which a client closes an idle internal communication channel. The
purpose is to allow servers to terminate voluntarily after they become idle. This is used,
for example, by the address resolving and rewriting clients.
ipc_timeout (default: 3600s)
The time limit for sending or receiving information over an internal communication
channel. The purpose is to break out of deadlock situations. If the time limit is exceeded
the software aborts with a fatal error.
ipc_ttl (default: 1000s)
The time after which a client closes an active internal communication channel. The
purpose is to allow servers to terminate voluntarily after reaching their client limit. This
is used, for example, by the address resolving and rewriting clients.

line_length_limit (default: 2048)
Upon input, long lines are chopped up into pieces of at most this length; upon delivery,
long lines are reconstructed.
lmtp_cache_connection (default: yes)
Keep Postfix LMTP client connections open for up to $max_idle seconds. When the
LMTP client receives a request for the same connection the connection is reused.
The effectiveness of cached connections will be determined by the number of LMTP

servers in use, and the concurrency limit specified for the LMTP client. Cached
connections are closed under any of the following conditions:
❍ The LMTP client idle time limit is reached. This limit is specified with the
Postfix max_idle configuration parameter.
❍ A delivery request specifies a different destination than the one currently cached.
❍ The per-process limit on the number of delivery requests is reached. This limit is
specified with the Postfix max_use configuration parameter.
❍ Upon the onset of another delivery request, the LMTP server associated with the
current session does not respond to the RSET command.
Most of these limitations will be removed after Postfix implements a connection cache
that is shared among multiple LMTP client programs.
lmtp_connect_timeout (default: 0s)
The LMTP client time limit for completing a TCP connection, or zero (use the operating
system built-in time limit). When no connection can be made within the deadline, the
LMTP client tries the next address on the mail exchanger list.
Example:
lmtp_connect_timeout = 30s

lmtp_data_done_timeout (default: 600s)
The LMTP client time limit for sending the LMTP ".", and for receiving the server
response. When no response is received within the deadline, a warning is logged that the
mail may be delivered multiple times.
lmtp_data_init_timeout (default: 120s)
The LMTP client time limit for sending the LMTP DATA command, and for receiving
the server response.
lmtp_data_xfer_timeout (default: 180s)
The LMTP client time limit for sending the LMTP message content. When the
connection stalls for more than $lmtp_data_xfer_timeout the LMTP client terminates
the transfer.
lmtp_destination_concurrency_limit (default: $default_destination_concurrency_limit)
The maximal number of parallel deliveries to the same destination via the lmtp message
delivery transport. This limit is enforced by the queue manager. The message delivery
transport name is the first field in the entry in the master.cf file.
lmtp_destination_recipient_limit (default: $default_destination_recipient_limit)
The maximal number of recipients per delivery via the lmtp message delivery transport.
This limit is enforced by the queue manager. The message delivery transport name is
the first field in the entry in the master.cf file.
Setting this parameter to a value of 1 changes the meaning of

lmtp_destination_concurrency_limit from concurrency per domain into concurrency per

recipient.
lmtp_lhlo_timeout (default: 300s)
The LMTP client time limit for receiving the LMTP greeting banner. When the server
drops the connection without sending a greeting banner, or when it sends no greeting
banner within the deadline, the LMTP client tries the next address on the mail
exchanger list.
lmtp_mail_timeout (default: 300s)
The LMTP client time limit for sending the MAIL FROM command, and for receiving
lmtp_quit_timeout (default: 300s)
The LMTP client time limit for sending the QUIT command, and for receiving the
server response.
lmtp_rcpt_timeout (default: 300s)
The LMTP client time limit for sending the RCPT TO command, and for receiving the
server response.
lmtp_rset_timeout (default: 20s)
The LMTP client time limit for sending the RSET command, and for receiving the
server response. The LMTP client sends RSET in order to finish a recipient address
probe, or to verify that a cached connection is still alive.

lmtp_sasl_auth_enable (default: no)
Enable SASL authentication in the Postfix LMTP client.
lmtp_sasl_password_maps (default: empty)
Optional LMTP client lookup tables with one username:password entry per host or
domain. If a remote host or domain has no username:password entry, then the Postfix
LMTP client will not attempt to authenticate to the remote host.
lmtp_sasl_security_options (default: noplaintext, noanonymous)
What authentication mechanisms the Postfix LMTP client is allowed to use. The list of
available authentication mechanisms is system dependent.
noplaintext
Disallow authentication methods that use plaintext passwords.
noactive
Disallow authentication methods that are vulnerable to non-dictionary active
attacks.
nodictionary
Disallow authentication methods that are vulnerable to passive dictionary attack.
noanonymous
Disallow anonymous logins.
Example:
lmtp_sasl_security_options = noplaintext
lmtp_send_xforward_command (default: no)
Send an XFORWARD command to the LMTP server when the LMTP LHLO server
response announces XFORWARD support. This allows an lmtp(8) delivery agent, used
for content filter message injection, to forward the name, address, protocol and HELO
name of the original client to the content filter and downstream queuing LMTP server.
Before you change the value to yes, it is best to make sure that your content filter
supports this command.

lmtp_skip_quit_response (default: no)
Wait for the response to the LMTP QUIT command.
lmtp_tcp_port (default: 24)
The default TCP port that the Postfix LMTP client connects to.
lmtp_xforward_timeout (default: 300s)
The LMTP client time limit for sending the XFORWARD command, and for receiving
In case of problems the client does NOT try the next address on the mail exchanger list.
local_command_shell (default: empty)
Optional shell program for local(8) delivery to non-Postfix command. By default, non-
Postfix commands are executed directly; commands are given to given to /bin/sh only
when they contain shell meta characters or shell built-in commands.
"sendmail's restricted shell" (smrsh) is what most people will use in order to restrict
what programs can be run from e.g. .forward files (smrsh is part of the Sendmail
distribution).
Note: when a shell program is specified, it is invoked even when the command contains
no shell built-in commands or meta characters.
Example:
local_command_shell = /some/where/smrsh -c

local_destination_concurrency_limit (default: 2)
The maximal number of parallel deliveries via the local mail delivery transport to the
same recipient (when "local_destination_recipient_limit = 1") or the maximal number of
parallel deliveries to the same local domain (when "local_destination_recipient_limit >
1"). This limit is enforced by the queue manager. The message delivery transport name
is the first field in the entry in the master.cf file.
A low limit of 2 is recommended, just in case someone has an expensive shell command
in a .forward file or in an alias (e.g., a mailing list manager). You don't want to run lots
of those at the same time.
local_destination_recipient_limit (default: 1)
The maximal number of recipients per message delivery via the local mail delivery
transport. This limit is enforced by the queue manager. The message delivery transport
name is the first field in the entry in the master.cf file.
Setting this parameter to a value > 1 changes the meaning of

local_destination_concurrency_limit from concurrency per recipient into concurrency
per domain.
local_header_rewrite_clients (default: see "postconf -d" output)
Append the domain name in $myorigin or $mydomain to message header addresses

from these clients only; either don't rewrite message headers from other clients at all, or
append the domain specified with the remote_header_rewrite_domain parameter.
Specify a list of zero or more of the following:
permit_mynetworks
Append the domain name in $myorigin or $mydomain when the client IP
address matches any network or network address listed in $mynetworks. This is
enabled by default.
permit_sasl_authenticated
Append the domain name in $myorigin or $mydomain when the client is
successfully authenticated via the RFC 2554 (AUTH) protocol. This is enabled
by default.
permit_tls_clientcerts
Append the domain name in $myorigin or $mydomain when the client TLS

certificate is successfully verified, and the client certificate fingerprint is listed in

$relay_clientcerts. This is enabled by default.
permit_tls_all_clientcerts
Append the domain name in $myorigin or $mydomain when the client TLS
certificate is successfully verified, regardless of whether it is listed on the server,
and regardless of the certifying authority.
check_address_map type:table
type:table
Append the domain name in $myorigin or $mydomain when the client IP
address matches the specified lookup table. The lookup result is ignored, and no
subnet lookup is done. This is suitable for pop-before-smtp lookup tables.
Examples:
The backwards compatible setting: always rewrite message headers, and always append
my own domain to incomplete header addresses.
local_header_rewrite_clients = static:all
The purist setting: rewrite headers only in mail from Postfix sendmail and in SMTP
mail from this machine.
mynetworks_style = host
local_header_rewrite_clients = permit_mynetworks
The default setting: rewrite headers and append my own domain only with mail from
Postfix sendmail and from local or authorized SMTP clients.
local_header_rewrite_clients = permit_mynetworks,
permit_sasl_authenticated permit_tls_clientcerts
The ISP setting: include clients that are pop-before-smtp authenticated.
local_header_rewrite_clients = permit_mynetworks,
permit_sasl_authenticated permit_tls_clientcerts
check_address_map hash:/etc/postfix/pop-before-smtp
local_recipient_maps (default: proxy:unix:passwd.byname $alias_maps)

Lookup tables with all names or addresses of local recipients: a recipient address is local
when its domain matches $mydestination, $inet_interfaces or $proxy_interfaces.
Specify @domain as a wild-card for domains that do not have a valid recipient list.
Technically, tables listed with $local_recipient_maps are used as lists: Postfix needs to
know only if a lookup string is found or not, but it does not use the result from table
lookup.
If this parameter is non-empty (the default), then the Postfix SMTP server will reject
mail for unknown local users.
To turn off local recipient checking in the Postfix SMTP server, specify
"local_recipient_maps =" (i.e. empty).
The default setting assumes that you use the default Postfix local delivery agent for
local delivery. You need to update the local_recipient_maps setting if:
❍ You redefine the local delivery agent in master.cf.

❍ You redefine the "local_transport" setting in main.cf.
❍ You use the "luser_relay", "mailbox_transport", or "fallback_transport" feature
of the Postfix local(8) delivery agent.
Details are described in the LOCAL_RECIPIENT_README file.
Beware: if the Postfix SMTP server runs chrooted, you need to access the passwd file
via the proxymap(8) service, in order to overcome chroot access restrictions. The
alternative, maintaining a copy of the system password file in the chroot jail is not
practical.
Examples:
local_recipient_maps =
local_transport (default: local:$myhostname)
The default mail delivery transport for domains that match $mydestination,
$inet_interfaces or $proxy_interfaces. This information can be overruled with the
transport(5) table.
By default, local mail is delivered to the transport called "local", which is just the name

of a service that is defined the master.cf file.
Beware: if you override the default local delivery agent then you need to review the
LOCAL_RECIPIENT_README document, otherwise the SMTP server may reject
mail for local recipients.
luser_relay (default: empty)
Optional catch-all destination for unknown local(8) recipients. By default, mail for
unknown recipients in domains that match $mydestination, $inet_interfaces or
$proxy_interfaces is returned as undeliverable.
The following $name expansions are done on luser_relay:
$domain
$extension
The recipient address extension.
$home
$local
The entire recipient address localpart.
$recipient
$shell
The recipient's login shell.
$user
The recipient username.
${name?value}
Expands to value when $name has a non-empty value.
${name:value}
Expands to value when $name has an empty value.

Note: luser_relay works only for the Postfix local(8) delivery agent.
NOTE: if you use this feature for accounts not in the UNIX password file, then you
must specify "local_recipient_maps =" (i.e. empty) in the main.cf file, otherwise the
Postfix SMTP server will reject mail for non-UNIX accounts with "User unknown in
local recipient table".
Examples:
luser_relay = $user@other.host
luser_relay = $local@other.host
luser_relay = admin+$local
mail_name (default: Postfix)
The mail system name that is displayed in Received: headers, in the SMTP greeting
banner, and in bounced mail.
mail_owner (default: postfix)
The UNIX system account that owns the Postfix queue and most Postfix daemon
processes. Specify the name of a user account that does not share a group with other
accounts and that owns no other files or processes on the system. In particular, don't
specify nobody or daemon. PLEASE USE A DEDICATED USER ID AND GROUP
ID.
mail_release_date (default: see "postconf -d" output)
The Postfix release date, in "YYYYMMDD" format.
mail_spool_directory (default: see "postconf -d" output)
The directory where local(8) UNIX-style mailboxes are kept. The default setting
depends on the system type. Specify a name ending in / for maildir-style delivery.
Note: maildir delivery is done with the privileges of the recipient. If you use the
mail_spool_directory setting for maildir style delivery, then you must create the top-
level maildir directory in advance. Postfix will not create it.
Examples:

mail_spool_directory = /var/mail
mail_spool_directory = /var/spool/mail
mail_version (default: see "postconf -d" output)
The version of the mail system. Stable releases are named major.minor.patchlevel.
Experimental releases also include the release date. The version string can be used in,
for example, the SMTP greeting banner.
mailbox_command (default: empty)
Optional external command that the local(8) delivery agent should use for mailbox
delivery. The command is run with the user ID and the primary group ID privileges of
the recipient. Exception: command delivery for root executes with $default_privs
privileges. This is not a problem, because 1) mail for root should always be aliased to a
real user and 2) don't log in as root, use "su" instead.
The following environment variables are exported to the command:
CLIENT_ADDRESS
Remote client network address. Available in Postfix 2.2 and later.
CLIENT_HELO
Remote client EHLO command parameter. Available in Postfix 2.2 and later.
CLIENT_HOSTNAME
Remote client hostname. Available in Postfix 2.2 and later.
CLIENT_PROTOCOL
Remote client protocol. Available in Postfix 2.2 and later.
DOMAIN
The domain part of the recipient address.
EXTENSION
The optional address extension.
HOME
The recipient home directory.
LOCAL
The recipient address localpart.
LOGNAME
RECIPIENT
SASL_METHOD

SASL authentication method specified in the remote client AUTH command.

Available in Postfix 2.2 and later.
SASL_SENDER
SASL sender address specified in the remote client MAIL FROM command.
Available in Postfix 2.2 and later.
SASL_USER
SASL username specified in the remote client AUTH command. Available in
Postfix 2.2 and later.
SENDER
The full sender address.
SHELL
The recipient's login shell.
USER
The recipient username.
Unlike other Postfix configuration parameters, the mailbox_command parameter is not

subjected to $name substitutions. This is to make it easier to specify shell syntax (see
example below).
If you can, avoid shell meta characters because they will force Postfix to run an
expensive shell process. If you're delivering via Procmail then running a shell won't
make a noticeable difference in the total cost.
Note: if you use the mailbox_command feature to deliver mail system-wide, you must
set up an alias that forwards mail for root to a real user.
Examples:
mailbox_command = /some/where/procmail
mailbox_command = /some/where/procmail -a "$EXTENSION"
mailbox_command = /some/where/maildrop -d "$USER"
-f "$SENDER" "$EXTENSION"
mailbox_command_maps (default: empty)
Optional lookup tables with per-recipient external commands to use for local(8)

mailbox delivery. Behavior is as with mailbox_command.
mailbox_delivery_lock (default: see "postconf -d" output)
How to lock a UNIX-style local(8) mailbox before attempting delivery. For a list of
available file locking methods, use the "postconf -l" command.
This setting is ignored with maildir style delivery, because such deliveries are safe
without explicit locks.
Note: The dotlock method requires that the recipient UID or GID has write access to
the parent directory of the mailbox file.
Note: the default setting of this parameter is system dependent.
mailbox_size_limit (default: 51200000)
The maximal size of any local(8) individual mailbox or maildir file, or zero (no limit).
In fact, this limits the size of any file that is written to upon local delivery, including
files written by external commands that are executed by the local(8) delivery agent.
This limit must not be smaller than the message size limit.
mailbox_transport (default: empty)
Optional message delivery transport that the local(8) delivery agent should use for
mailbox delivery to all local recipients, whether or not they are found in the UNIX
passwd database.
mailq_path (default: see "postconf -d" output)

Sendmail compatibility feature that specifies where the Postfix mailq(1) command is
installed. This command can be used to list the Postfix mail queue.
manpage_directory (default: see "postconf -d" output)
Where the Postfix manual pages are installed.
maps_rbl_domains (default: empty)
Obsolete feature: use the reject_rbl_client feature instead.
maps_rbl_reject_code (default: 554)
is blocked by the reject_rbl_client, reject_rhsbl_client, reject_rhsbl_sender or
reject_rhsbl_recipient restriction.
masquerade_classes (default: envelope_sender, header_sender, header_recipient)
What addresses are subject to address masquerading.
By default, address masquerading is limited to envelope sender addresses, and to header

sender and header recipient addresses. This allows you to use address masquerading on
a mail gateway while still being able to forward mail to users on individual machines.
Specify zero or more of: envelope_sender, envelope_recipient, header_sender,

header_recipient
masquerade_domains (default: empty)
Optional list of domains whose subdomain structure will be stripped off in email
addresses.
The list is processed left to right, and processing stops at the first match. Thus,
masquerade_domains = foo.example.com example.com
strips "user@any.thing.foo.example.com" to "user@foo.example.com", but strips

"user@any.thing.else.example.com" to "user@example.com".
A domain name prefixed with ! means do not masquerade this domain or its
subdomains. Thus,
masquerade_domains = !foo.example.com example.com
does not change "user@any.thing.foo.example.com" or "user@foo.example.com", but

strips "user@any.thing.else.example.com" to "user@example.com".
Example:
masquerade_domains = $mydomain
masquerade_exceptions (default: empty)
Optional list of user names that are not subjected to address masquerading, even when
their address matches $masquerade_domains.
By default, address masquerading makes no exceptions.

with whitespace.
Examples:
masquerade_exceptions = root, mailer-daemon

masquerade_exceptions = root
max_idle (default: 100s)
The maximum amount of time that an idle Postfix daemon process waits for the next
service request before exiting. This parameter is ignored by the Postfix queue manager.

max_use (default: 100)
The maximal number of connection requests before a Postfix daemon process

terminates. This parameter is ignored by the Postfix queue manager and by other long-
lived Postfix daemon processes.
maximal_backoff_time (default: 4000s)
The maximal time between attempts to deliver a deferred message.
maximal_queue_lifetime (default: 5d)
The maximal time a message is queued before it is sent back as undeliverable.
unit is d (days).
Specify 0 when mail delivery should be tried only once.
message_size_limit (default: 10240000)
The maximal size in bytes of a message, including envelope information.
mime_boundary_length_limit (default: 2048)
The maximal length of MIME multipart boundary strings. The MIME processor is
unable to distinguish between boundary strings that do not differ in the first
$mime_boundary_length_limit characters.
mime_header_checks (default: $header_checks)
Optional lookup tables for content inspection of MIME related message headers, as
described in the header_checks(5) manual page.

mime_nesting_limit (default: 100)
The maximal recursion level that the MIME processor will handle. Postfix refuses mail
that is nested deeper than the specified limit.
minimal_backoff_time (default: 1000s)
The minimal time between attempts to deliver a deferred message. This parameter also
limits the time an unreachable destination is kept in the short-term, in-memory,
destination status cache.
multi_recipient_bounce_reject_code (default: 550)
is blocked by the reject_multi_recipient_bounce restriction.
mydestination (default: $myhostname, localhost.$mydomain, localhost)
The list of domains that are delivered via the $local_transport mail delivery transport.
By default this is the Postfix local(8) delivery agent which looks up all recipients in /etc/
passwd and /etc/aliases. The SMTP server validates recipient addresses with
$local_recipient_maps and rejects non-existent recipients. See also the local domain
class in the ADDRESS_CLASS_README file.
The default mydestination value specifies names for the local machine only. On a mail
domain gateway, you should also include $mydomain.
The $local_transport delivery method is also selected for mail addressed to user@[the.

net.work.address] of the mail system (the IP addresses specified with the inet_interfaces
and proxy_interfaces parameters).
Warnings:
❍ Do not specify the names of virtual domains - those domains are specified
elsewhere. See VIRTUAL_README for more information.
❍ Do not specify the names of domains that this machine is backup MX host for.
See STANDARD_CONFIGURATION_README for how to set up backup MX
hosts.
❍ By default, the Postfix SMTP server rejects mail for recipients not listed with the
local_recipient_maps parameter. See the postconf(5) manual for a description of
the local_recipient_maps and unknown_local_recipient_reject_code parameters.
Specify a list of host or domain names, "/file/name" or "type:table" patterns, separated

by commas and/or whitespace. A "/file/name" pattern is replaced by its contents; a "type:
table" lookup table is matched when a name matches a lookup key (the lookup result is
ignored). Continue long lines by starting the next line with whitespace.
Examples:
mydestination = $myhostname, localhost.$mydomain $mydomain

mydestination = $myhostname, localhost.$mydomain www.
$mydomain, ftp.$mydomain
mydomain (default: see "postconf -d" output)
The internet domain name of this mail system. The default is to use $myhostname
minus the first component. $mydomain is used as a default value for many other
configuration parameters.
Example:
mydomain = domain.tld
myhostname (default: see "postconf -d" output)

The internet hostname of this mail system. The default is to use the fully-qualified
domain name from gethostname(). $myhostname is used as a default value for many
other configuration parameters.
Example:
myhostname = host.domain.tld
mynetworks (default: see "postconf -d" output)
The list of "trusted" SMTP clients that have more privileges than "strangers".
In particular, "trusted" SMTP clients are allowed to relay mail through Postfix. See the
smtpd_recipient_restrictions parameter description in the postconf(5) manual.
You can specify the list of "trusted" network addresses by hand or you can let Postfix do
it for you (which is the default). See the description of the mynetworks_style parameter
for more information.
If you specify the mynetworks list by hand, Postfix ignores the mynetworks_style
setting.
Specify a list of network addresses or network/netmask patterns, separated by commas

and/or whitespace. Continue long lines by starting the next line with whitespace.
The netmask specifies the number of bits in the network part of a host address. You can
also specify "/file/name" or "type:table" patterns. A "/file/name" pattern is replaced by
its contents; a "type:table" lookup table is matched when a table entry matches a lookup
string (the lookup result is ignored).
The list is matched left to right, and the search stops on the first match. Specify "!
pattern" to exclude an address or network block from the list.
Examples:
mynetworks = 168.100.189.0/28, 127.0.0.0/8

mynetworks = !192.168.0.1, 192.168.0.0/28
mynetworks = $config_directory/mynetworks
mynetworks = hash:/etc/postfix/network_table

mynetworks_style (default: subnet)
The method to generate the default value for the mynetworks parameter. This is the list
of trusted networks for relay access control etc.
❍ Specify "mynetworks_style = host" when Postfix should "trust" only the local
machine.
❍ Specify "mynetworks_style = subnet" when Postfix should "trust" SMTP clients

in the same IP subnetworks as the local machine. On Linux, this works correctly
only with interfaces specified with the "ifconfig" command.
❍ Specify "mynetworks_style = class" when Postfix should "trust" SMTP clients in

the same IP class A/B/C networks as the local machine. Don't do this with a
dialup site - it would cause Postfix to "trust" your entire provider's network.
Instead, specify an explicit mynetworks list by hand, as described with the
mynetworks configuration parameter.
myorigin (default: $myhostname)
The domain name that locally-posted mail appears to come from, and that locally posted
mail is delivered to. The default, $myhostname, is adequate for small sites. If you run a
domain with multiple machines, you should (1) change this to $mydomain and (2) set
up a domain-wide alias database that aliases each user to user@that.users.mailhost.
Example:
myorigin = $mydomain
nested_header_checks (default: $header_checks)
Optional lookup tables for content inspection of non-MIME message headers in

attached messages, as described in the header_checks(5) manual page.
newaliases_path (default: see "postconf -d" output)
Sendmail compatibility feature that specifies the location of the newaliases(1)

command. This command can be used to rebuild the local(8) aliases(5) database.
non_fqdn_reject_code (default: 504)
The numerical Postfix SMTP server reply code when a client request is rejected by the
reject_non_fqdn_hostname, reject_non_fqdn_sender or reject_non_fqdn_recipient
restriction.
notify_classes (default: resource, software)
The list of error classes that are reported to the postmaster. The default is to report only
the most serious problems. The paranoid may wish to turn on the policy (UCE and mail
relaying) and protocol error (broken mail software) reports.
The error classes are:
bounce (also implies 2bounce)

Send the postmaster copies of the headers of bounced mail, and send transcripts
of SMTP sessions when Postfix rejects mail. The notification is sent to the
address specified with the bounce_notice_recipient configuration parameter
2bounce
Send undeliverable bounced mail to the postmaster. The notification is sent to
the address specified with the 2bounce_notice_recipient configuration parameter
delay
Send the postmaster copies of the headers of delayed mail. The notification is
sent to the address specified with the delay_notice_recipient configuration
parameter (default: postmaster).
policy
Send the postmaster a transcript of the SMTP session when a client request was
rejected because of (UCE) policy. The notification is sent to the address
specified with the error_notice_recipient configuration parameter (default:
postmaster).
protocol
Send the postmaster a transcript of the SMTP session in case of client or server
protocol errors. The notification is sent to the address specified with the
resource
Inform the postmaster of mail not delivered due to resource problems. The
notification is sent to the address specified with the error_notice_recipient

configuration parameter (default: postmaster).

software
Inform the postmaster of mail not delivered due to software problems. The
notification is sent to the address specified with the error_notice_recipient
configuration parameter (default: postmaster).
Examples:
notify_classes = bounce, delay, policy, protocol,

resource, software
notify_classes = 2bounce, resource, software
owner_request_special (default: yes)
Give special treatment to owner-listname and listname-request address localparts: don't

split such addresses when the recipient_delimiter is set to "-". This feature is useful for
mailing lists.
parent_domain_matches_subdomains (default: see "postconf -d" output)
What Postfix features match subdomains of "domain.tld" automatically, instead of

requiring an explicit ".domain.tld" pattern. This is planned backwards compatibility:
eventually, all Postfix features are expected to require explicit ".domain.tld" style
patterns when you really want to match subdomains.
permit_mx_backup_networks (default: empty)
Restrict the use of the permit_mx_backup SMTP access feature to only domains whose
primary MX hosts match the listed networks.
pickup_service_name (default: pickup)
The name of the pickup(8) service. This service picks up local mail submissions from
the Postfix maildrop queue.
prepend_delivered_header (default: command, file, forward)
The message delivery contexts where the Postfix local(8) delivery agent prepends a

Delivered-To: message header.
By default, the Postfix local delivery agent prepends a Delivered-To: header when
forwarding mail and when delivering to file (mailbox) and command. Turning off the
Delivered-To: header when forwarding mail is not recommended.
Specify zero or more of forward, file, or command.
Example:
prepend_delivered_header = forward
process_id (read-only)
The process ID of a Postfix command or daemon process.
process_id_directory (default: pid)
The location of Postfix PID files relative to $queue_directory. This is a read-only

parameter.
process_name (read-only)
The process name of a Postfix command or daemon process.
propagate_unmatched_extensions (default: canonical, virtual)
What address lookup tables copy an address extension from the lookup key to the
lookup result.
For example, with a virtual(5) mapping of "joe@domain -> joe.user", the address "joe
+foo@domain" would rewrite to "joe.user+foo".
Specify zero or more of canonical, virtual, alias, forward or include. These cause
address extension propagation with canonical(5), virtual(5), and aliases(5) maps, and
with local(8) .forward and :include: file lookups, respectively.
Note: enabling this feature for types other than canonical and virtual is likely to cause
problems when mail is forwarded to other sites, especially with mail that is sent to a
mailing list exploder address.

Examples:
propagate_unmatched_extensions = canonical, virtual, alias,

forward, include
propagate_unmatched_extensions = canonical, virtual
proxy_interfaces (default: empty)
The network interface addresses that this mail system receives mail on by way of a
proxy or network address translation unit.
You must specify your "outside" proxy/NAT addresses when your system is a backup
MX host for other domains, otherwise mail delivery loops will happen when the
Example:
proxy_interfaces = 1.2.3.4
proxy_read_maps (default: see "postconf -d" output)
The lookup tables that the proxymap(8) server is allowed to access. Table references
that don't begin with proxy: are ignored. The proxymap(8) table accesses are read-only.
qmgr_clog_warn_time (default: 300s)
The minimal delay between warnings that a specific destination is clogging up the
Postfix active queue. Specify 0 to disable.
This feature is enabled with the helpful_warnings parameter.
qmgr_fudge_factor (default: 100)

Obsolete feature: the percentage of delivery resources that a busy mail system will use
up for delivery of a large mailing list message.
This feature exists only in the oqmgr(8) old queue manager. The current queue manager
solves the problem in a better way.
qmgr_message_active_limit (default: 20000)
The maximal number of messages in the active queue.
qmgr_message_recipient_limit (default: 20000)
The maximal number of recipients held in memory by the Postfix queue manager, and
the maximal size of the size of the short-term, in-memory "dead" destination status
cache.
qmgr_message_recipient_minimum (default: 10)
The minimal number of in-memory recipients for any message. This takes priority over
any other in-memory recipient limits (i.e., the global qmgr_message_recipient_limit and
the per transport _recipient_limit) if necessary. The minimum value allowed for this
parameter is 1.
qmqpd_authorized_clients (default: empty)
What clients are allowed to connect to the QMQP server port.
By default, no client is allowed to use the service. This is because the QMQP server will
relay mail to any destination.
Specify a list of client patterns. A list pattern specifies a host name, a domain name, an
internet address, or a network/mask pattern, where the mask specifies the number of bits
in the network part. When a pattern specifies a file name, its contents are substituted for
the file name; when a pattern is a "type:table" table specification, table lookup is used
instead.
Patterns are separated by whitespace and/or commas. In order to reverse the result,
precede a non-file name pattern with an exclamation point (!).
Example:

qmqpd_authorized_clients = !192.168.0.1, 192.168.0.0/24
qmqpd_error_delay (default: 1s)
How long the QMQP server will pause before sending a negative reply to the client. The
purpose is to slow down confused or malicious clients.
qmqpd_timeout (default: 300s)
The time limit for sending or receiving information over the network. If a read or write
operation blocks for more than $qmqpd_timeout seconds the QMQP server gives up and
disconnects.
queue_directory (default: see "postconf -d" output)
The location of the Postfix top-level queue directory. This is the root directory of
Postfix daemon processes that run chrooted.
queue_file_attribute_count_limit (default: 100)
The maximal number of (name=value) attributes that may be stored in a Postfix queue
file. The limit is enforced by the cleanup(8) server.
queue_minfree (default: 0)
The minimal amount of free space in bytes in the queue file system that is needed to
receive mail. This is currently used by the SMTP server to decide if it will accept any
mail at all.
By default, the Postfix 2.1 SMTP server rejects MAIL FROM commands when the
amount of free space is less than 1.5*$message_size_limit. To specify a higher
minimum free space limit, specify a queue_minfree value that is at least 1.5*

$message_size_limit.
With Postfix versions 2.0 and earlier, a queue_minfree value of zero means there is no
minimum required amount of free space.
queue_run_delay (default: 1000s)
The time between deferred queue scans by the queue manager.
queue_service_name (default: qmgr)
The name of the qmgr(8) service. This service manages the Postfix queue and schedules
delivery requests.
rbl_reply_maps (default: empty)
Optional lookup tables with RBL response templates. The tables are indexed by the
RBL domain name. By default, Postfix uses the default template as specified with the
default_rbl_reply configuration parameter. See there for a discussion of the syntax of
RBL reply templates.
readme_directory (default: see "postconf -d" output)
The location of Postfix README files that describe how to build, configure or operate
a specific Postfix subsystem or feature.
receive_override_options (default: empty)
Enable or disable recipient validation, built-in content filtering, or address mapping.

Typically, these are specified in master.cf as command-line arguments for the smtpd(8),
qmqpd(8) or pickup(8) daemons.
Specify zero or more of the following options. The options override main.cf settings and

are either implemented by smtpd(8), qmqpd(8), or pickup(8) themselves, or they are

forwarded to the cleanup server.
no_unknown_recipient_checks
Do not try to reject unknown recipients (SMTP server only). This is typically
specified AFTER an external content filter.
no_address_mappings
Disable canonical address mapping, virtual alias map expansion, address
masquerading, and automatic BCC (blind carbon-copy) recipients. This is
typically specified BEFORE an external content filter.
no_header_body_checks
Disable header/body_checks. This is typically specified AFTER an external
content filter.
Note: when the "BEFORE content filter" receive_override_options setting is specified

in the main.cf file, specify the "AFTER content filter" receive_override_options setting
in master.cf (and vice versa).
Examples:
receive_override_options =
no_unknown_recipient_checks, no_header_body_checks
receive_override_options = no_address_mappings
recipient_bcc_maps (default: empty)
Optional BCC (blind carbon-copy) address lookup tables, indexed by recipient address.
The BCC address (multiple results are not supported) is added when mail enters from
outside of Postfix.
The table search order is as follows:
❍ Look up the "user+extension@domain.tld" address including the optional

address extension.
❍ Look up the "user@domain.tld" address without the optional address extension.
❍ Look up the "user+extension" address local part when the recipient domain

equals $myorigin, $mydestination, $inet_interfaces or $proxy_interfaces.

❍ Look up the "user" address local part when the recipient domain equals
$myorigin, $mydestination, $inet_interfaces or $proxy_interfaces.
❍ Look up the "@domain.tld" part.
Specify the types and names of databases to use. After change, run "postmap /etc/
postfix/recipient_bcc".
Example:
recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
recipient_canonical_classes (default: envelope_recipient, header_recipient)
What addresses are subject to recipient_canonical_maps address mapping. By default,

recipient_canonical_maps address mapping is applied to envelope recipient addresses,
and to header recipient addresses.
Specify one or more of: envelope_recipient, header_recipient
recipient_canonical_maps (default: empty)
Optional address mapping lookup tables for envelope and header recipient addresses.
The table format and lookups are documented in canonical(5).
Note: $recipient_canonical_maps is processed before $canonical_maps.
Example:
recipient_canonical_maps = hash:/etc/postfix/
recipient_canonical

recipient_delimiter (default: empty)
The separator between user names and address extensions (user+foo). See canonical(5),
local(8), relocated(5) and virtual(5) for the effects this has on aliases, canonical, virtual,
relocated and on .forward file lookups. Basically, the software tries user+foo and .
forward+foo before trying user and .forward.
Example:
recipient_delimiter = +
reject_code (default: 554)
is rejected by the "reject" restriction.
relay_clientcerts (default: empty)
The list of remote SMTP client certificates for which the Postfix SMTP server will
allow access with the permit_tls_clientcerts feature. This feature does not use certificate
names, because Postfix list manipulation routines treat whitespace and some other
characters as special. Instead we use certificate fingerprints as they are difficult to fake
but easy to use for lookup.
Postfix lookup tables are in the form of (key, value) pairs. Since we only need the key,
the value can be chosen freely, e.g. the name of the user or host: D7:04:2F:A7:0B:8C:
A5:21:FA:31:77:E1:41:8A:EE:80 lutzpc.at.home
Example:
relay_clientcerts = hash:/etc/postfix/relay_clientcerts
relay_destination_concurrency_limit (default: $default_destination_concurrency_limit)
The maximal number of parallel deliveries to the same destination via the relay message

This feature is available in Postfix version 2.0 and later.
relay_destination_recipient_limit (default: $default_destination_recipient_limit)
The maximal number of recipients per delivery via the relay message delivery transport.

relay_destination_concurrency_limit from concurrency per domain into concurrency per
recipient.
relay_domains (default: $mydestination)
What destination domains (and subdomains thereof) this system will relay mail to.
Subdomain matching is controlled with the parent_domain_matches_subdomains
parameter. For details about how the relay_domains value is used, see the description of
the permit_auth_destination and reject_unauth_destination SMTP recipient restrictions.
Domains that match $relay_domains are delivered with the $relay_transport mail
delivery transport. The SMTP server validates recipient addresses with
$relay_recipient_maps and rejects non-existent recipients. See also the relay domains
address class in the ADDRESS_CLASS_README file.
NOTE: Postfix will not automatically forward mail for domains that list this system as
their primary or backup MX host. See the permit_mx_backup restriction in the postconf
(5) manual page.
Specify a list of host or domain names, "/file/name" patterns or "type:table" lookup

tables, separated by commas and/or whitespace. Continue long lines by starting the next
line with whitespace. A "/file/name" pattern is replaced by its contents; a "type:table"
lookup table is matched when a (parent) domain appears as lookup key.
relay_domains_reject_code (default: 554)
The numerical Postfix SMTP server response code when a client request is rejected by
the reject_unauth_destination recipient restriction.

relay_recipient_maps (default: empty)
Optional lookup tables with all valid addresses in the domains that match
$relay_domains. Specify @domain as a wild-card for domains that do not have a valid
recipient list. Technically, tables listed with $relay_recipient_maps are used as lists:
Postfix needs to know only if a lookup string is found or not, but it does not use the
result from table lookup.
If this parameter is non-empty, then the Postfix SMTP server will reject mail to
unknown relay users. This feature is off by default.
See also the relay domains address class in the ADDRESS_CLASS_README file.
Example:
relay_recipient_maps = hash:/etc/postfix/relay_recipients
relay_transport (default: relay)
The default mail delivery transport and next-hop information for domains that match the
$relay_domains parameter value. This information can be overruled with the transport
(5) table.
See also the relay domains address class in the ADDRESS_CLASS_README file.
relayhost (default: empty)
The default host to send non-local mail to when no entry is matched in the optional
transport(5) table. When no relayhost is given, mail is routed directly to the destination.

On an intranet, specify the organizational domain name. If your internal DNS uses no
MX records, specify the name of the intranet gateway host instead.
In the case of SMTP, specify a domain name, hostname, hostname:port, [hostname]:

port, [hostaddress] or [hostaddress]:port. The form [hostname] turns off MX lookups.
If you're connected via UUCP, see the UUCP_README file for useful information.
Examples:
relayhost = [gateway.my.domain]
relayhost = uucphost
relayhost = [an.ip.add.ress]
relocated_maps (default: empty)
Optional lookup tables with new contact information for users or domains that no longer
exist. The table format and lookups are documented in relocated(5).
If you use this feature, run "postmap /etc/postfix/relocated" to build the necessary
DBM or DB file after change, then "postfix reload" to make the changes visible.
Examples:
relocated_maps = dbm:/etc/postfix/relocated
relocated_maps = hash:/etc/postfix/relocated
remote_header_rewrite_domain (default: empty)
Don't rewrite message headers from remote clients at all when this parameter is empty;
otherwise, rewrite remote message headers and append the specified domain name to
incomplete addresses. The local_header_rewrite_clients parameter controls what clients
Postfix considers local.
Examples:
The safe setting: append "domain.invalid" to incomplete header addresses from remote
SMTP clients, so that those addresses cannot be confused with local addresses.

remote_header_rewrite_domain = domain.invalid
The default, purist, setting: don't rewrite headers from remote clients at all.
remote_header_rewrite_domain =
require_home_directory (default: no)
Whether or not a local(8) recipient's home directory must exist before mail delivery is
attempted. By default this test is disabled. It can be useful for environments that import
home directories to the mail server (NOT RECOMMENDED).
resolve_dequoted_address (default: yes)
Resolve a recipient address safely instead of correctly, by looking inside quotes.
By default, the Postfix address resolver does not quote the address localpart as per RFC
822, so that additional @ or % or ! operators remain visible. This behavior is safe but it
is also technically incorrect.
If you specify "resolve_dequoted_address = no", then the Postfix resolver will not know
about additional @ etc. operators in the address localpart. This opens opportunities for
obscure mail relay attacks with user@domain@domain addresses when Postfix
provides backup MX service for Sendmail systems.
resolve_null_domain (default: no)
Resolve an address that ends in the "@" null domain as if the local hostname were
specified, instead of rejecting the address as invalid.
This feature is available in Postfix version 2.1 and later. Earlier versions always resolve
the null domain as the local hostname.
The Postfix SMTP server uses this feature to reject mail from or to addresses that end in
the "@" null domain, and from addresses that rewrite into a form that ends in the "@"
null domain.
rewrite_service_name (default: rewrite)

The name of the address rewriting service. This service rewrites addresses to standard
form and resolves them to a (delivery method, next-hop host, recipient) triple.
sample_directory (default: /etc/postfix)
The name of the directory with example Postfix configuration files.
sender_based_routing (default: no)
This parameter should not be used.
sender_bcc_maps (default: empty)
Optional BCC (blind carbon-copy) address lookup tables, indexed by sender address.
The BCC address (multiple results are not supported) is added when mail enters from
outside of Postfix.
The table search order is as follows:
❍ Look up the "user+extension@domain.tld" address including the optional

address extension.
❍ Look up the "user@domain.tld" address without the optional address extension.
❍ Look up the "user+extension" address local part when the sender domain equals
$myorigin, $mydestination, $inet_interfaces or $proxy_interfaces.
❍ Look up the "user" address local part when the sender domain equals $myorigin,
$mydestination, $inet_interfaces or $proxy_interfaces.
❍ Look up the "@domain.tld" part.
Specify the types and names of databases to use. After change, run "postmap /etc/
postfix/sender_bcc".

Example:
sender_bcc_maps = hash:/etc/postfix/sender_bcc
sender_canonical_classes (default: envelope_sender, header_sender)
What addresses are subject to sender_canonical_maps address mapping. By default,

sender_canonical_maps address mapping is applied to envelope sender addresses, and
to header sender addresses.
Specify one or more of: envelope_sender, header_sender
sender_canonical_maps (default: empty)
Optional address mapping lookup tables for envelope and header sender addresses. The
table format and lookups are documented in canonical(5).
Example: you want to rewrite the SENDER address "user@ugly.domain" to

"user@pretty.domain", while still being able to send mail to the RECIPIENT address
"user@ugly.domain".
Note: $sender_canonical_maps is processed before $canonical_maps.
Example:
sender_canonical_maps = hash:/etc/postfix/sender_canonical
sendmail_path (default: see "postconf -d" output)
A Sendmail compatibility feature that specifies the location of the Postfix sendmail(1)
command. This command can be used to submit mail into the Postfix queue.
service_throttle_time (default: 60s)
How long the Postfix master(8) waits before forking a server that appears to be
malfunctioning.

session_cache_service (default: scache)
The name of the scache(8) connection cache service. This service maintains a limited
pool of cached sessions.
session_cache_status_update_time (default: 600s)
How frequently the scache(8) server logs usage statistics with connection cache hit and
miss rates for logical destinations and for physical endpoints.
session_cache_ttl_limit (default: 2s)
The maximal time-to-live value that the connection cache server allows. Requests that
specify a larger TTL will be stored with the maximum allowed TTL. The purpose of
this additional control is to protect the infrastructure against careless people. The cache
TTL is already bounded by $max_idle.
setgid_group (default: postdrop)
The group ownership of set-gid Postfix commands and of group-writable Postfix

directories. When this parameter value is changed you need to re-run "post-install set-
permissions".
show_user_unknown_table_name (default: yes)
Display the name of the recipient table in the "User unknown" responses. The extra
detail makes trouble shooting easier but also reveals information that is nobody elses
business.
showq_service_name (default: showq)
The name of the showq(8) service. This service produces mail queue status reports.

smtp_always_send_ehlo (default: yes)
Always send EHLO at the start of an SMTP session.
With "smtp_always_send_ehlo = no", Postfix sends EHLO only when the word
"ESMTP" appears in the server greeting banner (example: 220 spike.porcupine.org
ESMTP Postfix).
smtp_bind_address (default: empty)
An optional numerical network address that the SMTP client should bind to when
making a connection.
This can be specified in the main.cf file for all SMTP clients, or it can be specified in
the master.cf file for a specific client, for example:
smtp ... smtp -o smtp_bind_address=11.22.33.44
Note: when inet_interfaces specifies exactly one address that is a non-loopback address,
it is automatically used as the smtp_bind_address. This supports virtual IP hosting, but
can be a problem on multi-homed firewalls. See the inet_interfaces documentation for
more detail.
smtp_connect_timeout (default: 30s)
The SMTP client time limit for completing a TCP connection, or zero (use the operating
system built-in time limit).
When no connection can be made within the deadline, the SMTP client tries the next
address on the mail exchanger list. Specify 0 to disable the time limit (i.e. use whatever
timeout is implemented by the operating system).
smtp_connection_cache_destinations (default: empty)
Permanently enable SMTP connection caching for the specified destinations. With
SMTP connection caching, a connection is not closed immediately after completion of a

mail transaction. Instead, the connection is kept open for up to

$smtp_connection_cache_time_limit seconds. This allows connections to be reused for
other deliveries, and can improve mail delivery performance.
Specify a comma or white space separated list of destinations or pseudo-destinations:
❍ if mail is sent without a relay host: a domain name (the right-hand side of an
email address, without the optional []),
❍ if mail is sent via a relay host: a relay host (without the optional [] or non-default
TCP port), as specified in main.cf or in the transport map,
❍ a /file/name with domains and/or relay hosts,
❍ a "type:table" with domains and/or relay hosts on the left-hand side. The right-
hand side result from "type:table" lookups is ignored.
smtp_connection_cache_on_demand (default: yes)
Temporarily enable SMTP connection caching while a destination has a high volume of
mail in the active queue. With SMTP connection caching, a connection is not closed
immediately after completion of a mail transaction. Instead, the connection is kept open
for up to $smtp_connection_cache_time_limit seconds. This allows connections to be
reused for other deliveries, and can improve mail delivery performance.
smtp_connection_cache_reuse_limit (default: 10)
When SMTP connection caching is enabled, the number of times that an SMTP session
is reused before it is closed.
smtp_connection_cache_time_limit (default: 2s)
When SMTP connection caching is enabled, the amount of time that an unused SMTP
client socket is kept open before it is closed. Do not specify larger values without
permission from the remote sites.

smtp_data_done_timeout (default: 600s)
The SMTP client time limit for sending the SMTP ".", and for receiving the server
response.
When no response is received within the deadline, a warning is logged that the mail may
be delivered multiple times.
smtp_data_init_timeout (default: 120s)
The SMTP client time limit for sending the SMTP DATA command, and for receiving
smtp_data_xfer_timeout (default: 180s)
The SMTP client time limit for sending the SMTP message content. When the
connection makes no progress for more than $smtp_data_xfer_timeout seconds the
SMTP client terminates the transfer.
smtp_defer_if_no_mx_address_found (default: no)
Defer mail delivery when no MX record resolves to an IP address.
The default (no) is to return the mail as undeliverable. With older Postfix versions the
default was to keep trying to deliver the mail until someone fixed the MX record or until
the mail was too old.
Note: Postfix always ignores MX records with equal or worse preference than the local
MTA itself.

smtp_destination_concurrency_limit (default: $default_destination_concurrency_limit)
The maximal number of parallel deliveries to the same destination via the smtp message
smtp_destination_recipient_limit (default: $default_destination_recipient_limit)
The maximal number of recipients per delivery via the smtp message delivery transport.

smtp_destination_concurrency_limit from concurrency per domain into concurrency per
recipient.
smtp_discard_ehlo_keyword_address_maps (default: empty)
Lookup tables, indexed by the remote SMTP server address, with case insensitive lists
of EHLO keywords (pipelining, starttls, auth, etc.) that the SMTP client will ignore in
the EHLO response from a remote SMTP server.
smtp_discard_ehlo_keywords (default: empty)
A case insensitive list of EHLO keywords (pipelining, starttls, auth, etc.) that the SMTP
client will ignore in the EHLO response from a remote SMTP server. Use the
smtp_discard_ehlo_keyword_address_maps feature to discard EHLO keywords
selectively.
smtp_enforce_tls (default: no)
Enforcement mode: require that remote SMTP servers use TLS encryption, and never
send mail in the clear. This also requires that the remote SMTP server hostname
matches the information in the remote server certificate, and that the remote SMTP
server certificate was issued by a CA that is trusted by the Postfix SMTP client. If the
certificate doesn't verify or the hostname doesn't match, delivery is deferred and mail
stays in the queue.
The server hostname is matched against all names provided as dNSNames in the
SubjectAlternativeName. If no dNSNames are specified, the CommonName is checked.

The behavior may be changed with the smtp_tls_enforce_peername option.
This option is useful only if you are definitely sure that you will only connect to servers
that support RFC 2487 _and_ that provide valid server certificates. Typical use is for
clients that send all their email to a dedicated mailhub.
smtp_helo_name (default: $myhostname)
The hostname to send in the SMTP EHLO or HELO command.
The default value is the machine hostname. Specify a hostname or [ip.add.re.ss].
This information can be specified in the main.cf file for all SMTP clients, or it can be
specified in the master.cf file for a specific client, for example:
mysmtp ... smtp -o smtp_helo_name=foo.bar.com
smtp_helo_timeout (default: 300s)
The SMTP client time limit for sending the HELO or EHLO command, and for
receiving the initial server response.
smtp_host_lookup (default: dns)
What mechanisms when the SMTP client uses to look up a host's IP address. This
parameter is ignored when DNS lookups are disabled.
Specify one of the following:
dns
Hosts can be found in the DNS (preferred).
native
Use the native naming service only (nsswitch.conf, or equivalent mechanism).
dns, native

Use the native service for hosts not found in the DNS.
smtp_line_length_limit (default: 990)
The maximal length of message header and body lines that Postfix will send via SMTP.
Longer lines are broken by inserting "<CR><LF><SPACE>". This minimizes the
damage to MIME formatted mail.
By default, the line length is limited to 990 characters, because some server
implementations cannot receive mail with long lines.
smtp_mail_timeout (default: 300s)
The SMTP client time limit for sending the MAIL FROM command, and for receiving
smtp_mx_address_limit (default: 0)
The maximal number of MX (mail exchanger) IP addresses that can result from mail
exchanger lookups, or zero (no limit).
smtp_mx_session_limit (default: 2)
The maximal number of SMTP sessions per delivery request before giving up or
delivering to a fall-back relay host, or zero (no limit). This restriction ignores IP
addresses that fail to complete the SMTP initial handshake.
smtp_never_send_ehlo (default: no)
Never send EHLO at the start of an SMTP session. See also the smtp_always_send_ehlo
parameter.

smtp_pix_workaround_delay_time (default: 10s)
How long the Postfix SMTP client pauses before sending ".<CR><LF>" in order to
work around the PIX firewall "<CR><LF>.<CR><LF>" bug.
Choosing a too short time makes this workaround ineffective when sending large
messages over slow network connections.
smtp_pix_workaround_threshold_time (default: 500s)
How long a message must be queued before the PIX firewall "<CR><LF>.<CR><LF>"
bug workaround is turned on.
By default, the workaround is turned off for mail that is queued for less than 500
seconds. In other words, the workaround is normally turned off for the first delivery
attempt.
Specify 0 to enable the PIX firewall "<CR><LF>.<CR><LF>" bug workaround upon

the first delivery attempt.
smtp_quit_timeout (default: 300s)
The SMTP client time limit for sending the QUIT command, and for receiving the
server response.
smtp_quote_rfc821_envelope (default: yes)
Quote addresses in SMTP MAIL FROM and RCPT TO commands as required by RFC
821. This includes putting quotes around an address localpart that ends in ".".
The default is to comply with RFC 821. If you have to send mail to a broken SMTP
server, configure a special SMTP client in master.cf:
broken-smtp . . . smtp -o
smtp_quote_rfc821_envelope=no

and route mail for the destination in question to the "broken-smtp" message delivery
with a transport(5) table.
smtp_randomize_addresses (default: yes)
Randomize the order of equal-preference MX host addresses. This is a performance

feature of the Postfix SMTP client.
smtp_rcpt_timeout (default: 300s)
The SMTP client time limit for sending the SMTP RCPT TO command, and for
receiving the server response.
smtp_rset_timeout (default: 20s)
The SMTP client time limit for sending the RSET command, and for receiving the
server response. The SMTP client sends RSET in order to finish a recipient address
probe, or to verify that a cached session is still usable.
smtp_sasl_auth_enable (default: no)
Enable SASL authentication in the Postfix SMTP client. By default, the Postfix SMTP
client uses no authentication.
Example:
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter (default: empty)
If non-empty, a Postfix SMTP client filter for the remote SMTP server's list of offered
SASL mechanisms. Different client and server implementations may support different
mechanism lists. By default, the Postfix SMTP client will use the intersection of the

two. smtp_sasl_mechanism_filter further restricts what server mechanisms the client

will take into consideration.
Specify mechanism names, "/file/name" patterns or "type:table" lookup tables. The right-
hand side result from "type:table" lookups is ignored.
Examples:
smtp_sasl_mechanism_filter = plain, login

smtp_sasl_mechanism_filter = /etc/postfix/smtp_mechs
smtp_sasl_mechanism_filter = !gssapi, !login, static:rest
smtp_sasl_password_maps (default: empty)
Optional SMTP client lookup tables with one username:password entry per remote
hostname or domain. If a remote host or domain has no username:password entry, then
the Postfix SMTP client will not attempt to authenticate to the remote host.
The Postfix SMTP client opens the lookup table before going to chroot jail, so you can
leave the password file in /etc/postfix.
smtp_sasl_security_options (default: noplaintext, noanonymous)
What authentication mechanisms the Postfix SMTP client is allowed to use. The list of
available authentication mechanisms is system dependent.
Specify zero or more of the following:
noplaintext
Disallow methods that use plaintext passwords.
noactive
Disallow methods subject to active (non-dictionary) attack.
nodictionary
Disallow methods subject to passive (dictionary) attack.
noanonymous
Disallow methods that allow anonymous authentication.
mutual_auth
Only allow methods that provide mutual authentication (not available with SASL

version 1).
Example:
smtp_sasl_security_options = noplaintext
smtp_sasl_tls_security_options (default: $smtp_sasl_security_options)
The SASL authentication security options that the Postfix SMTP client uses for TLS
encrypted SMTP sessions.
smtp_send_xforward_command (default: no)
Send the non-standard XFORWARD command when the Postfix SMTP server EHLO
response announces XFORWARD support.
This allows an "smtp" delivery agent, used for injecting mail into a content filter, to
forward the name, address, protocol and HELO name of the original client to the
content filter and downstream queuing SMTP server. This can produce more useful
logging than localhost[127.0.0.1] etc.
smtp_skip_4xx_greeting (default: yes)
Skip SMTP servers that greet with a 4XX status code (go away, try again later).
By default, Postfix moves on the next mail exchanger. Specify

"smtp_skip_4xx_greeting = no" if Postfix should defer delivery immediately.
This feature is available in Postfix version 2.0 and earlier. Later Postfix versions always
skip SMTP servers that greet with a 4XX status code.
smtp_skip_5xx_greeting (default: yes)
Skip SMTP servers that greet with a 5XX status code (go away, do not try again later).
By default, the Postfix SMTP client moves on the next mail exchanger. Specify
"smtp_skip_5xx_greeting = no" if Postfix should bounce the mail immediately. The
default setting is incorrect, but it is what a lot of people expect to happen.

smtp_skip_quit_response (default: yes)
Do not wait for the response to the SMTP QUIT command.
smtp_starttls_timeout (default: 300s)
Time limit for Postfix SMTP client write and read operations during TLS startup and
shutdown handshake procedures.
smtp_tls_CAfile (default: empty)
The file with the certificate of the certification authority (CA) that issued the Postfix
SMTP client certificate. This is needed only when the CA certificate is not already
present in the client certificate file.
Example:
smtp_tls_CAfile = /etc/postfix/CAcert.pem
smtp_tls_CApath (default: empty)
Directory with PEM format certificate authority certificates that the Postfix SMTP
client uses to verify a remote SMTP server certificate. Don't forget to create the
necessary "hash" links with, for example, "$OPENSSL_HOME/bin/c_rehash /etc/
postfix/certs".
To use this option in chroot mode, this directory (or a copy) must be inside the chroot
jail.
Example:
smtp_tls_CApath = /etc/postfix/certs
smtp_tls_cert_file (default: empty)
File with the Postfix SMTP client RSA certificate in PEM format. This file may also
contain the client private key, and these may be the same as the server certificate and
key file.
In order to verify certificates, the CA certificate (in case of a certificate chain, all CA

certificates) must be available. You should add these certificates to the server certificate,
the server certificate first, then the issuing CA(s).
Example: the certificate for "client.dom.ain" was issued by "intermediate CA" which
itself has a certificate of "root CA". Create the client.pem file with "cat client_cert.pem
intermediate_CA.pem root_CA.pem > client.pem".
If you want to accept remote SMTP server certificates issued by these CAs yourself,
you can also add the CA certificates to the smtp_tls_CAfile, in which case it is not
necessary to have them in the smtp_tls_cert_file or smtp_tls_dcert_file.
A certificate supplied here must be usable as SSL client certificate and hence pass the
"openssl verify -purpose sslclient ..." test.
Example:
smtp_tls_cert_file = /etc/postfix/client.pem
smtp_tls_cipherlist (default: empty)
Controls the Postfix SMTP client TLS cipher selection scheme. For details, see the
OpenSSL documentation. Note: do not use "" quotes around the parameter value.
smtp_tls_dcert_file (default: empty)
File with the Postfix SMTP client DSA certificate in PEM format. This file may also
contain the server private key.
See the discussion under smtp_tls_cert_file for more details.
Example:
smtp_tls_dcert_file = /etc/postfix/client-dsa.pem
smtp_tls_dkey_file (default: $smtp_tls_dcert_file)
File with the Postfix SMTP client DSA private key in PEM format. The private key
must not be encrypted. In other words, the key must be accessible without password.
This file may be combined with the server certificate file specified with

$smtp_tls_cert_file.
smtp_tls_enforce_peername (default: yes)
When TLS encryption is enforced, require that the remote SMTP server hostname
matches the information in the remote SMTP server certificate. As of RFC 2487 the
requirements for hostname checking for MTA clients are not specified.
This option can be set to "no" to disable strict peer name checking. This setting has no
effect on sessions that are controlled via the smtp_tls_per_site table.
Disabling the hostname verification can make sense in closed environment where
special CAs are created. If not used carefully, this option opens the danger of a "man-in-
the-middle" attack (the CommonName of this attacker will be logged).
smtp_tls_key_file (default: $smtp_tls_cert_file)
File with the Postfix SMTP client RSA private key in PEM format. This file may be
combined with the client certificate file specified with $smtp_tls_cert_file.
The private key must not be encrypted. In other words, the key must be accessible
without password.
Example:
smtp_tls_key_file = $smtp_tls_cert_file
smtp_tls_loglevel (default: 0)
Enable additional Postfix SMTP client logging of TLS activity. Each logging level also
includes the information that is logged at a lower logging level.
0 Disable logging of TLS activity.

1 Log TLS handshake and certificate information.
2 Log levels during TLS negotiation.
3 Log hexadecimal and ASCII dump of TLS negotiation process.
4 Log hexadecimal and ASCII dump of complete transmission after STARTTLS.
Use "smtp_tls_loglevel = 3" only in case of problems. Use of loglevel 4 is strongly

discouraged.

smtp_tls_note_starttls_offer (default: no)
Log the hostname of a remote SMTP server that offers STARTTLS, when TLS is not
already enabled for that server.
The logfile record looks like:
postfix/smtp[pid]: Host offered STARTTLS: [name.of.host]
smtp_tls_per_site (default: empty)
Optional lookup tables with the Postfix SMTP client TLS usage policy by next-hop
domain name and by remote SMTP server hostname.
Table format: domain names or server hostnames are specified on the left-hand side; no
wildcards are allowed. On the right hand side specify one of the following keywords:
NONE
Don't use TLS at all.
MAY
Try to use STARTTLS if offered, otherwise use the unencrypted connection.
NOTE: STARTTLS can be used only if TLS is already enabled via main.cf, so
that the client TLS engine is properly initialized at program startup.
MUST
Require usage of STARTTLS, require that the remote SMTP server hostname
matches the information in the remote SMTP server certificate, and require that
the remote SMTP server certificate was issued by a trusted CA.
MUST_NOPEERMATCH
Require usage of STARTTLS, but do not require that the remote SMTP server
hostname matches the information in the remote SMTP server certificate, or that
the server certificate was issued by a trusted CA.
Special hint for enforcement mode: since no secure DNS lookup mechanism is
available, the recommended setup is: specify local transport(5) table entries for sensitive
domains with explicit smtp:[mailhost] destinations (since you can assure security of this
table unlike DNS), then specify MUST for these mail hosts in the smtp_tls_per_site
table.
smtp_tls_scert_verifydepth (default: 5)

The verification depth for remote SMTP server certificates. A depth of 1 is sufficient, if
the certificate is directly issued by a CA listed in the CA files. The default value (5)
should suffice for longer chains (the root CA issues special CA which then issues the
actual certificate...).
smtp_tls_session_cache_database (default: empty)
Name of the file containing the optional Postfix SMTP client TLS session cache.
Specify a database type that supports enumeration, such as btree or sdbm; there is no
need to support concurrent access. The file is created if it does not exist.
NOTE: dbm databases are not suitable. TLS session objects are too large.
Example:
smtp_tls_session_cache_database = btree:/var/postfix/
smtp_scache
smtp_tls_session_cache_timeout (default: 3600s)
The expiration time of Postfix SMTP client TLS session cache information. A cache
cleanup is performed periodically every $smtp_tls_session_cache_timeout seconds.
smtp_use_tls (default: no)
Opportunistic mode: use TLS when a remote SMTP server announces STARTTLS
support, otherwise send the mail in the clear. Beware: some SMTP servers offer
STARTTLS even if it is not configured. If the TLS handshake fails, and no other server
is available, delivery is deferred and mail stays in the queue. If this is a concern for you,
use the smtp_tls_per_site feature instead.
smtp_xforward_timeout (default: 300s)
The SMTP client time limit for sending the XFORWARD command, and for receiving

smtpd_authorized_verp_clients (default: $authorized_verp_clients)
What SMTP clients are allowed to specify the XVERP command. This command
requests that mail be delivered one recipient at a time with a per recipient return
address.
By default, no clients are allowed to specify XVERP.
This parameter was renamed with Postfix 2.1. The default value is backwards
compatible with Postfix 2.0.

smtpd_authorized_xclient_hosts (default: empty)
What SMTP clients are allowed to use the XCLIENT feature. This command overrides
SMTP client information that is used for access control. Typical use is for SMTP-based
content filters, fetchmail-like programs, or SMTP server access rule testing. See the
XCLIENT_README document for details.
By default, no clients are allowed to specify XCLIENT.

smtpd_authorized_xforward_hosts (default: empty)

What SMTP clients are allowed to use the XFORWARD feature. This command
forwards information that is used to improve logging after SMTP-based content filters.
See the XFORWARD_README document for details.
By default, no clients are allowed to specify XFORWARD.

smtpd_banner (default: $myhostname ESMTP $mail_name)
The text that follows the 220 status code in the SMTP greeting banner. Some people
like to see the mail version advertised. By default, Postfix shows no version.
You MUST specify $myhostname at the start of the text. This is required by the SMTP
protocol.
Example:
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
smtpd_client_connection_count_limit (default: 50)
How many simultaneous connections any client is allowed to make to this service. By
default, the limit is set to half the default process limit value.
To disable this feature, specify a limit of 0.
WARNING: The purpose of this feature is to limit abuse. It must not be used to regulate
legitimate mail traffic.

smtpd_client_connection_rate_limit (default: 0)
The maximal number of connection attempts any client is allowed to make to this
service per time unit. The time unit is specified with the anvil_rate_time_unit
By default, a client can make as many connections per time unit as Postfix can accept.
Example:
smtpd_client_connection_rate_limit = 1000
smtpd_client_event_limit_exceptions (default: $mynetworks)
Clients that are excluded from connection count, connection rate, message rate or
recipient rate restrictions.
By default, clients in trusted networks are excluded. Specify a list of network blocks,
hostnames or .domain names (the initial dot causes the domain to match any name
below it).
smtpd_client_message_rate_limit (default: 0)
The maximal number of message delivery requests that any client is allowed to make to
this service per time unit, regardless of whether or not Postfix actually accepts those
messages. The time unit is specified with the anvil_rate_time_unit configuration
parameter.
By default, a client can send as many message delivery requests per time unit as Postfix
can accept.

Example:
smtpd_client_message_rate_limit = 1000
smtpd_client_recipient_rate_limit (default: 0)
The maximal number of recipient addresses that any client is allowed to send to this
service per time unit, regardless of whether or not Postfix actually accepts those
recipients. The time unit is specified with the anvil_rate_time_unit configuration
parameter.
By default, a client can make as many recipient addresses per time unit as Postfix can
accept.
Example:
smtpd_client_recipient_rate_limit = 1000
smtpd_client_restrictions (default: empty)
Optional SMTP server access restrictions in the context of a client SMTP connection
request.
The default is to allow all connection requests.
Specify a list of restrictions, separated by commas and/or whitespace. Continue long

lines by starting the next line with whitespace. Restrictions are applied in the order as
specified; the first restriction that matches wins.
The following restrictions are specific to client hostname or client network address
information.
check_client_access type:table
Search the specified access database for the client hostname, parent domains,
client IP address, or networks obtained by stripping least significant octets. See
the access(5) manual page for details.
permit_mynetworks
Permit the request when the client IP address matches any network or network
address listed in $mynetworks.
permit_sasl_authenticated
Permit the request when the client is successfully authenticated via the RFC
2554 (AUTH) protocol.
Permit the request when the remote SMTP client certificate is verified
successfully. This option must be used only if a special CA issues the certificates
and only this CA is listed as trusted CA, otherwise all clients with a recognized
certificate would be allowed to relay.
Permit the request when the remote SMTP client certificate is verified
successfully, and the certificate fingerprint is listed in $relay_clientcerts.
reject_rbl_client rbl_domain=d.d.d.d
Reject the request when the reversed client network address is listed with the A
record "d.d.d.d" under rbl_domain (Postfix version 2.1 and later only). If no "=d.
d.d.d" is specified, reject the request when the reversed client network address is
listed with any A record under rbl_domain.
The maps_rbl_reject_code parameter specifies the response code for rejected
requests (default: 554), the default_rbl_reply parameter specifies the default
server reply, and the rbl_reply_maps parameter specifies tables with server
replies indexed by rbl_domain. This feature is available in Postfix 2.0 and later.
reject_rhsbl_client rbl_domain=d.d.d.d
Reject the request when the client hostname is listed with the A record "d.d.d.d"
under rbl_domain (Postfix version 2.1 and later only). If no "=d.d.d.d" is
specified, reject the request when the reversed client network address is listed
with any A record under rbl_domain. See the reject_rbl_client description above
for additional RBL related configuration parameters. This feature is available in
Postfix 2.0 and later.
reject_unknown_client

Reject the request when the client IP address has no PTR (address to name)
record in the DNS, or when the PTR record does not have a matching A (name to
address) record.
The unknown_client_reject_code parameter specifies the response code for
rejected requests (default: 450). The reply is always 450 in case the hostname
lookup failed due to a temporary problem.
In addition, you can use any of the following generic restrictions. These restrictions are
applicable in any SMTP command context.
check_policy_service servername
Query the specified policy server. See the SMTPD_POLICY_README
document for details. This feature is available in Postfix 2.1 and later.
defer
Defer the request. The client is told to try again later. This restriction is useful at
the end of a restriction list, to make the default policy explicit.
The defer_code parameter specifies the SMTP server reply code (default: 450).
defer_if_permit
Defer the request if some later restriction would result in an explicit or implicit
PERMIT action. This is useful when a blacklisting feature fails due to a
temporary problem. This feature is available in Postfix 2.1 and later.
defer_if_reject
Defer the request if some later restriction would result in a REJECT action. This
is useful when a whitelisting feature fails due to a temporary problem. This
feature is available in Postfix 2.1 and later.
permit
Permit the request. This restriction is useful at the end of a restriction list, to
make the default policy explicit.
reject_multi_recipient_bounce
Reject the request when the envelope sender is the null address, and the message
has multiple envelope recipients. Although this usage is technically allowed, it
seems to have no legitimate application.
NOTE: this restriction can only work reliably when used in
smtpd_data_restrictions or smtpd_end_of_data_restrictions, because the total
number of recipients is not known at an earlier stage of the SMTP conversation.
Use at the RCPT stage will only reject the second etc. recipient.
The multi_recipient_bounce_reject_code parameter specifies the response code
for rejected requests (default: 550). This feature is available in Postfix 2.1 and
later.
reject_unauth_pipelining
Reject the request when the client sends SMTP commands ahead of time where
it is not allowed, or when the client sends SMTP commands ahead of time

without knowing that Postfix actually supports ESMTP command pipelining.

This stops mail from bulk mail software that improperly uses ESMTP command
pipelining in order to speed up deliveries.
NOTE: reject_unauth_pipelining is not useful outside smtpd_data_restrictions
when 1) the client uses ESMTP (EHLO instead of HELO) and 2) with
"smtpd_delay_reject = yes" (the default). The use of reject_unauth_pipelining in
the other restriction contexts is therefore not recommended.
reject
Reject the request. This restriction is useful at the end of a restriction list, to
make the default policy explicit. The reject_code configuration parameter
specifies the response code to rejected requests (default: 554).
warn_if_reject
Change the meaning of the next restriction, so that it logs a warning instead of
rejecting a request (look for logfile records that contain "reject_warning"). This
is useful for testing new restrictions in a "live" environment without risking
unnecessary loss of mail.
Other restrictions that are valid in this context:
❍ SMTP command specific restrictions that are described under the

smtpd_helo_restrictions, smtpd_sender_restrictions or
smtpd_recipient_restrictions parameters. When helo, sender or recipient
restrictions are listed under smtpd_client_restrictions, they have effect only with
"smtpd_delay_reject = yes", so that $smtpd_client_restrictions is evaluated at the
time of the RCPT TO command.
Example:
smtpd_client_restrictions = permit_mynetworks,
smtpd_data_restrictions (default: empty)
Optional access restrictions that the Postfix SMTP server applies in the context of the
SMTP DATA command.


The following restrictions are valid in this context:
❍ Generic restrictions that can be used in any SMTP command context, described
under smtpd_client_restrictions.
❍ SMTP command specific restrictions described under smtpd_client_restrictions,
smtpd_helo_restrictions, smtpd_sender_restrictions or
smtpd_recipient_restrictions.
Examples:
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_data_restrictions = reject_multi_recipient_bounce
smtpd_delay_reject (default: yes)
Wait until the RCPT TO command before evaluating $smtpd_client_restrictions,

$smtpd_helo_restrictions and $smtpd_sender_restrictions, or wait until the ETRN
command before evaluating $smtpd_client_restrictions and $smtpd_helo_restrictions.
This feature is turned on by default because some clients apparently mis-behave when
the Postfix SMTP server rejects commands before RCPT TO.
The default setting has one major benefit: it allows Postfix to log recipient address
information when rejecting a client name/address or sender address, so that it is possible
to find out whose mail is being rejected.
smtpd_discard_ehlo_keyword_address_maps (default: empty)
Lookup tables, indexed by the remote SMTP client address, with case insensitive lists of
EHLO keywords (pipelining, starttls, auth, etc.) that the SMTP server will not send in
the EHLO response to a remote SMTP client.
smtpd_discard_ehlo_keywords (default: empty)
A case insensitive list of EHLO keywords (pipelining, starttls, auth, etc.) that the SMTP
server will not send in the EHLO response to a remote SMTP client. Use the
smtpd_discard_ehlo_keyword_address_maps feature to discard EHLO keywords
selectively.

smtpd_end_of_data_restrictions (default: empty)
Optional access restrictions that the Postfix SMTP server applies in the context of the
SMTP END-OF-DATA command.
See smtpd_data_restrictions for syntax details.
smtpd_enforce_tls (default: no)
Enforcement mode: announce STARTTLS support to SMTP clients, and require that
clients use TLS encryption. According to RFC 2487 this MUST NOT be applied in case
of a publicly-referenced SMTP server. This option is off by default and should be used
only on dedicated servers.
Note 1: this mode implies "smtpd_tls_auth_only = yes".
Note 2: when invoked via "sendmail -bs", Postfix will never offer STARTTLS due to
insufficient privileges to access the server private key. This is intended behavior.
smtpd_error_sleep_time (default: 1s)
With Postfix 2.1 and later: the SMTP server response delay after a client has made more
than $smtpd_soft_error_limit errors, and fewer than $smtpd_hard_error_limit errors,
without delivering mail.
With Postfix 2.0 and earlier: the SMTP server delay before sending a reject (4xx or 5xx)
response, when the client has made fewer than $smtpd_soft_error_limit errors without
delivering mail.
smtpd_etrn_restrictions (default: empty)
Optional SMTP server access restrictions in the context of a client ETRN request.
The Postfix ETRN implementation accepts only destinations that are eligible for the
Postfix "fast flush" service. See the ETRN_README file for details.

The following restrictions are specific to the domain name information received with
the ETRN command.
check_etrn_access type:table
Search the specified access database for the ETRN domain name or its parent
domains. See the access(5) manual page for details.
❍ SMTP command specific restrictions described under smtpd_client_restrictions
and smtpd_helo_restrictions.
Example:
smtpd_etrn_restrictions = permit_mynetworks, reject
smtpd_expansion_filter (default: see "postconf -d" output)
What characters are allowed in $name expansions of RBL reply templates. Characters
not in the allowed set are replaced by "_". Use C like escapes to specify special
characters such as whitespace.
This parameter is not subjected to $parameter expansion.
smtpd_forbidden_commands (default: CONNECT, GET, POST)
List of commands that causes the Postfix SMTP server to immediately terminate the
session with a 221 code. This can be used to disconnect clients that obviously attempt to
abuse the system. In addition to the commands listed in this parameter, commands that
follow the "Label:" format of message headers will also cause a disconnect.

smtpd_hard_error_limit (default: 20)
The maximal number of errors a remote SMTP client is allowed to make without
delivering mail. The Postfix SMTP server disconnects when the limit is exceeded.
smtpd_helo_required (default: no)
Require that a remote SMTP client introduces itself at the beginning of an SMTP
session with the HELO or EHLO command.
Example:
smtpd_helo_required = yes
smtpd_helo_restrictions (default: empty)
Optional restrictions that the Postfix SMTP server applies in the context of the SMTP
HELO command.
The default is to permit everything.

The following restrictions are specific to the hostname information received with the
HELO or EHLO command.
check_helo_access type:table
Search the specified access(5) database for the HELO or EHLO hostname or
parent domains, and execute the corresponding action.
check_helo_mx_access type:table
Search the specified access(5) database for the MX hosts for the HELO or EHLO
hostname, and execute the corresponding action. Note: a result of "OK" is not
allowed for safety reasons. Instead, use DUNNO in order to exclude specific
hosts from blacklists. This feature is available in Postfix 2.1 and later.
check_helo_ns_access type:table
Search the specified access(5) database for the DNS servers for the HELO or
EHLO hostname, and execute the corresponding action. Note: a result of "OK" is
not allowed for safety reasons. Instead, use DUNNO in order to exclude specific

reject_invalid_hostname
Reject the request when the HELO or EHLO hostname syntax is invalid.
The invalid_hostname_reject_code specifies the response code to rejected
requests (default: 501).
reject_non_fqdn_hostname
Reject the request when the HELO or EHLO hostname is not in fully-qualified
domain form, as required by the RFC.
The non_fqdn_reject_code parameter specifies the response code to rejected
reject_unknown_hostname
Reject the request when the HELO or EHLO hostname has no DNS A or MX
record.
The unknown_hostname_reject_code specifies the response code to rejected
❍ Client hostname or network address specific restrictions described under
smtpd_client_restrictions.
❍ SMTP command specific restrictions described under smtpd_sender_restrictions
or smtpd_recipient_restrictions. When sender or recipient restrictions are listed
under smtpd_helo_restrictions, they have effect only with "smtpd_delay_reject =
yes", so that $smtpd_helo_restrictions is evaluated at the time of the RCPT TO
command.
Examples:
smtpd_helo_restrictions = permit_mynetworks,
reject_invalid_hostname
smtpd_helo_restrictions = permit_mynetworks,
smtpd_history_flush_threshold (default: 100)
The maximal number of lines in the Postfix SMTP server command history before it is
flushed upon receipt of EHLO, RSET, or end of DATA.

smtpd_junk_command_limit (default: 100)
The number of junk commands (NOOP, VRFY, ETRN or RSET) that a remote SMTP
client can send before the Postfix SMTP server starts to increment the error counter with
each junk command. The junk command count is reset after mail is delivered. See also
the smtpd_error_sleep_time and smtpd_soft_error_limit configuration parameters.
smtpd_noop_commands (default: empty)
List of commands that the Postfix SMTP server replies to with "250 Ok", without doing
any syntax checks and without changing state. This list overrides any commands built
into the Postfix SMTP server.
smtpd_null_access_lookup_key (default: <>)
The lookup key to be used in SMTP access(5) tables instead of the null sender address.
smtpd_policy_service_max_idle (default: 300s)
The time after which an idle SMTPD policy service connection is closed.
smtpd_policy_service_max_ttl (default: 1000s)
The time after which an active SMTPD policy service connection is closed.
smtpd_policy_service_timeout (default: 100s)
The time limit for connecting to, writing to or receiving from a delegated SMTPD
policy server.
smtpd_proxy_ehlo (default: $myhostname)
How the Postfix SMTP server announces itself to the proxy filter. By default, the
Postfix hostname is used.

smtpd_proxy_filter (default: empty)
The hostname and TCP port of the mail filtering proxy server. The proxy receives all
mail from the Postfix SMTP server, and is supposed to give the result to another Postfix
SMTP server process.
Specify host:port. The host can be specified as an IP address or as a symbolic name; no

MX lookups are done. When no host or host: are specified, the local machine is
assumed.
smtpd_proxy_timeout (default: 100s)
The time limit for connecting to a proxy filter and for sending or receiving information.
When a connection fails the client gets a generic error message while more detailed
information is logged to the maillog file.
smtpd_recipient_limit (default: 1000)
The maximal number of recipients that the Postfix SMTP server accepts per message
delivery request.
smtpd_recipient_overshoot_limit (default: 1000)
The number of recipients that a remote SMTP client can send in excess of the limit
specified with $smtpd_recipient_limit, before the Postfix SMTP server increments the
per-session error count for each excess recipient.
smtpd_recipient_restrictions (default: permit_mynetworks, reject_unauth_destination)
The access restrictions that the Postfix SMTP server applies in the context of the RCPT
TO command.

By default, the Postfix SMTP server accepts:
❍ Mail from clients whose IP address matches $mynetworks, or:

❍ Mail to remote destinations that match $relay_domains, except for addresses that
contain sender-specified routing (user@elsewhere@domain), or:
❍ Mail to local destinations that match $inet_interfaces or $proxy_interfaces,
$mydestination, $virtual_alias_domains, or $virtual_mailbox_domains.
IMPORTANT: If you change this parameter setting, you must specify at least one of the
following restrictions. Otherwise Postfix will refuse to receive mail:
reject, defer, defer_if_permit,

reject_unauth_destination

The following restrictions are specific to the recipient address that is received with the
RCPT TO command.
check_recipient_access type:table
Search the specified access(5) database for the resolved RCPT TO address,
domain, parent domains, or localpart@, and execute the corresponding action.
check_recipient_mx_access type:table
Search the specified access(5) database for the MX hosts for the RCPT TO
address, and execute the corresponding action. Note: a result of "OK" is not
check_recipient_ns_access type:table
Search the specified access(5) database for the DNS servers for the RCPT TO
permit_auth_destination
Permit the request when one of the following is true:
■ Postfix is mail forwarder: the resolved RCPT TO address matches
$relay_domains or a subdomain thereof, and the address contains no

sender-specified routing (user@elsewhere@domain),

Postfix is the final destination: the resolved RCPT TO address matches

■
$mydestination, $inet_interfaces, $proxy_interfaces,

$virtual_alias_domains, or $virtual_mailbox_domains, and the address
contains no sender-specified routing (user@elsewhere@domain).
permit_mx_backup
Permit the request when the local mail system is MX host for the RCPT TO
address. This includes the case that the local mail system is the final destination.
However, the SMTP server will not forward mail with addresses that have
sender-specified routing information (example: user@elsewhere@domain). Use
the optional permit_mx_backup_networks parameter to require that the primary
MX hosts match a list of network blocks.
NOTE: prior to Postfix version 2.0, use of permit_mx_backup is not
recommended; mail may be rejected in case of a temporary DNS lookup
problem.
reject_non_fqdn_recipient
Reject the request when the RCPT TO address is not in fully-qualified domain
form, as required by the RFC.
reject_rhsbl_recipient rbl_domain=d.d.d.d
Reject the request when the RCPT TO domain is listed with the A record "d.d.d.
d" under rbl_domain (Postfix version 2.1 and later only). If no "=d.d.d.d" is
with any A record under rbl_domain.
requests (default: 554); the default_rbl_reply parameter specifies the default
server reply; and the rbl_reply_maps parameter specifies tables with server
Reject the request unless one of the following is true:
■ Postfix is mail forwarder: the resolved RCPT TO address matches
$relay_domains or a subdomain thereof, and contains no sender-specified

routing (user@elsewhere@domain),
■ Postfix is the final destination: the resolved RCPT TO address matches
$mydestination, $inet_interfaces, $proxy_interfaces,

$virtual_alias_domains, or $virtual_mailbox_domains, and contains no
sender-specified routing (user@elsewhere@domain).
The relay_domains_reject_code parameter specifies the response code for
rejected requests (default: 554).
reject_unknown_recipient_domain
Reject the request when the RCPT TO address has no DNS A or MX record and

Postfix is not final destination for the recipient address.

The unknown_address_reject_code parameter specifies the response code for
rejected requests (default: 450). The response is always 450 in case of a
temporary DNS error.
reject_unlisted_recipient (Postfix 2.0 name: check_recipient_maps)
Reject the request when the RCPT TO address is not listed in the list of valid
recipients for its domain class. See the smtpd_reject_unlisted_recipient
parameter description for details. This feature is available in Postfix 2.1 and later.
reject_unverified_recipient
Reject the request when mail to the RCPT TO address is known to bounce, or
when the recipient address destination is not reachable. Address verification
information is managed by the verify(8) server; see the
ADDRESS_VERIFICATION_README file for details.
The unverified_recipient_reject_code parameter specifies the response when an
address is known to bounce (default: 450, change into 550 when you are
confident that it is safe to do so). Postfix replies with 450 when an address probe
failed due to a temporary problem. This feature is available in Postfix 2.1 and
later.
❍ SMTP command specific restrictions described under smtpd_client_restrictions,
smtpd_helo_restrictions and smtpd_sender_restrictions.
Example:
smtpd_recipient_restrictions = permit_mynetworks,
smtpd_reject_unlisted_recipient (default: yes)
Request that the Postfix SMTP server rejects mail for unknown recipient addresses,
even when no explicit reject_unlisted_recipient access restriction is specified. This
prevents the Postfix queue from filling up with undeliverable MAILER-DAEMON
messages.
❍ The recipient domain matches $mydestination, $inet_interfaces or

$proxy_interfaces, but the recipient is not listed in $local_recipient_maps, and

$local_recipient_maps is not null.

❍ The recipient domain matches $virtual_alias_domains but the recipient is not
listed in $virtual_alias_maps.
❍ The recipient domain matches $virtual_mailbox_domains but the recipient is not
listed in $virtual_mailbox_maps, and $virtual_mailbox_maps is not null.
❍ The recipient domain matches $relay_domains but the recipient is not listed in
$relay_recipient_maps, and $relay_recipient_maps is not null.
smtpd_reject_unlisted_sender (default: no)
Request that the Postfix SMTP server rejects mail from unknown sender addresses,
even when no explicit reject_unlisted_sender access restriction is specified. This can
slow down an explosion of forged mail from worms or viruses.
❍ The sender domain matches $mydestination, $inet_interfaces or

$proxy_interfaces, but the recipient is not listed in $local_recipient_maps, and
$local_recipient_maps is not null.
❍ The sender domain matches $virtual_alias_domains but the recipient is not listed
in $virtual_alias_maps.
❍ The sender domain matches $virtual_mailbox_domains but the recipient is not
listed in $virtual_mailbox_maps, and $virtual_mailbox_maps is not null.
❍ The sender domain matches $relay_domains but the recipient is not listed in
$relay_recipient_maps, and $relay_recipient_maps is not null.
smtpd_restriction_classes (default: empty)
User-defined aliases for groups of access restrictions. The aliases can be specified in
smtpd_recipient_restrictions etc., and on the right-hand side of a Postfix access(5) table.
One major application is for implementing per-recipient UCE control. See the
RESTRICTION_CLASS_README document for other examples.
smtpd_sasl_application_name (default: smtpd)
The application name used for SASL server initialization. This controls the name of the

SASL configuration file. The default value is smtpd, corresponding to a SASL

configuration file named smtpd.conf.
smtpd_sasl_auth_enable (default: no)
Enable SASL authentication in the Postfix SMTP server. By default, the Postfix SMTP
server does not use authentication.
If a remote SMTP client is authenticated, the permit_sasl_authenticated access

restriction can be used to permit relay access, like this:
smtpd_recipient_restrictions =
permit_mynetworks, permit_sasl_authenticated, ...
To reject all SMTP connections from unauthenticated clients, specify

"smtpd_delay_reject = yes" (which is the default) and use:
smtpd_client_restrictions = permit_sasl_authenticated,
reject
See the SASL_README file for SASL configuration and operation details.
smtpd_sasl_exceptions_networks (default: empty)
What SMTP clients Postfix will not offer AUTH support to.
Some clients (Netscape 4 at least) have a bug that causes them to require a login and
password whenever AUTH is offered, whether it's necessary or not. To work around
this, specify, for example, $mynetworks to prevent Postfix from offering AUTH to local
clients.

also "/file/name" or "type:table" patterns. A "/file/name" pattern is replaced by its
contents; a "type:table" lookup table is matched when a table entry matches a lookup
string (the lookup result is ignored). Continue long lines by starting the next line with
whitespace.

Example:
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_local_domain (default: empty)
The name of the local SASL authentication realm.
By default, the local authentication realm name is the null string.
Examples:
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_security_options (default: noanonymous)
Restrict what authentication mechanisms the Postfix SMTP server will offer to the
client. The list of available authentication mechanisms is system dependent.
Specify zero or more of the following:
noplaintext
Disallow methods that use plaintext passwords.
noactive
Disallow methods subject to active (non-dictionary) attack.
nodictionary
Disallow methods subject to passive (dictionary) attack.
noanonymous
Disallow methods that allow anonymous authentication.
mutual_auth
Only allow methods that provide mutual authentication (not available with SASL
version 1).
By default, the Postfix SMTP server accepts plaintext passwords but not anonymous
logins.
Warning: it appears that clients try authentication methods in the order as advertised by

the server (e.g., PLAIN ANONYMOUS CRAM-MD5) which means that if you disable
plaintext passwords, clients will log in anonymously, even when they should be able to
use CRAM-MD5. So, if you disable plaintext logins, disable anonymous logins too.
Postfix treats anonymous login as no authentication.
Example:
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options (default: $smtpd_sasl_security_options)
The SASL authentication security options that the Postfix SMTP server uses for TLS
encrypted SMTP sessions.
smtpd_sender_login_maps (default: empty)
Optional lookup table with the SASL login names that own sender (MAIL FROM)
addresses.
Specify zero or more "type:table" lookup tables. With lookups from indexed files such
as DB or DBM, or from networked tables such as NIS, LDAP or SQL, the following
search operations are done with a sender address of user@domain:
1) user@domain
This table lookup is always done and has the highest precedence.
2) user
This table lookup is done only when the domain part of the sender address
matches $myorigin, $mydestination, $inet_interfaces or $proxy_interfaces.
3) @domain
This table lookup is done last and has the lowest precedence.
In all cases the result of table lookup must be either "not found" or a list of SASL login
names separated by comma and/or whitespace.
smtpd_sender_restrictions (default: empty)
Optional restrictions that the Postfix SMTP server applies in the context of the MAIL
FROM command.
The default is to permit everything.


The following restrictions are specific to the sender address received with the MAIL
FROM command.
check_sender_access type:table
Search the specified access(5) database for the MAIL FROM address, domain,
parent domains, or localpart@, and execute the corresponding action.
check_sender_mx_access type:table
Search the specified access(5) database for the MX hosts for the MAIL FROM
check_sender_ns_access type:table
Search the specified access(5) database for the DNS servers for the MAIL
FROM address, and execute the corresponding action. Note: a result of "OK" is
not allowed for safety reasons. Instead, use DUNNO in order to exclude specific
reject_authenticated_sender_login_mismatch
Enforces the reject_sender_login_mismatch restriction for authenticated clients
only. This feature is available in Postfix version 2.1 and later.
reject_non_fqdn_sender
Reject the request when the MAIL FROM address is not in fully-qualified
domain form, as required by the RFC.
reject_rhsbl_sender rbl_domain=d.d.d.d
Reject the request when the MAIL FROM domain is listed with the A record "d.
d.d.d" under rbl_domain (Postfix version 2.1 and later only). If no "=d.d.d.d" is
with any A record under rbl_domain.
requests (default: 554); the default_rbl_reply parameter specifies the default
server reply; and the rbl_reply_maps parameter specifies tables with server
reject_sender_login_mismatch
Reject the request when $smtpd_sender_login_maps specifies an owner for the
MAIL FROM address, but the client is not (SASL) logged in as that MAIL
FROM address owner; or when the client is (SASL) logged in, but the client

login name doesn't own the MAIL FROM address according to

$smtpd_sender_login_maps.
reject_unauthenticated_sender_login_mismatch
Enforces the reject_sender_login_mismatch restriction for unauthenticated
clients only. This feature is available in Postfix version 2.1 and later.
reject_unknown_sender_domain
Reject the request when the MAIL FROM address has no DNS A or MX record
and Postfix is not final destination for the sender address.
The unknown_address_reject_code parameter specifies the response code for
rejected requests (default: 450). The response is always 450 in case of a
temporary DNS error.
reject_unlisted_sender
Reject the request when the MAIL FROM address is not listed in the list of valid
recipients for its domain class. See the smtpd_reject_unlisted_sender parameter
description for details. This feature is available in Postfix 2.1 and later.
reject_unverified_sender
Reject the request when mail to the MAIL FROM address is known to bounce,
or when the sender address destination is not reachable. Address verification
information is managed by the verify(8) server; see the
ADDRESS_VERIFICATION_README file for details.
The unverified_sender_reject_code parameter specifies the response when an
address is known to bounce (default: 450, change into 550 when you are
confident that it is safe to do so). Postfix replies with 450 when an address probe
failed due to a temporary problem. This feature is available in Postfix 2.1 and
later.
❍ SMTP command specific restrictions described under smtpd_client_restrictions
and smtpd_helo_restrictions.
❍ SMTP command specific restrictions described under
smtpd_recipient_restrictions. When recipient restrictions are listed under
smtpd_sender_restrictions, they have effect only with "smtpd_delay_reject =
yes", so that $smtpd_sender_restrictions is evaluated at the time of the RCPT TO
command.
Examples:

smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_sender_restrictions = reject_unknown_sender_domain,
check_sender_access hash:/etc/postfix/access
smtpd_soft_error_limit (default: 10)
The number of errors a remote SMTP client is allowed to make without delivering mail
before the Postfix SMTP server slows down all its responses.
❍ With Postfix version 2.1 and later, the Postfix SMTP server delays all responses
by $smtpd_error_sleep_time seconds.
❍ With Postfix versions 2.0 and earlier, the Postfix SMTP server delays all
responses by (number of errors) seconds.
smtpd_starttls_timeout (default: 300s)
The time limit for Postfix SMTP server write and read operations during TLS startup
and shutdown handshake procedures.
smtpd_timeout (default: 300s)
The time limit for sending a Postfix SMTP server response and for receiving a remote
SMTP client request.
Note: if you set SMTP time limits to very large values you may have to update the
global ipc_timeout parameter.
smtpd_tls_CAfile (default: empty)
The file with the certificate of the certification authority (CA) that issued the Postfix
SMTP server certificate. This is needed only when the CA certificate is not already
present in the server certificate file. This file may also contain the CA certificates of
other trusted CAs. You must use this file for the list of trusted CAs if you want to use
chroot-mode.
Example:

smtpd_tls_CAfile = /etc/postfix/CAcert.pem
smtpd_tls_CApath (default: empty)
Directory with PEM format certificate authority certificates that the Postfix SMTP
server offers to remote SMTP clients for the purpose of client certificate verification.
Do not forget to create the necessary "hash" links with, for example,
"$OPENSSL_HOME/bin/c_rehash /etc/postfix/certs".
To use this option in chroot mode, this directory (or a copy) must be inside the chroot
jail. Please note that in this case the CA certificates are not offered to the client, so that e.
g. Netscape clients might not offer certificates issued by them. Use of this feature is
therefore not recommended.
Example:
smtpd_tls_CApath = /etc/postfix/certs
smtpd_tls_ask_ccert (default: no)
Ask a remote SMTP client for a client certificate. This information is needed for
certificate based mail relaying with, for example, the permit_tls_clientcerts feature.
Some clients such as Netscape will either complain if no certificate is available (for the
list of CAs in /etc/postfix/certs) or will offer multiple client certificates to choose from.
This may be annoying, so this option is "off" by default.
smtpd_tls_auth_only (default: no)
When TLS encryption is optional in the Postfix SMTP server, do not announce or
accept SASL authentication over unencrypted connections.
smtpd_tls_ccert_verifydepth (default: 5)
The verification depth for remote SMTP client certificates. A depth of 1 is sufficient if
the issuing CA is listed in a local CA file. The default value should also suffice for
longer chains (the root CA issues special CA which then issues the actual certificate...).
smtpd_tls_cert_file (default: empty)

File with the Postfix SMTP server RSA certificate in PEM format. This file may also
Both RSA and DSA certificates are supported. When both types are present, the cipher
used determines which certificate will be presented to the client. For Netscape and
OpenSSL clients without special cipher choices the RSA certificate is preferred.
In order to verify a certificate, the CA certificate (in case of a certificate chain, all CA
certificates) must be available. You should add these certificates to the server certificate,
the server certificate first, then the issuing CA(s).
Example: the certificate for "server.dom.ain" was issued by "intermediate CA" which
itself has a certificate of "root CA". Create the server.pem file with "cat server_cert.pem
intermediate_CA.pem root_CA.pem > server.pem".
If you want to accept certificates issued by these CAs yourself, you can also add the CA
certificates to the smtpd_tls_CAfile, in which case it is not necessary to have them in
the smtpd_tls_dcert_file or smtpd_tls_cert_file.
A certificate supplied here must be usable as SSL server certificate and hence pass the
"openssl verify -purpose sslserver ..." test.
Example:
smtpd_tls_cert_file = /etc/postfix/server.pem
smtpd_tls_cipherlist (default: empty)
Controls the Postfix SMTP server TLS cipher selection scheme. For details, see the
OpenSSL documentation. Note: do not use "" quotes around the parameter value.
smtpd_tls_dcert_file (default: empty)
File with the Postfix SMTP server DSA certificate in PEM format. This file may also
See the discussion under smtpd_tls_cert_file for more details.
Example:

smtpd_tls_dcert_file = /etc/postfix/server-dsa.pem
smtpd_tls_dh1024_param_file (default: empty)
File with DH parameters that the Postfix SMTP server should use with EDH ciphers.
Instead of using the exact same parameter sets as distributed with other TLS packages,
it is more secure to generate your own set of parameters with something like the
following command:
openssl gendh -out /etc/postfix/dh_1024.pem -2 -rand /var/

run/egd-pool 1024
Your actual source for entropy may differ. Some systems have /dev/random; on other
system you may consider using the "Entropy Gathering Daemon EGD", available at
http://www.lothar.com/tech/crypto/.
Example:
smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem
smtpd_tls_dh512_param_file (default: empty)
File with DH parameters that the Postfix SMTP server should use with EDH ciphers.
See also the discussion under the smtpd_tls_dh1024_param_file configuration

parameter.
Example:
smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
smtpd_tls_dkey_file (default: $smtpd_tls_dcert_file)
File with the Postfix SMTP server DSA private key in PEM format. This file may be
combined with the server certificate file specified with $smtpd_tls_dcert_file.
without password.

smtpd_tls_key_file (default: $smtpd_tls_cert_file)
File with the Postfix SMTP server RSA private key in PEM format. This file may be
combined with the server certificate file specified with $smtpd_tls_cert_file.
without password.
smtpd_tls_loglevel (default: 0)
Enable additional Postfix SMTP server logging of TLS activity. Each logging level also
includes the information that is logged at a lower logging level.

3 Log hexadecimal and ASCII dump of TLS negotiation process.
4 Also log hexadecimal and ASCII dump of complete transmission after
STARTTLS.
Use "smtpd_tls_loglevel = 3" only in case of problems. Use of loglevel 4 is strongly

discouraged.
smtpd_tls_received_header (default: no)
Request that the Postfix SMTP server produces Received: message headers that include
information about the protocol and cipher used, as well as the client CommonName and
client certificate issuer CommonName. This is disabled by default, as the information
may be modified in transit through other mail servers. Only information that was
recorded by the final destination can be trusted.
smtpd_tls_req_ccert (default: no)
When TLS encryption is enforced, require a remote SMTP client certificate in order to
allow TLS connections to proceed. This option implies "smtpd_tls_ask_ccert = yes".
When TLS encryption is optional, remote SMTP clients can bypass the restriction by
simply not using STARTTLS at all. For this reason a TLS connection will be handled as
if only "smtpd_tls_ask_ccert = yes" is specified.

smtpd_tls_session_cache_database (default: empty)
Name of the file containing the optional Postfix SMTP server TLS session cache.
Specify a database type that supports enumeration, such as btree or sdbm; there is no
need to support concurrent access. The file is created if it does not exist.
NOTE: dbm databases are not suitable. TLS session objects are too large.
Example:
smtpd_tls_session_cache_database = btree:/var/postfix/
smtpd_scache
smtpd_tls_session_cache_timeout (default: 3600s)
The expiration time of Postfix SMTP server TLS session cache information. A cache
cleanup is performed periodically every $smtpd_tls_session_cache_timeout seconds.
smtpd_tls_wrappermode (default: no)
Run the Postfix SMTP server in the non-standard "wrapper" mode, instead of using the
STARTTLS command.
If you want to support this service, enable a special port in master.cf, and specify "-o
smtpd_tls_wrappermode=yes" on the SMTP server's command line. Port 465 (smtps)
was once chosen for this purpose.
smtpd_use_tls (default: no)
Opportunistic mode: announce STARTTLS support to SMTP clients, but do not require
that clients use TLS encryption.
Note: when invoked via "sendmail -bs", Postfix will never offer STARTTLS due to
soft_bounce (default: no)
Safety net to keep mail queued that would otherwise be returned to the sender. This
parameter disables locally-generated bounces, and prevents the Postfix SMTP server
from rejecting mail permanently, by changing 5xx reply codes into 4xx. However,

soft_bounce is no cure for address rewriting mistakes or mail routing mistakes.
Example:
soft_bounce = yes
stale_lock_time (default: 500s)
The time after which a stale exclusive mailbox lockfile is removed. This is used for
delivery to file or mailbox.
strict_7bit_headers (default: no)
Reject mail with 8-bit text in message headers. This blocks mail from poorly written
applications.
This feature should not be enabled on a general purpose mail server, because it is likely
to reject legitimate email.
strict_8bitmime (default: no)
Enable both strict_7bit_headers and strict_8bitmime_body.
strict_8bitmime_body (default: no)
Reject 8-bit message body text without 8-bit MIME content encoding information. This
blocks mail from poorly written applications.
Unfortunately, this also rejects majordomo approval requests when the included request
contains valid 8-bit MIME mail, and it rejects bounces from mailers that do not MIME

encapsulate 8-bit content (for example, bounces from qmail or from old versions of
Postfix).
strict_mime_encoding_domain (default: no)
Reject mail with invalid Content-Transfer-Encoding: information for the message/* or

multipart/* MIME content types. This blocks mail from poorly written software.
This feature should not be enabled on a general purpose mail server, because it will
reject mail after a single violation.
strict_rfc821_envelopes (default: no)
Require that addresses received in SMTP MAIL FROM and RCPT TO commands are
enclosed with <>, and that those addresses do not contain RFC 822 style comments or
phrases. This stops mail from poorly written software.
By default, the Postfix SMTP server accepts RFC 822 syntax in MAIL FROM and
RCPT TO addresses.
sun_mailtool_compatibility (default: no)
Obsolete SUN mailtool compatibility feature. Instead, use "mailbox_delivery_lock =

dotlock".
swap_bangpath (default: yes)
Enable the rewriting of "site!user" into "user@site". This is necessary if your machine is
connected to UUCP networks. It is enabled by default.
Example:
swap_bangpath = no

syslog_facility (default: mail)
The syslog facility of Postfix logging. Specify a facility as defined in syslog.conf(5).

The default facility is "mail".
Warning: a non-default syslog_facility setting takes effect only after a Postfix process
has completed initialization. Errors during process initialization will be logged with the
default facility. Examples are errors while parsing the command line arguments, and
errors while accessing the Postfix main.cf configuration file.
syslog_name (default: postfix)
The mail system name that is prepended to the process name in syslog records, so that
"smtpd" becomes, for example, "postfix/smtpd".
Warning: a non-default syslog_name setting takes effect only after a Postfix process has
completed initialization. Errors during process initialization will be logged with the
default name. Examples are errors while parsing the command line arguments, and
errors while accessing the Postfix main.cf configuration file.
tls_daemon_random_bytes (default: 32)
The number of pseudo-random bytes that an smtp(8) or smtpd(8) process requests from
the tlsmgr(8) server in order to seed its internal pseudo random number generator
(PRNG). The default of 32 bytes (equivalent to 256 bits) is sufficient to generate a
128bit (or 168bit) session key.
tls_random_bytes (default: 32)
The number of bytes that tlsmgr(8) reads from $tls_random_source when (re)seeding
the in-memory pseudo random number generator (PRNG) pool. The default of 32 bytes
(256 bits) is good enough for 128bit symmetric keys. If using EGD or a device file, a
maximum of 255 bytes is read.
tls_random_exchange_name (default: ${config_directory}/prng_exch)
Name of the pseudo random number generator (PRNG) state file that is maintained by
tlsmgr(8). The file is created when it does not exist, and its length is fixed at 1024 bytes.

Since this file is modified by Postfix, it should probably be kept in the /var file system,
instead of under $config_directory. The location should not be inside the chroot jail.
tls_random_prng_update_period (default: 3600s)
The time between attempts by tlsmgr(8) to save the state of the pseudo random number
generator (PRNG) to the file specified with $tls_random_exchange_name.
tls_random_reseed_period (default: 3600s)
The maximal time between attempts by tlsmgr(8) to re-seed the in-memory pseudo
random number generator (PRNG) pool from external sources. The actual time between
re-seeding attempts is calculated using the PRNG, and is between 0 and the time
specified.
tls_random_source (default: see "postconf -d" output)
The external entropy source for the in-memory tlsmgr(8) pseudo random number
generator (PRNG) pool. Be sure to specify a non-blocking source. If this source is not a
regular file, the entropy source type must be prepended: egd:/path/to/egd_socket for a
source with EGD compatible socket interface, or dev:/path/to/device for a device file.
trace_service_name (default: trace)
The name of the trace(8) service. This service maintains a record of mail deliveries and
produces a mail delivery report when verbose delivery is requested with "sendmail -v".
transport_maps (default: empty)
Optional lookup tables with mappings from recipient address to (message delivery
transport, next-hop destination). See transport(5) for details.
Specify zero or more "type:table" lookup tables. If you use this feature with local files,
run "postmap /etc/postfix/transport" after making a change.
Examples:
transport_maps = dbm:/etc/postfix/transport

transport_maps = hash:/etc/postfix/transport
transport_retry_time (default: 60s)
The time between attempts by the Postfix queue manager to contact a malfunctioning
message delivery transport.
trigger_timeout (default: 10s)
The time limit for sending a trigger to a Postfix daemon (for example, the pickup(8) or
qmgr(8) daemon). This time limit prevents programs from getting stuck when the mail
system is under heavy load.
undisclosed_recipients_header (default: To: undisclosed-recipients:;)
Message header that the Postfix cleanup(8) server inserts when a message contains no
To: or Cc: message header.
unknown_address_reject_code (default: 450)
The numerical Postfix SMTP server response code when a sender or recipient address is
rejected by the reject_unknown_sender_domain or reject_unknown_recipient_domain
restriction.
unknown_client_reject_code (default: 450)
The numerical Postfix SMTP server response code when a client without valid address
<=> name mapping is rejected by the reject_unknown_client restriction. The SMTP
server always replies with 450 when the mapping failed due to a temporary error
condition.

unknown_hostname_reject_code (default: 450)
The numerical Postfix SMTP server response code when the hostname specified with
the HELO or EHLO command is rejected by the reject_unknown_hostname restriction.
unknown_local_recipient_reject_code (default: 550)
The numerical Postfix SMTP server response code when a recipient address is local,
and $local_recipient_maps specifies a list of lookup tables that does not match the
recipient. A recipient address is local when its domain matches $mydestination,
$proxy_interfaces or $inet_interfaces.
The default setting is 550 (reject mail) but it is safer to initially use 450 (try again later)
so you have time to find out if your local_recipient_maps settings are OK.
Example:
unknown_local_recipient_reject_code = 450
unknown_relay_recipient_reject_code (default: 550)
The numerical Postfix SMTP server reply code when a recipient address matches
$relay_domains, and relay_recipient_maps specifies a list of lookup tables that does not
match the recipient address.
unknown_virtual_alias_reject_code (default: 550)
The SMTP server reply code when a recipient address matches $virtual_alias_domains,
and $virtual_alias_maps specifies a list of lookup tables that does not match the
recipient address.

unknown_virtual_mailbox_reject_code (default: 550)
The SMTP server reply code when a recipient address matches

$virtual_mailbox_domains, and $virtual_mailbox_maps specifies a list of lookup tables
that does not match the recipient address.
unverified_recipient_reject_code (default: 450)
The numerical Postfix SMTP server response when a recipient address is rejected by the
reject_unverified_recipient restriction.
Unlike elsewhere in Postfix, you can specify 250 in order to accept the address anyway.
unverified_sender_reject_code (default: 450)
The numerical Postfix SMTP server response code when a recipient address is rejected
by the reject_unverified_sender restriction.
Unlike elsewhere in Postfix, you can specify 250 in order to accept the address anyway.
verp_delimiter_filter (default: -=+)
The characters Postfix accepts as VERP delimiter characters on the Postfix sendmail(1)
command line and in SMTP commands.
virtual_alias_domains (default: $virtual_alias_maps)

Postfix is final destination for the specified list of virtual alias domains, that is, domains
for which all addresses are aliased to addresses in other local or remote domains. The
SMTP server validates recipient addresses with $virtual_alias_maps and rejects non-
existent recipients. See also the virtual alias domain class in the
ADDRESS_CLASS_README file
This feature is available in Postfix 2.0 and later. The default value is backwards
The default value is $virtual_alias_maps so that you can keep all information about
virtual alias domains in one place. If you have many users, it is better to separate
information that changes more frequently (virtual address -> local or remote address
mapping) from information that changes less frequently (the list of virtual domain
names).
Specify a list of host or domain names, "/file/name" or "type:table" patterns, separated

by commas and/or whitespace. A "/file/name" pattern is replaced by its contents; a "type:
table" lookup table is matched when a table entry matches a lookup string (the lookup
result is ignored). Continue long lines by starting the next line with whitespace.
See also the VIRTUAL_README and ADDRESS_CLASS_README documents for

further information.
Example:
virtual_alias_domains = virtual1.tld virtual2.tld
virtual_alias_expansion_limit (default: 1000)
The maximal number of addresses that virtual alias expansion produces from each
original recipient.
virtual_alias_maps (default: $virtual_maps)
Optional lookup tables that alias specific mail addresses or domains to other local or
remote address. The table format and lookups are documented in virtual(5).

If you use this feature with indexed files, run "postmap /etc/postfix/virtual" after
changing the file.
Examples:
virtual_alias_maps = dbm:/etc/postfix/virtual
virtual_alias_recursion_limit (default: 1000)
The maximal nesting depth of virtual alias expansion. Currently the recursion limit is
applied only to the left branch of the expansion graph, so the depth of the tree can in the
worst case reach the sum of the expansion and recursion limits. This may change in the
future.
virtual_destination_concurrency_limit (default: $default_destination_concurrency_limit)
The maximal number of parallel deliveries to the same destination via the virtual
message delivery transport. This limit is enforced by the queue manager. The message
delivery transport name is the first field in the entry in the master.cf file.
virtual_destination_recipient_limit (default: $default_destination_recipient_limit)
The maximal number of recipients per delivery via the virtual message delivery
transport. This limit is enforced by the queue manager. The message delivery transport
name is the first field in the entry in the master.cf file.

virtual_destination_concurrency_limit from concurrency per domain into concurrency
per recipient.
virtual_gid_maps (default: empty)
Lookup tables with the per-recipient group ID for virtual(8) mailbox delivery.
In a lookup table, specify a left-hand side of "@domain.tld" to match any user in the

specified domain that does not have a specific "user@domain.tld" entry.
When a recipient address has an optional address extension (user+foo@domain.tld), the

virtual(8) delivery agent looks up the full address first, and when the lookup fails, it
looks up the unextended address (user@domain.tld).
Note 1: for security reasons, the virtual(8) delivery agent disallows regular expression
substitution of $1 etc. in regular expression lookup tables, because that would open a
security hole.
Note 2: for security reasons, the virtual(8) delivery agent will silently ignore requests to
use the proxymap(8) server. Instead it will open the table directly. Before Postfix
version 2.2, the virtual(8) delivery agent will terminate with a fatal error.
virtual_mailbox_base (default: empty)
A prefix that the virtual(8) delivery agent prepends to all pathname results from
$virtual_mailbox_maps table lookups. This is a safety measure to ensure that an out of
control map doesn't litter the file system with mailboxes. While virtual_mailbox_base
could be set to "/", this setting isn't recommended.
Example:
virtual_mailbox_base = /var/mail
virtual_mailbox_domains (default: $virtual_mailbox_maps)
Postfix is final destination for the specified list of domains; mail is delivered via the
$virtual_transport mail delivery transport. By default this is the Postfix virtual(8)
delivery agent. The SMTP server validates recipient addresses with
$virtual_mailbox_maps and rejects mail for non-existent recipients. See also the virtual
mailbox domain class in the ADDRESS_CLASS_README file.
This parameter expects the same syntax as the mydestination configuration parameter.
virtual_mailbox_limit (default: 51200000)

The maximal size in bytes of an individual mailbox or maildir file, or zero (no limit).
virtual_mailbox_lock (default: see "postconf -d" output)
How to lock a UNIX-style virtual(8) mailbox before attempting delivery. For a list of
available file locking methods, use the "postconf -l" command.
This setting is ignored with maildir style delivery, because such deliveries are safe
without application-level locks.
Note 1: The dotlock method requires that the recipient UID or GID has write access to
the parent directory of the recipient's mailbox file.
Note 2: the default setting of this parameter is system dependent.
virtual_mailbox_maps (default: empty)
Optional lookup tables with all valid addresses in the domains that match
$virtual_mailbox_domains.
The virtual(8) delivery agent uses this table to look up the per-recipient mailbox or
maildir pathname. If the lookup result ends in a slash ("/"), maildir-style delivery is
carried out, otherwise the path is assumed to specify a UNIX-style mailbox file. Note
that $virtual_mailbox_base is unconditionally prepended to this path.

security hole.

virtual_maps (default: empty)
Optional lookup tables with a) names of domains for which all addresses are aliased to
addresses in other local or remote domains, and b) addresses that are aliased to
addresses in other local or remote domains. Available before Postfix version 2.0. With
Postfix 2.1 and later, this is replaced by separate controls: virtual_alias_domains and
virtual_alias_maps.
virtual_minimum_uid (default: 100)
The minimum user ID value that the virtual(8) delivery agent accepts as a result from
$virtual_uid_maps table lookup. Returned values less than this will be rejected, and
the message will be deferred.
virtual_transport (default: virtual)
The default mail delivery transport for domains that match the
$virtual_mailbox_domains parameter value. This information can be overruled with the
transport(5) table.
virtual_uid_maps (default: empty)
Lookup tables with the per-recipient user ID that the virtual(8) delivery agent uses while
writing to the recipient's mailbox.


security hole.

Postfix manual - access(5)
ACCESS(5) ACCESS
(5)
NAME
access - format of Postfix access table
SYNOPSIS
postmap /etc/postfix/access
postmap -q "string" /etc/postfix/access
postmap -q - /etc/postfix/access <inputfile
DESCRIPTION
The optional access table directs the Postfix SMTP
server
to selectively reject or accept mail. Access can
be
allowed or denied for specific host names, domain
names,
networks, host network addresses or mail addresses.
For an example, see the EXAMPLE section at the end of

this
manual page.
Normally, the access table is specified as a text

file
that serves as input to the postmap(1) command.
The
result, an indexed file in dbm or db format, is used
for
fast searching by the mail system. Execute the
command
"postmap /etc/postfix/access" in order to rebuild
the
indexed file after changing the access table.
When the table is provided via other means such as

NIS,
LDAP or SQL, the same lookups are done as for
http://www.subneural.net/postfix-master/access.5.html (1 of 12)01/16/2005 15:45:59

ordinary
indexed files.
Alternatively, the table can be provided as a

regular-
expression map where patterns are given as regular
expres-
sions, or lookups can be directed to TCP-based server.
In
that case, the lookups are done in a slightly
different
way as described below under "REGULAR EXPRESSION
TABLES"
and "TCP-BASED TABLES".
TABLE FORMAT
The input format for the postmap(1) command is as
follows:
pattern action
When pattern matches a mail address, domain or
host
address, perform the corresponding action.
blank lines and comments

Empty lines and whitespace-only lines are
ignored,
as are lines whose first non-whitespace
character
is a `#'.
multi-line text
A logical line starts with non-whitespace text.
A
line that starts with whitespace continues a
logi-
cal line.
EMAIL ADDRESS PATTERNS

With lookups from indexed files such as DB or DBM, or
from
networked tables such as NIS, LDAP or SQL, patterns

are
tried in the order as listed below:
user@domain
Matches the specified mail address.
domain.tld
Matches domain.tld as the domain part of an
email
address.
The pattern domain.tld also matches subdomains,

but
only when the string smtpd_access_maps is listed
in
the Postfix parent_domain_matches_subdomains
con-
figuration setting (note that this is the
default
for some versions of Postfix). Otherwise,
specify
.domain.tld (note the initial dot) in order
to
match subdomains.
user@ Matches all mail addresses with the specified

user
part.
Note: lookup of the null sender address is not

possible
with some types of lookup table. By default, Postfix
uses
<> as the lookup key for such addresses. The value
is
specified with the smtpd_null_access_lookup_key
parameter
in the Postfix main.cf file.
EMAIL ADDRESS EXTENSION

When a mail address localpart contains the optional
recip-

ient delimiter (e.g., user+foo@domain), the lookup

order
becomes: user+foo@domain, user@domain, domain, user
+foo@,
and user@.
HOST NAME/ADDRESS PATTERNS

from
networked tables such as NIS, LDAP or SQL, the
following
lookup patterns are examined in the order as listed:
domain.tld
Matches domain.tld.
The pattern domain.tld also matches subdomains,

but
only when the string smtpd_access_maps is listed
in
the Postfix parent_domain_matches_subdomains
con-
figuration setting. Otherwise, specify .domain.
tld
(note the initial dot) in order to match
subdo-
mains.
net.work.addr.ess
net.work.addr
net.work
net Matches any host address in the specified

network.
A network address is a sequence of one or
more
octets separated by ".".
NOTE: use the cidr lookup table type to

specify

network/netmask patterns. See cidr_table(5)

for
details.
ACCEPT ACTIONS
OK Accept the address etc. that matches the pattern.
all-numerical
An all-numerical result is treated as OK. This
for-
mat is generated by address-based relay
authoriza-
tion schemes.
REJECT ACTIONS
4NN text
5NN text
Reject the address etc. that matches the
pattern,
and respond with the numerical three-digit code
and
text. 4NN means "try again later", while 5NN
means
"do not try again".
REJECT optional text...

Reject the address etc. that matches the
pattern.
Reply with $reject_code optional text... when
the
optional text is specified, otherwise reply with
a
generic error response message.
DEFER_IF_REJECT optional text...

Defer the request if some later restriction
would
result in a REJECT action. Reply with "450
optional
text... when the optional text is specified,
other-

wise reply with a generic error response message.
This feature is available in Postfix 2.1 and

later.
DEFER_IF_PERMIT optional text...

Defer the request if some later restriction
would
result in a an explicit or implicit PERMIT
action.
Reply with "450 optional text... when the
optional
text is specified, otherwise reply with a
generic
error response message.

later.
OTHER ACTIONS
restriction...
Apply the named UCE restriction(s) (permit,
reject,
reject_unauth_destination, and so on).
DISCARD optional text...

Claim successful delivery and silently discard
the
message. Log the optional text if specified,
oth-
erwise log a generic message.
Note: this action currently affects all

recipients
of the message.

later.
DUNNO Pretend that the lookup key was not found.

This
prevents Postfix from trying substrings of

the
lookup key (such as a subdomain name, or a
network
address subnetwork).

later.
FILTER transport:destination
After the message is queued, send the entire
mes-
sage through the specified external content
filter.
The transport:destination syntax is described
in
the transport(5) manual page. More
information
about external content filters is in the
Postfix
FILTER_README file.
Note: this action overrides the main.cf

con-
tent_filter setting, and currently affects
all
recipients of the message.

later.
HOLD optional text...

Place the message on the hold queue, where it
will
sit until someone either deletes it or releases
it
for delivery. Log the optional text if
specified,
otherwise log a generic message.
Mail that is placed on hold can be examined

with
the postcat(1) command, and can be destroyed

or
released with the postsuper(1) command.
Note: use "postsuper -r" to release mail that

was
kept on hold for a significant fraction of
$maxi-
mal_queue_lifetime or $bounce_queue_lifetime,
or
longer.
Note: this action currently affects all

recipients
of the message.

later.
PREPEND headername: headervalue

Prepend the specified message header to the
mes-
sage. When this action is used multiple times,
the
first prepended header appears before the
second
etc. prepended header.
Note: this action does not support multi-line

mes-
sage headers.

later.
REDIRECT user@domain
After the message is queued, send the message
to
the specified address instead of the
intended
recipient(s).
Note: this action overrides the FILTER action,

and
currently affects all recipients of the message.

later.
WARN optional text...

Log a warning with the optional text, together
with
client information and if available, with
helo,
sender, recipient and protocol information.

later.
REGULAR EXPRESSION TABLES

This section describes how the table lookups change
when
the table is given in the form of regular expressions.
For
a description of regular expression lookup table
syntax,
see regexp_table(5) or pcre_table(5).
Each pattern is a regular expression that is applied

to
the entire string being looked up. Depending on the
appli-
cation, that string is an entire client hostname,
an
entire client IP address, or an entire mail address.
Thus,
no parent domain or parent network search is
done,
user@domain mail addresses are not broken up into
their
user@ and domain constituent parts, nor is user+foo
broken
up into user and foo.
Patterns are applied in the order as specified in

the
table, until a pattern is found that matches the
search
string.
Actions are the same as with indexed file lookups,

with
the additional feature that parenthesized substrings
from
the pattern can be interpolated as $1, $2 and so on.
TCP-BASED TABLES
when
lookups are directed to a TCP-based server. For a
descrip-
tion of the TCP client/server lookup protocol,
see
tcp_table(5). This feature is not available in
Postfix
version 2.1.
Each lookup operation uses the entire query string

once.
Depending on the application, that string is an
entire
client hostname, an entire client IP address, or an
entire
mail address. Thus, no parent domain or parent
network
search is done, user@domain mail addresses are not
broken
up into their user@ and domain constituent parts, nor
is
user+foo broken up into user and foo.
Actions are the same as with indexed file lookups.
EXAMPLE
The following example uses an indexed file, so that
the
order of table entries does not matter. The example

per-
mits access by the client at address 1.2.3.4 but
rejects
all other clients in 1.2.3.0/24. Instead of hash
lookup
tables, some systems use dbm. Use the command
"postconf
-m" to find out what lookup tables Postfix supports
on
your system.
smtpd_client_restrictions =
check_client_access hash:/etc/postfix/access
/etc/postfix/access:
1.2.3 REJECT
1.2.3.4 OK
Execute the command "postmap /etc/postfix/access" after

editing the file.
BUGS
The table format does not understand quoting
conventions.
SEE ALSO
postmap(1), Postfix lookup table manager
smtpd(8), SMTP server
postconf(5), configuration parameters
transport(5), transport:nexthop syntax
README FILES
SMTPD_ACCESS_README, built-in SMTP server access control
DATABASE_README, Postfix lookup table overview
LICENSE
The Secure Mailer license must be distributed with
this
software.
AUTHOR(S)

Wietse Venema
IBM T.J. Watson Research
P.O. Box 704
Yorktown Heights, NY 10598, USA
ACCESS
(5)

Postfix manual - postmap(1)
POSTMAP(1) POSTMAP
(1)
NAME
postmap - Postfix lookup table management
SYNOPSIS
postmap [-Nfinoprsvw] [-c config_dir] [-d key] [-q key]
[file_type:]file_name ...
DESCRIPTION
The postmap command creates or queries one or more
Postfix
lookup tables, or updates an existing one. The input
and
output file formats are expected to be compatible with:
makemap file_type file_name < file_name
If the result files do not exist they will be created

with
the same group and other read permissions as the
source
file.
While the table update is in progress, signal delivery

is
postponed, and an exclusive, advisory, lock is placed
on
the entire table, in order to avoid surprises in
spectator
programs.
INPUT FILE FORMAT

The format of a lookup table input file is as follows:
o A table entry has the form
key whitespace value
o Empty lines and whitespace-only lines are
http://www.subneural.net/postfix-master/postmap.1.html (1 of 8)01/16/2005 15:46:00

ignored,
character
is a `#'.
o A logical line starts with non-whitespace text.

A
logi-
cal line.
The key and value are processed as is, except that

sur-
rounding white space is stripped off. Unlike with
Postfix
alias databases, quotes cannot be used to protect
lookup
keys that contain special characters such as `#'
or
whitespace. The key is mapped to lowercase to make
mapping
lookups case insensitive.
COMMAND-LINE ARGUMENTS
-c config_dir
Read the main.cf configuration file in the
named
directory instead of the default
configuration
directory.
-d key Search the specified maps for key and remove

one
entry per map. The exit status is zero when
the
requested information was found.
If a key value of - is specified, the program

reads
key values from the standard input stream. The
exit
status is zero when at least one of the
requested

keys was found.
-f Do not fold the lookup key to lower case while

cre-
ating or querying a map.
-i Incremental mode. Read entries from standard

input
and do not truncate an existing database.
By
default, postmap creates a new database from
the
entries in file_name.
-N Include the terminating null character that

termi-
nates lookup keys and values. By default,
Postfix
does whatever is the default for the host
operating
system.
-n Don't include the terminating null character

that
terminates lookup keys and values. By
default,
Postfix does whatever is the default for the
host
operating system.
-o Do not release root privileges when processing

a
non-root input file. By default, postmap drops
root
privileges and runs as the source file
owner
instead.
-p Do not inherit the file access permissions from

the
input file when creating a new file. Instead,
cre-

ate a new file with default access

permissions
(mode 0644).
-q key Search the specified maps for key and write

the
first value found to the standard output
stream.
The exit status is zero when the requested
informa-
tion was found.

reads
key values from the standard input stream
and
writes one line of key value output for each
key
that was found. The exit status is zero when
at
least one of the requested keys was found.
-r When updating a table, do not complain

about
attempts to update existing entries, and make
those
updates anyway.
-s Retrieve all database elements, and write one

line
of key value output for each element. The
elements
are printed in database order, which is not
neces-
sarily the same as the original input order.
This
feature is available in Postfix version 2.2
and
later, and is not available for all database
types.
-v Enable verbose logging for debugging purposes.

Mul-

tiple -v options make the software

increasingly
verbose.
-w When updating a table, do not complain

about
attempts to update existing entries, and
ignore
those attempts.
Arguments:
file_type
The database type. To find out what types are
sup-
ported, use the "postconf -m" command.
The postmap command can query any supported

file
type, but it can create only the following
file
types:
btree The output file is a btree file,

named
file_name.db. This is available only
on
systems with support for db databases.
dbm The output consists of two files,

named
file_name.pag and file_name.dir. This
is
available only on systems with support
for
dbm databases.
hash The output file is a hashed file,

named
on

sdbm The output consists of two files,

named
is
for
sdbm databases.
When no file_type is specified, the software

uses
the database type specified via
the
default_database_type configuration parameter.
file_name
The name of the lookup table source file
when
rebuilding a database.
DIAGNOSTICS
Problems are logged to the standard error stream and
to
syslogd(8). No output means that no problems
were
detected. Duplicate entries are skipped and are
flagged
with a warning.
postmap terminates with zero exit status in case of

suc-
cess (including successful postmap -q lookup) and
termi-
nates with non-zero exit status in case of failure.
ENVIRONMENT
MAIL_CONFIG
Directory with Postfix configuration files.
MAIL_VERBOSE
Enable verbose logging for debugging purposes.

CONFIGURATION PARAMETERS
The following main.cf parameters are especially
relevant
to this program. The text below provides only a
parameter
summary. See postconf(5) for more details including
exam-
ples.
berkeley_db_create_buffer_size (16777216)
The per-table I/O buffer size for programs
that
create Berkeley DB hash or btree tables.
berkeley_db_read_buffer_size (131072)
that
read Berkeley DB hash or btree tables.
config_directory (see 'postconf -d' output)

The default location of the Postfix main.cf
and
master.cf configuration files.
default_database_type (see 'postconf -d' output)

The default database type for use in newaliases
(1),
postalias(1) and postmap(1) commands.
syslog_facility (mail)
The syslog facility of Postfix logging.
syslog_name (postfix)
The mail system name that is prepended to the
pro-
cess name in syslog records, so that
"smtpd"
becomes, for example, "postfix/smtpd".
SEE ALSO
postalias(1), create/update/query alias database

postconf(1), supported database types

syslogd(8), system logging
README FILES
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
POSTMAP
(1)

Postfix manual - sendmail(1)
SENDMAIL(1) SENDMAIL
(1)
NAME
sendmail - Postfix to Sendmail compatibility interface
SYNOPSIS
sendmail [option ...] [recipient ...]
mailq
sendmail -bp
newaliases
sendmail -I
DESCRIPTION
The Postfix sendmail command implements the Postfix
to
Sendmail compatibility interface. For the sake of
compat-
ibility with existing applications, some Sendmail
command-
line options are recognized but silently ignored.
By default, Postfix sendmail reads a message from

standard
input until EOF or until it reads a line with only
a .
character, and arranges for delivery. Postfix
sendmail
relies on the postdrop(1) command to create a queue
file
in the maildrop directory.
Specific command aliases are provided for other

common
modes of operation:
mailq List the mail queue. Each entry shows the

queue
file ID, message size, arrival time, sender,
http://www.subneural.net/postfix-master/newaliases.1.html (1 of 14)01/16/2005 15:46:00

and
the recipients that still need to be delivered.
If
mail could not be delivered upon the last
attempt,
the reason for failure is shown. This mode of
oper-
ation is implemented by executing the postqueue
(1)
command.
newaliases
Initialize the alias database. If no input file
is
specified (with the -oA option, see below),
the
program processes the file(s) specified with
the
alias_database configuration parameter. If
no
alias database type is specified, the program
uses
the type specified with the
default_database_type
configuration parameter. This mode of operation
is
implemented by running the postalias(1) command.
Note: it may take a minute or so before an

alias
database update becomes visible. Use the
postfix
reload command to eliminate this delay.
These and other features can be selected by specifying

the
appropriate combination of command-line options. Some
fea-
tures are controlled by parameters in the main.cf
configu-
ration file.

The following options are recognized:
-Am (ignored)
-Ac (ignored)
Postfix sendmail uses the same configuration
file
regardless of whether or not a message is an
ini-
tial submission.
-B body_type
The message body MIME type: 7BIT or 8BITMIME.
-bd Go into daemon mode. This mode of operation

is
implemented by executing the postfix start
command.
-bh (ignored)
-bH (ignored)
Postfix has no persistent host status database.
-bi Initialize alias database. See the newaliases

com-
mand above.
-bm Read mail from standard input and arrange

for
delivery. This is the default mode of operation.
-bp List the mail queue. See the mailq command above.
-bs Stand-alone SMTP server mode. Read SMTP

commands
from standard input, and write responses to
stan-
dard output. In stand-alone SMTP server mode,
mail
relaying and other access controls are disabled
by
default. To enable them, run the process as

the
mail_owner user.
This mode of operation is implemented by

running
the smtpd(8) daemon.
-bv Do not collect or deliver a message. Instead,

send
an email report after verifying each
recipient
address. This is useful for testing
address
rewriting and routing configurations.
This feature is available in Postfix version

2.1
and later.
-C config_file (ignored)
The path name of the sendmail.cf file. Postfix
con-
figuration files are kept in the /etc/
postfix
directory.
-F full_name
Set the sender full name. This is used only
with
messages that have no From: message header.
-f sender
Set the envelope sender address. This is
the
address where delivery problems are sent to,
unless
the message contains an Errors-To: message
header.
-G (ignored)
Gateway (relay) submission, as opposed to
initial

user submission.
-h hop_count (ignored)
Hop count limit. Use the hopcount_limit
configura-
tion parameter instead.
-I Initialize alias database. See the newaliases

com-
mand above.
-i When reading a message from standard input,

don't
treat a line with only a . character as the end
of
input.
-L label (ignored)
The logging label. Use the syslog_name
configura-
tion parameter instead.
-m (ignored)
Backwards compatibility.
-N dsn (ignored)
Delivery status notification control.
Currently,
Postfix does not implement DSN.
-n (ignored)
Backwards compatibility.
-oAalias_database
Non-default alias database. Specify pathname
or
type:pathname. See postalias(1) for details.
-o7 (ignored)
-o8 (ignored)
To send 8-bit or binary content, use an

appropriate
MIME encapsulation and specify the appropriate -
B
command-line option.
-oi When reading a message from standard input,

don't
treat a line with only a . character as the end
of
input.
-om (ignored)
The sender is never eliminated from alias
etc.
expansions.
-o x value (ignored)
Set option x to value. Use the equivalent
configu-
ration parameter in main.cf instead.
-r sender
Set the envelope sender address. This is
the
address where delivery problems are sent to,
unless
the message contains an Errors-To: message
header.
-R return_limit (ignored)
Limit the size of bounced mail. Use
the
bounce_size_limit configuration parameter
instead.
-q Attempt to deliver all queued mail. This is

imple-
mented by executing the postqueue(1) command.
Warning: flushing undeliverable mail

frequently
will result in poor delivery performance of

all
other mail.
-qinterval (ignored)
The interval between queue runs. Use
the
queue_run_delay configuration parameter instead.
-qRsite
Schedule immediate delivery of all mail that
is
queued for the named site. This option accepts
only
site names that are eligible for the "fast
flush"
service, and is implemented by executing
the
postqueue(1) command. See flush(8) for more
infor-
mation about the "fast flush" service.
-qSsite
This command is not implemented. Use the
slower
sendmail -q command instead.
-t Extract recipients from message headers. These

are
added to any recipients specified on the
command
line.
With Postfix versions prior to 2.1, this

option
requires that no recipient addresses are
specified
on the command line.
-U (ignored)
Initial user submission.
-V Variable Envelope Return Path. Given an

envelope
sender address of the form owner-
listname@origin,
each recipient user@domain receives mail with
a
personalized envelope sender address.
By default, the personalized envelope

sender
address is owner-listname+user=domain@origin.
The
default + and = characters are configurable
with
the default_verp_delimiters configuration
parame-
ter.
This feature is available in Postfix version

1.1
and later.
-Vxy As -V, but uses x and y as the VERP delimiter

char-
acters, instead of the characters specified
with
the default_verp_delimiters configuration
parame-
ter.
-v Send an email report of the first delivery

attempt
(Postfix versions 2.1 and later). Mail
delivery
always happens in the background. When multiple -
v
options are given, enable verbose logging
for
debugging purposes.
-X log_file (ignored)
Log mailer traffic. Use the debug_peer_list
and

debug_peer_level configuration parameters

instead.
SECURITY
By design, this program is not set-user (or group)
id.
However, it must handle data from untrusted users
or
untrusted machines. Thus, the usual precautions need
to
be taken against malicious inputs.
DIAGNOSTICS
Problems are logged to syslogd(8) and to the
standard
error stream.
ENVIRONMENT
MAIL_CONFIG
MAIL_VERBOSE
MAIL_DEBUG
Enable debugging with an external command, as
spec-
ified with the debugger_command
configuration
parameter.
relevant
parameter
exam-
ples.
TROUBLE SHOOTING CONTROLS

The DEBUG_README file gives examples of how to

trouble
shoot a Postfix system.
debugger_command (empty)
The external command to execute when a Postfix
dae-
mon program is invoked with the -D option.
debug_peer_level (2)
The increment in verbose logging level when
a
remote client or server matches a pattern in
the
debug_peer_list parameter.
debug_peer_list (empty)
Optional list of remote client or server
hostname
or network address patterns that cause the
verbose
logging level to increase by the amount
specified
in $debug_peer_level.
ACCESS CONTROLS
Available in Postfix version 2.2 and later:
authorized_flush_users (static:anyone)
List of users who are authorized to flush
the
queue.
authorized_mailq_users (static:anyone)
List of users who are authorized to view the
queue.
authorized_submit_users (static:anyone)
List of users who are authorized to submit
mail
with the sendmail(1) command (and with the
privi-

leged postdrop(1) helper command).
RESOURCE AND RATE CONTROLS

bounce_size_limit (50000)
The maximal amount of original message text that
is
sent in a non-delivery notification.
fork_attempts (5)
The maximal number of attempts to fork() a
child
process.
fork_delay (1s)
The delay between attempts to fork() a child
pro-
cess.
hopcount_limit (50)
The maximal number of Received: message
headers
that is allowed in the primary message headers.
queue_run_delay (1000s)
The time between deferred queue scans by the
queue
manager.
FAST FLUSH CONTROLS

The ETRN_README file describes configuration and
operation
details for the Postfix "fast flush" service.
fast_flush_domains ($relay_domains)
Optional list of destinations that are eligible
for
per-destination logfiles with mail that is
queued
to those destinations.
VERP CONTROLS

The VERP_README file describes configuration and

operation
details of Postfix support for variable envelope
return
path addresses.
default_verp_delimiters (+=)
The two default VERP delimiter characters.
verp_delimiter_filter (-=+)
The characters Postfix accepts as VERP
delimiter
characters on the Postfix sendmail(1) command
line
and in SMTP commands.
MISCELLANEOUS CONTROLS
alias_database (see 'postconf -d' output)
The alias databases for local(8) delivery that
are
updated with "newaliases" or with "sendmail -bi".
command_directory (see 'postconf -d' output)

The location of all postfix administrative
com-
mands.

and
daemon_directory (see 'postconf -d' output)

The directory with Postfix support programs
and
daemon programs.

(1),

delay_warning_time (0h)
The time after which the sender receives the
mes-
sage headers of mail that is still queued.
mail_owner (postfix)
The UNIX system account that owns the Postfix
queue
and most Postfix daemon processes.
queue_directory (see 'postconf -d' output)

The location of the Postfix top-level queue
direc-
tory.
pro-
"smtpd"
trigger_timeout (10s)
The time limit for sending a trigger to a
Postfix
daemon (for example, the pickup(8) or qmgr(8)
dae-
mon).
FILES
/var/spool/postfix, mail queue
/etc/postfix, configuration files
SEE ALSO
pickup(8), mail pickup daemon
qmgr(8), queue manager

flush(8), fast flush service

postsuper(1), queue maintenance
postdrop(1), mail posting utility
postfix(1), mail system control
postqueue(1), mail queue control
README_FILES
DEBUG_README, Postfix debugging howto
ETRN_README, Postfix ETRN howto
VERP_README, Postfix VERP howto
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
SENDMAIL
(1)

Postfix manual - postdrop(1)
POSTDROP(1) POSTDROP
(1)
NAME
postdrop - Postfix mail posting utility
SYNOPSIS
postdrop [-rv] [-c config_dir]
DESCRIPTION
The postdrop command creates a file in the maildrop
direc-
tory and copies its standard input to the file.
Options:
-c config_dir
The main.cf configuration file is in the
named
configuration
directory. See also the MAIL_CONFIG
environment
setting below.
-r Use a Postfix-internal protocol for reading

the
message from standard input, and for reporting
sta-
tus information on standard output. This is
cur-
rently the only supported method.

Mul-
increasingly
verbose.
SECURITY
The command is designed to run with set-group ID
http://www.subneural.net/postfix-master/postdrop.1.html (1 of 4)01/16/2005 15:46:01

privi-
leges, so that it can write to the maildrop queue
direc-
tory and so that it can connect to Postfix daemon
pro-
cesses.
DIAGNOSTICS
Fatal errors: malformed input, I/O error, out of
memory.
standard
error stream. When the input is incomplete, or when
the
process receives a HUP, INT, QUIT or TERM signal,
the
queue file is deleted.
ENVIRONMENT
MAIL_CONFIG
Directory with the main.cf file. In order to
avoid
exploitation of set-group ID privileges, a
non-
standard directory is allowed only if:
o The name is listed in the standard main.

cf
file with the
alternate_config_directories
o The command is invoked by the super-user.
relevant
parameter
exam-
ples.

alternate_config_directories (empty)
A list of non-default Postfix configuration
direc-
tories that may be specified with "-c
config_direc-
tory" on the command line, or via the
MAIL_CONFIG
environment parameter.

and
import_environment (see 'postconf -d' output)

The list of environment parameters that a
Postfix
process will import from a non-Postfix parent
pro-
cess.

direc-
tory.
pro-
"smtpd"
Postfix

dae-
mon).
authorized_submit_users (static:anyone)
List of users who are authorized to submit
mail
with the sendmail(1) command (and with the
privi-
leged postdrop(1) helper command).
FILES
/var/spool/postfix/maildrop, maildrop queue
SEE ALSO
sendmail(1), compatibility interface
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
POSTDROP
(1)

Postfix manual - pickup(8)
PICKUP(8) PICKUP
(8)
NAME
pickup - Postfix local mail pickup
SYNOPSIS
pickup [generic Postfix daemon options]
DESCRIPTION
The pickup daemon waits for hints that new mail has
been
dropped into the maildrop directory, and feeds it into
the
cleanup(8) daemon. Ill-formatted files are deleted
with-
out notifying the originator. This program expects to
be
run from the master(8) process manager.
STANDARDS
None. The pickup daemon does not interact with the
outside
world.
SECURITY
The pickup daemon is moderately security sensitive.
It
runs with fixed low privilege and can run in a
chrooted
environment. However, the program reads files from
poten-
tially hostile users. The pickup daemon opens no
files
for writing, is careful about what files it opens
for
reading, and does not actually touch any data that is
sent
to its public service endpoint.
DIAGNOSTICS
http://www.subneural.net/postfix-master/pickup.8.html (1 of 4)01/16/2005 15:46:01

Problems and transactions are logged to syslogd(8).
BUGS
The pickup daemon copies mail from file to the cleanup
(8)
daemon. It could avoid message copying overhead by
send-
ing a file descriptor instead of file data, but then
the
already complex cleanup(8) daemon would have to deal
with
unfiltered user data.
As the pickup(8) daemon is a relatively long-running
pro-
cess, up to an hour may pass before a main.cf change
takes
effect. Use the command "postfix reload" command to
speed
up a change.
The text below provides only a parameter summary.

See
postconf(5) for more details including examples.
CONTENT INSPECTION CONTROLS

content_filter (empty)
The name of a mail delivery transport that
filters
mail after it is queued.
receive_override_options (empty)
Enable or disable recipient validation, built-
in
content filtering, or address mapping.
and

daemon_timeout (18000s)
How much time a Postfix daemon process may take
to
handle a request before it is terminated by
a
built-in watchdog timer.
ipc_timeout (3600s)
The time limit for sending or receiving
information
over an internal communication channel.
line_length_limit (2048)
Upon input, long lines are chopped up into
pieces
of at most this length; upon delivery, long
lines
are reconstructed.
max_idle (100s)
The maximum amount of time that an idle
Postfix
daemon process waits for the next service
request
before exiting.
max_use (100)
The maximal number of connection requests before
a
Postfix daemon process terminates.
The process ID of a Postfix command or daemon
pro-
cess.
The process name of a Postfix command or
daemon
process.


direc-
tory.
pro-
"smtpd"
SEE ALSO
cleanup(8), message canonicalization
sendmail(1), Sendmail-compatible interface
postdrop(1), mail posting agent
master(5), generic daemon options
master(8), process manager
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
PICKUP
(8)

Postfix manual - cleanup(8)
CLEANUP(8) CLEANUP
(8)
NAME
cleanup - canonicalize and enqueue Postfix message
SYNOPSIS
cleanup [generic Postfix daemon options]
DESCRIPTION
The cleanup daemon processes inbound mail, inserts it
into
the incoming mail queue, and informs the queue manager
of
its arrival.
The cleanup daemon always performs the following

transfor-
mations:
o Insert missing message headers: (Resent-)

From:,
To:, Message-Id:, and Date:.
o Transform envelope and header addresses to

the
standard user@fully-qualified-domain form that
is
expected by other Postfix programs. This task
is
delegated to the trivial-rewrite(8) daemon.
o Eliminate duplicate envelope recipient addresses.
The following address transformations are optional:
o Optionally, rewrite all envelope and

header
addresses according to the mappings specified
in
the canonical(5) lookup tables.
http://www.subneural.net/postfix-master/cleanup.8.html (1 of 12)01/16/2005 15:46:02

o Optionally, masquerade envelope sender

addresses
and message header addresses (i.e. strip host
or
domain information below all domains listed in
the
masquerade_domains parameter, except for user
names
listed in masquerade_exceptions). By
default,
address masquerading does not affect
envelope
recipients.
o Optionally, expand envelope recipients according

to
information found in the virtual(5) lookup
tables.
The cleanup daemon performs sanity checks on the

content
of each message. When it finds a problem, by default
it
returns a diagnostic status to the client, and leaves
it
up to the client to deal with the problem.
Alternatively,
the client can request the cleanup daemon to bounce
the
message back to the sender in case of trouble.
STANDARDS
RFC 822 (ARPA Internet Text Messages)
RFC 2045 (MIME: Format of Internet Message Bodies)
RFC 2046 (MIME: Media Types)
DIAGNOSTICS
BUGS
Table-driven rewriting rules make it hard to express

if
then else and other logical relationships.
Changes to main.cf are picked up automatically,
as
cleanup(8) processes run for only a limited amount
of
time. Use the command "postfix reload" to speed up
a
change.

See
COMPATIBILITY CONTROLS
undisclosed_recipients_header (To: undisclosed-
recipi-
ents:;)
Message header that the Postfix cleanup(8)
server
inserts when a message contains no To: or Cc:
mes-
sage header.
BUILT-IN CONTENT FILTERING CONTROLS

Postfix built-in content filtering is meant to stop
a
flood of worms or viruses. It is not a general
content
filter.
body_checks (empty)
Optional lookup tables for content inspection
as
specified in the body_checks(5) manual page.
header_checks (empty)

of
primary non-MIME message headers, as specified
in
the header_checks(5) manual page.
body_checks_size_limit (51200)
How much text in a message body segment (or
attach-
ment, if you prefer to use that term) is
subjected
to body_checks inspection.
mime_header_checks ($header_checks)
of
MIME related message headers, as described in
the
header_checks(5) manual page.
nested_header_checks ($header_checks)
of
non-MIME message headers in attached messages,
as
described in the header_checks(5) manual page.
MIME PROCESSING CONTROLS

disable_mime_input_processing (no)
Turn off MIME processing while receiving mail.
mime_boundary_length_limit (2048)
The maximal length of MIME multipart
boundary
strings.
mime_nesting_limit (100)
The maximal recursion level that the MIME

processor
will handle.
strict_8bitmime (no)
Enable both strict_7bit_headers and
strict_8bit-
mime_body.
strict_7bit_headers (no)
Reject mail with 8-bit text in message headers.
strict_8bitmime_body (no)
Reject 8-bit message body text without 8-bit
MIME
content encoding information.
strict_mime_encoding_domain (no)
Reject mail with invalid Content-Transfer-
Encoding:
information for the message/* or multipart/*
MIME
content types.
AUTOMATIC BCC RECIPIENT CONTROLS

Postfix can automatically add BCC (blind carbon copy)
when
mail enters the mail system:
always_bcc (empty)
Optional address that receives a "blind
carbon
copy" of each message that is received by the
Post-
fix mail system.
sender_bcc_maps (empty)
Optional BCC (blind carbon-copy) address
lookup
tables, indexed by sender address.

recipient_bcc_maps (empty)
Optional BCC (blind carbon-copy) address
lookup
tables, indexed by recipient address.
ADDRESS TRANSFORMATION CONTROLS

Address rewriting is delegated to the trivial-rewrite
(8)
daemon. The cleanup(8) server implements table
driven
address mapping.
empty_address_recipient (MAILER-DAEMON)
The recipient of mail addressed to the
null
address.
canonical_maps (empty)
Optional address mapping lookup tables for
message
headers and envelopes.
recipient_canonical_maps (empty)
envelope
and header recipient addresses.
sender_canonical_maps (empty)
envelope
and header sender addresses.
masquerade_classes (envelope_sender,
header_sender,
header_recipient)
What addresses are subject to address
masquerading.
masquerade_domains (empty)
Optional list of domains whose subdomain
structure

will be stripped off in email addresses.
masquerade_exceptions (empty)
Optional list of user names that are not
subjected
to address masquerading, even when their
address
matches $masquerade_domains.
propagate_unmatched_extensions (canonical, virtual)

What address lookup tables copy an address
exten-
sion from the lookup key to the lookup result.
Available before Postfix version 2.0:
virtual_maps (empty)
Optional lookup tables with a) names of domains
for
which all addresses are aliased to addresses
in
other local or remote domains, and b)
addresses
that are aliased to addresses in other local
or
remote domains.
virtual_alias_maps ($virtual_maps)
Optional lookup tables that alias specific
mail
addresses or domains to other local or
remote
address.
canonical_classes (envelope_sender,
envelope_recipient,
header_sender, header_recipient)
What addresses are subject to

canonical_maps
address mapping.
recipient_canonical_classes
(envelope_recipient,
header_recipient)
recipient_canoni-
cal_maps address mapping.
sender_canonical_classes (envelope_sender, header_sender)

sender_canonical_maps
address mapping.
remote_header_rewrite_domain (empty)
Don't rewrite message headers from remote
clients
at all when this parameter is empty;
otherwise,
rewrite remote message headers and append the
spec-
ified domain name to incomplete addresses.

duplicate_filter_limit (1000)
The maximal number of addresses remembered by
the
address duplicate filter for aliases(5) or
vir-
tual(5) alias expansion, or for showq(8) queue
dis-
plays.
header_size_limit (102400)
The maximal amount of memory in bytes for storing
a
message header.
hopcount_limit (50)

headers
in_flow_delay (1s)
Time to pause before accepting a new message,
when
the message arrival rate exceeds the message
deliv-
ery rate.
message_size_limit (10240000)
The maximal size in bytes of a message,
including
envelope information.
header_address_token_limit (10240)
The maximal number of address tokens are allowed
in
an address message header.
boundary
strings.
processor
will handle.
queue_file_attribute_count_limit (100)
The maximal number of (name=value) attributes
that
may be stored in a Postfix queue file.
virtual_alias_expansion_limit (1000)
The maximal number of addresses that virtual
alias

expansion produces from each original recipient.
virtual_alias_recursion_limit (1000)
The maximal nesting depth of virtual alias
expan-
sion.
and
to
a
delay_warning_time (0h)
The time after which the sender receives the
mes-
sage headers of mail that is still queued.
ipc_timeout (3600s)
information
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a

myhostname (see 'postconf -d' output)

The internet hostname of this mail system.
myorigin ($myhostname)
The domain name that locally-posted mail appears
to
come from, and that locally posted mail is
deliv-
ered to.
pro-
cess.
daemon
process.

direc-
tory.
soft_bounce (no)
Safety net to keep mail queued that would
otherwise
be returned to the sender.
pro-
"smtpd"

enable_original_recipient (yes)
Enable support for the X-Original-To
message
header.
FILES
/etc/postfix/canonical*, canonical mapping table
/etc/postfix/virtual*, virtual mapping table
SEE ALSO
trivial-rewrite(8), address rewriting
header_checks(5), message header content inspection
body_checks(5), body parts content inspection
canonical(5), canonical address lookup table format
virtual(5), virtual alias lookup table format
README FILES
ADDRESS_REWRITING_README Postfix address manipulation
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
CLEANUP
(8)

Postfix manual - trivial-rewrite(8)
TRIVIAL-REWRITE(8) TRIVIAL-REWRITE
(8)
NAME
trivial-rewrite - Postfix address rewriting and
resolving
daemon
SYNOPSIS
trivial-rewrite [generic Postfix daemon options]
DESCRIPTION
The trivial-rewrite daemon processes three types of
client
service requests:
rewrite context address

Rewrite an address to standard form, according
to
the address rewriting context:
local Append the domain names specified with

$myo-
rigin or $mydomain to incomplete
addresses;
do swap_bangpath and allow_percent_hack
pro-
cessing as described below, and strip
source
routed addresses (@site,@site:
user@domain)
to user@domain form.
remote Append the domain name specified

with
$remote_header_rewrite_domain to
incomplete
addresses. Otherwise the result is
identical
to that of the local address rewriting
con-
http://www.subneural.net/postfix-master/trivial-rewrite.8.html (1 of 10)01/16/2005 15:46:03

text. This prevents Postfix from

appending
the local domain to spam from poorly
written
remote clients.
resolve address
Resolve an address to a (transport, nexthop,
recip-
ient, flags) quadruple. The meaning of the
results
is as follows:
transport
The delivery agent to use. This is the
first
field of an entry in the master.cf file.
nexthop
The host to send to and optional
delivery
method information.
recipient
The envelope recipient address that
is
passed on to nexthop.
flags The address class, whether the

address
requires relaying, whether the address
has
problems, and whether the request failed.
verify address
Resolve an address for address verification
pur-
poses.
SERVER PROCESS MANAGEMENT

The trivial-rewrite servers run under control by the
Post-

fix master server. Each server can handle multiple

simul-
taneous connections. When all servers are busy while
a
client connects, the master creates a new server
process,
provided that the trivial-rewrite server process limit
is
not exceeded. Each trivial-rewrite server
terminates
after serving at least $max_use clients of after
$max_idle
seconds of idle time.
STANDARDS
None. The command does not interact with the
outside
world.
SECURITY
The trivial-rewrite daemon is not security sensitive.
By
default, this daemon does not talk to remote or
local
users. It can run at a fixed low privilege in a
chrooted
environment.
DIAGNOSTICS
On busy mail systems a long time may pass before a main.
cf
change affecting trivial_rewrite(8) is picked up. Use
the
command "postfix reload" to speed up a change.

See

resolve_dequoted_address (yes)
Resolve a recipient address safely instead of
cor-
rectly, by looking inside quotes.
resolve_null_domain (no)
Resolve an address that ends in the "@" null
domain
as if the local hostname were specified, instead
of
rejecting the address as invalid.
ADDRESS REWRITING CONTROLS

to
deliv-
ered to.
allow_percent_hack (yes)
Enable the rewriting of the form "user%domain"
to
"user@domain".
append_at_myorigin (yes)
With locally submitted mail, append the
string
"@$myorigin" to mail addresses without
domain
information.
append_dot_mydomain (yes)
With locally submitted mail, append the
string
".$mydomain" to addresses that have no ".
domain"
information.
recipient_delimiter (empty)

The separator between user names and address

exten-
sions (user+foo).
swap_bangpath (yes)
Enable the rewriting of "site!user"
into
"user@site".
Available in Postfix 2.2 and later:
remote_header_rewrite_domain (empty)
Don't rewrite message headers from remote
clients
at all when this parameter is empty;
otherwise,
rewrite remote message headers and append the
spec-
ified domain name to incomplete addresses.
ROUTING CONTROLS
The following is applicable to Postfix version 2.0
and
later. Earlier versions do not have support for:
vir-
tual_transport, relay_transport,
virtual_alias_domains,
virtual_mailbox_domains or proxy_interfaces.
local_transport (local:$myhostname)
The default mail delivery transport for
domains
that match $mydestination, $inet_interfaces
or
$proxy_interfaces.
virtual_transport (virtual)
domains
that match the $virtual_mailbox_domains
parameter

value.
relay_transport (relay)
The default mail delivery transport and next-
hop
information for domains that match
the
$relay_domains parameter value.
default_transport (smtp)
domains
that do not match $mydestination,
$inet_interfaces,
$proxy_interfaces, $virtual_alias_domains,
$vir-
tual_mailbox_domains, or $relay_domains.
parent_domain_matches_subdomains (see 'postconf -d'

out-
put)
What Postfix features match subdomains
of
"domain.tld" automatically, instead of requiring
an
explicit ".domain.tld" pattern.
relayhost (empty)
The default host to send non-local mail to when
no
entry is matched in the optional transport
(5)
table.
transport_maps (empty)
Optional lookup tables with mappings from
recipient
address to (message delivery transport, next-
hop
destination).

ADDRESS VERIFICATION CONTROLS

Postfix version 2.1 introduces sender and
recipient
address verification. This feature is implemented
by
sending probe email messages that are not actually
deliv-
ered. By default, address verification probes use
the
same route as regular mail. To override specific
aspects
of message routing for address verification probes,
spec-
ify one or more of the following:
address_verify_local_transport ($local_transport)
Overrides the local_transport parameter setting
for
address verification probes.
address_verify_virtual_transport ($virtual_transport)
Overrides the virtual_transport parameter
setting
for address verification probes.
address_verify_relay_transport ($relay_transport)
Overrides the relay_transport parameter setting
for
address_verify_default_transport ($default_transport)
Overrides the default_transport parameter
setting
address_verify_relayhost ($relayhost)
Overrides the relayhost parameter setting
for
address_verify_transport_maps ($transport_maps)

Overrides the transport_maps parameter setting

for
and
to
a
null
address.
ipc_timeout (3600s)
information
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a
relocated_maps (empty)
Optional lookup tables with new contact
information

for users or domains that no longer exist.
pro-
cess.
daemon
process.

direc-
tory.
show_user_unknown_table_name (yes)
Display the name of the recipient table in
the
"User unknown" responses.
pro-
"smtpd"
helpful_warnings (yes)
Log warnings about problematic configuration
set-
tings, and provide helpful suggestions.
SEE ALSO

transport(5), transport table format

relocated(5), format of the "user has moved" table
README FILES
ADDRESS_CLASS_README, Postfix address classes howto
ADDRESS_VERIFICATION_README, Postfix address verification
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
TRIVIAL-REWRITE
(8)

Postfix Address Classes
Introduction
Postfix version 2.0 introduces the concept of address classes. This is a way of grouping
recipient addresses by their delivery method. The idea comes from discussions with Victor
Duchovni. Although address classes introduced a few incompatibilities they also made it
possible to improve the handling of hosted domains and of unknown recipients.
This document provides information on the following topics:
● What are address classes good for?

● What address classes does Postfix implement?
● Improvements compared to Postfix 1.1
● Incompatibilities with Postfix 1.1
What are address classes good for?

Why should you care about address classes? This is how Postfix decides what mail to accept,
and how to deliver it. In other words, address classes are very important for the operation of
Postfix.
An address class is defined by three items.
● The list of domains that are a member of the class: for example, all local domains, or all
relay domains.
● The default delivery method. For example, the local or smtp delivery agent. This helps
to keep Postfix configurations simple.
● The list of valid recipient addresses for that address class. The Postfix SMTP server
http://www.subneural.net/postfix-master/ADDRESS_CLASS_README.html (1 of 5)01/16/2005 15:46:03

rejects invalid recipients with "User unknown in <name of address class here> table".
This helps to keep the Postfix queue free of undeliverable MAILER-DAEMON
messages.
What address classes does Postfix implement?

Initially the list of address classes is hard coded, but this is meant to become extensible. The
summary below describes the main purpose of each class, and what the relevant configuration
parameters are.
The local domain class.
● Purpose: final delivery for traditional UNIX system accounts and traditional Sendmail-
style aliases. This is typically used for the canonical domains of the machine. For a
discussion of the difference between canonical domains, hosted domains and other
domains, see the VIRTUAL_README file.
● Domain names are listed with the mydestination parameter. This domain class also
includes mail for user@[ipaddress] when the IP address is listed with the
inet_interfaces or proxy_interfaces parameters.
● Valid recipient addresses are listed with the local_recipient_maps parameter, as

described in LOCAL_RECIPIENT_README. The Postfix SMTP server rejects invalid
recipients with "User unknown in local recipient table". If the local_recipient_maps
parameter value is empty, then the Postfix SMTP server accepts any address in the local
domain class.
● The mail delivery transport is specified with the local_transport parameter. The default
value is local:$myhostname for delivery with the local(8) delivery agent.
The virtual alias domain class.
● Purpose: hosted domains where each recipient address is aliased to a local UNIX system
account or to a remote address. A virtual alias example is given in the
VIRTUAL_README file.
● Domain names are listed in virtual_alias_domains. The default value is

$virtual_alias_maps for Postfix 1.1 compatibility.

● Valid recipient addresses are listed with the virtual_alias_maps parameter. The Postfix
SMTP server rejects invalid recipients with "User unknown in virtual alias table". The
default value is $virtual_maps for Postfix 1.1 compatibility.
● There is no mail delivery transport parameter. Every address must be aliased to some
other address.
The virtual mailbox domain class.
● Purpose: final delivery for hosted domains where each recipient address can have its
own mailbox, and where users do not need to have a UNIX system account. A virtual
mailbox example is given in the VIRTUAL_README file.
● Domain names are listed with the virtual_mailbox_domains parameter. The default
value is $virtual_mailbox_maps for Postfix 1.1 compatibility.
● Valid recipient addresses are listed with the virtual_mailbox_maps parameter. The
Postfix SMTP server rejects invalid recipients with "User unknown in virtual mailbox
table". If this parameter value is empty, the Postfix SMTP server accepts all recipients
for domains listed in $virtual_mailbox_domains.
● The mail delivery transport is specified with the virtual_transport parameter. The default
value is virtual for delivery with the virtual(8) delivery agent.
The relay domain class.
● Purpose: mail forwarding to remote destinations that list your system as primary or
backup MX host. For a discussion of the basic configuration details, see the
BASIC_CONFIGURATION_README document. For a discussion of the difference
between canonical domains, hosted domains and other domains, see the
VIRTUAL_README file.
● Domain names are listed with the relay_domains parameter.
● Valid recipient addresses are listed with the relay_recipient_maps parameter. The
Postfix SMTP server rejects invalid recipients with "User unknown in relay recipient
table". If this parameter value is empty, the Postfix SMTP server accepts all recipients
for domains listed with the relay_domains parameter.

● The mail delivery transport is specified with the relay_transport parameter. The default
value is relay which is a clone of the smtp(8) delivery agent.
The default domain class.
● Purpose: mail forwarding to the Internet on behalf of authorized clients. For a

discussion of the basic configuration details, see the
BASIC_CONFIGURATION_README file. For a discussion of the difference between
canonical domains, hosted domains and other domains, see the VIRTUAL_README
file.
● This class has no destination domain table.
● This class has no valid recipient address table.
● The mail delivery transport is specified with the default_transport parameter. The
default value is smtp for delivery with the smtp(8) delivery agent.
Improvements compared to Postfix 1.1

Postfix 2.0 address classes made the following improvements possible over earlier Postfix
versions:
● You no longer need to specify all the virtual(8) mailbox domains in the Postfix transport
map. The virtual(8) delivery agent has become a first-class citizen just like local(8) or
smtp(8).
● On mail gateway systems, address classes provide separation of inbound mail relay
traffic ($relay_transport) from outbound traffic ($default_transport). This eliminates a
problem where inbound mail deliveries could become resource starved in the presence
of a high volume of outbound mail.
● The SMTP server rejects unknown recipients in a more consistent manner than was
possible with Postfix version 1. This is needed to keep undeliverable mail (and bounced
undeliverable mail) out of the mail queue. This is controlled by the
smtpd_reject_unlisted_recipient configuration parameter.
● As of Postfix version 2.1, the SMTP server also rejects unknown sender addresses (i.e.
addresses that it would reject as unknown recipient addresses). Sender "egress filtering"

can help to slow down an email worm explosion. This is controlled by the
smtpd_reject_unlisted_sender configuration parameter.
Incompatibilities with Postfix 1.1

Postfix 2.0 address classes introduce a few incompatible changes in documented behavior. In
order to ease the transitions, new parameters have default values that are backwards
compatible.
● The virtual_maps parameter is replaced by virtual_alias_maps (for address lookups) and

by virtual_alias_domains (for the names of what were formerly called "Postfix-style
virtual domains").
For backwards compatibility with Postfix version 1.1, the new virtual_alias_maps
parameter defaults to $virtual_maps, and the new virtual_alias_domains parameter
defaults to $virtual_alias_maps.
● The virtual_mailbox_maps parameter now has a companion parameter called

virtual_mailbox_domains (for the names of domains served by the virtual delivery
agent). The virtual_mailbox_maps parameter is now used for address lookups only.
For backwards compatibility with Postfix version 1.1, the new

virtual_mailbox_domains parameter defaults to $virtual_mailbox_maps.
● Introduction of the relay_recipient_maps parameter. The Postfix SMTP server can use
this to block mail for relay recipients that don't exist. This list is empty by default,
which means accept any recipient.
● The local_recipient_maps feature is now turned on by default. The Postfix SMTP server
uses this to reject mail for unknown local recipients. See the
LOCAL_RECIPIENT_README file hints and tips.
● Introduction of the relay delivery transport in master.cf. This helps to avoid mail
delivery scheduling problems on inbound mail relays when there is a lot of outbound
mail, but may require that you update your "defer_transports" setting.

Postfix Virtual Domain Hosting Howto
Postfix Virtual Domain

Hosting Howto
Purpose of this document

This document requires Postfix version 2.0 or later.
This document gives an overview of how Postfix can be used for hosting multiple Internet
domains, both for final delivery on the machine itself and for the purpose of forwarding to
destinations elsewhere.
The text not only describes delivery mechanisms that are built into Postfix, but also gives
pointers for using non-Postfix mail delivery software.
The following topics are covered:
● Canonical versus hosted versus other domains

● Local files versus network databases
● As simple as can be: shared domains, UNIX system accounts
● Postfix virtual ALIAS example: separate domains, UNIX system accounts
● Postfix virtual MAILBOX example: separate domains, non-UNIX accounts
● Non-Postfix mailbox store: separate domains, non-UNIX accounts
● Mail forwarding domains
● Mailing lists
● Autoreplies
Canonical versus hosted versus other domains

Most Postfix systems are final destination for only a few domain names. These include the
hostnames and [the IP addresses] of the machine that Postfix runs on, and sometimes also include
the parent domain of the hostname. The remainder of this document will refer to these domains as
http://www.subneural.net/postfix-master/VIRTUAL_README.html (1 of 12)01/16/2005 15:46:04

the canonical domains. They are usually implemented with the Postfix local domain address
class, as defined in the ADDRESS_CLASS_README file.
Besides the canonical domains, Postfix can be configured to be final destination for any number
of additional domains. These domains are called hosted, because they are not directly associated
with the name of the machine itself. Hosted domains are usually implemented with the virtual
alias domain address class and/or with the virtual mailbox domain address class, as defined in the
ADDRESS_CLASS_README file.
But wait! There is more. Postfix can be configured as a backup MX host for other domains. In
this case Postfix is not the final destination for those domains. It merely queues the mail when
the primary MX host is down, and forwards the mail when the primary MX host becomes
available. This function is implemented with the relay domain address class, as defined in the
Finally, Postfix can be configured as a transit host for sending mail across the internet.
Obviously, Postfix is not final destination for such mail. This function is available only for
authorized clients and/or users, and is implemented by the default domain address class, as
defined in the ADDRESS_CLASS_README file.
Local files versus network databases

The examples in this text use table lookups from local files such as DBM or Berkeley DB. These
are easy to debug with the postmap command:
Example: postmap -q info@example.com hash:/etc/postfix/

virtual
See the documentation in LDAP_README, MYSQL_README and PGSQL_README for

how to replace local files by databases. The reader is strongly advised to make the system work
with local files before migrating to network databases, and to use the postmap command to
verify that network database lookups produce the exact same results as local file lookup.
Example: postmap -q info@example.com ldap:/etc/postfix/

virtual.cf
As simple as can be: shared domains, UNIX system

accounts
The simplest method to host an additional domain is to add the domain name to the domains

listed in the Postfix mydestination configuration parameter, and to add the user names to the
UNIX password file.
This approach makes no distinction between canonical and hosted domains. Each username can
receive mail in every domain.
In the examples we will use "example.com" as the domain that is being hosted on the local
Postfix machine.
mydestination = $myhostname localhost.$mydomain ...
example.com
The limitations of this approach are:
● A total lack of separation: mail for info@my.host.name is delivered to the same UNIX
system account as mail for info@example.com.
● With users in the UNIX password file, administration of large numbers of users becomes
inconvenient.
The examples that follow provide solutions for both limitations.
Postfix virtual ALIAS example: separate domains, UNIX

system accounts
With the approach described in this section, every hosted domain can have its own info etc. email
address. However, it still uses UNIX system accounts for local mailbox deliveries.
With virtual alias domains, each hosted address is aliased to a local UNIX system account or to a
remote address. The example below shows how to use this mechanism for the example.com
domain.
1 /etc/postfix/main.cf:
2 virtual_alias_domains = example.com ...other
hosted domains...
3 virtual_alias_maps = hash:/etc/postfix/virtual
4
5 /etc/postfix/virtual:
6 postmaster@example.com postmaster
7 info@example.com joe

8 sales@example.com jane
9 # Uncomment entry below to implement a catch-all
address
10 # @example.com jim
11 ...virtual aliases for more domains...
Notes:
● Line 2: the virtual_alias_domains setting tells Postfix that example.com is a so-called

virtual alias domain. If you omit this setting then Postfix will reject mail (relay access
denied) or will not be able to deliver it (mail for example.com loops back to myself).
NEVER list a virtual alias domain name as a mydestination domain!
● Lines 3-8: the /etc/postfix/virtual file contains the virtual aliases. With the example above,
mail for postmaster@example.com goes to the local postmaster, while mail for
info@example.com goes to the UNIX account joe, and mail for sales@example.com goes
to the UNIX account jane. Mail for all other addresses in example.com is rejected with the
error message "User unknown".
● Line 10: the commented out entry (text after #) shows how one would implement a catch-
all virtual alias that receives mail for every example.com address not listed in the virtual
alias file. This is not without risk. Spammers nowadays try to send mail from (or mail to)
every possible name that they can think of. A catch-all mailbox is likely to receive many
spam messages, and many bounces for spam messages that were sent in the name of
anything@example.com.
Execute the command "postmap /etc/postfix/virtual" after changing the virtual file, and execute
the command "postfix reload" after changing the main.cf file.
Note: virtual aliases can resolve to a local address or to a remote address, or both. They don't
have to resolve to UNIX system accounts on your machine.
More details about the virtual alias file are given in the virtual(5) manual page, including multiple
addresses on the right-hand side.
Virtual aliasing solves one problem: it allows each domain to have its own info mail address. But
there still is one drawback: each virtual address is aliased to a UNIX system account. As you add
more virtual addresses you also add more UNIX system accounts. The next section eliminates
this problem.

Postfix virtual MAILBOX example: separate domains, non-

UNIX accounts
As a system hosts more and more domains and users, it becomes less desirable to give every user
their own UNIX system account.
With the Postfix virtual(8) mailbox delivery agent, every recipient address can have its own
virtual mailbox. Unlike virtual alias domains, virtual mailbox domains do not need the clumsy
translation from each recipient addresses into a different address, and owners of a virtual mailbox
address do not need to have a UNIX system account.
The Postfix virtual(8) mailbox delivery agent looks up the user mailbox pathname, uid and gid
via separate tables that are searched with the recipient's mail address. Maildir style delivery is
turned on by terminating the mailbox pathname with "/".
If you find the idea of multiple tables bothersome, remember that you can migrate the
information (once it works), to an SQL database. If you take that route, be sure to review the
"local files versus databases" section at the top of this document.
Here is an example of a virtual mailbox domain "example.com":
2 virtual_mailbox_domains = example.com ...more
domains...
3 virtual_mailbox_base = /var/mail/vhosts
4 virtual_mailbox_maps = hash:/etc/postfix/vmailbox
5 virtual_minimum_uid = 100
6 virtual_uid_maps = static:5000
7 virtual_gid_maps = static:5000
9
10 /etc/postfix/vmailbox:
11 info@example.com example.com/info
12 sales@example.com example.com/sales/
13 # Comment out the entry below to implement a
catch-all.
14 # @example.com example.com/catchall
15 ...virtual mailboxes for more domains...
16

Notes:
● Line 2: The virtual_mailbox_domains setting tells Postfix that example.com is a so-called

virtual mailbox domain. If you omit this setting then Postfix will reject mail (relay access
NEVER list a virtual MAILBOX domain name as a mydestination domain!
NEVER list a virtual MAILBOX domain name as a virtual ALIAS domain!
● Line 3: The virtual_mailbox_base parameter specifies a prefix for all virtual mailbox
pathnames. This is a safety mechanism in case someone makes a mistake. It prevents mail
from being delivered all over the file system.
● Lines 4, 10-15: The virtual_mailbox_maps parameter specifies the lookup table with
mailbox (or maildir) pathnames, indexed by the virtual mail address. In this example, mail
for info@example.com goes to the mailbox at /var/mail/vhosts/example.com/info while
mail for sales@example.com goes to the maildir located at /var/mail/vhosts/example.com/
sales/.
● Line 5: The virtual_minimum_uid specifies a lower bound on the mailbox or maildir

owner's UID. This is a safety mechanism in case someone makes a mistake. It prevents
mail from being written to sensitive files.
● Lines 6, 7: The virtual_uid_maps and virtual_gid_maps parameters specify that all the
virtual mailboxes are owned by a fixed uid and gid 5000. If this is not what you want,
specify lookup tables that are searched by the recipient's mail address.
● Line 14: The commented out entry (text after #) shows how one would implement a catch-
all virtual mailbox address. Be prepared to receive a lot of spam, as well as bounced spam
that was sent in the name of anything@example.com.
NEVER put a virtual MAILBOX wild-card in the virtual ALIAS file!!
● Lines 8, 17, 18: As you see, it is possible to mix virtual aliases with virtual mailboxes. We
use this feature to redirect mail for example.com's postmaster address to the local
postmaster. You can use the same mechanism to redirect an address to a remote address.
● Line 18: This example assumes that in main.cf, $myorigin is listed under the

mydestination parameter setting. If that is not the case, specify an explicit domain name
on the right-hand side of the virtual alias table entries or else mail will go to the wrong
domain.
Execute the command "postmap /etc/postfix/virtual" after changing the virtual file, execute
"postmap /etc/postfix/vmailbox" after changing the vmailbox file, and execute the command
"postfix reload" after changing the main.cf file.
Note: mail delivery happens with the recipient's UID/GID privileges specified with
virtual_uid_maps and virtual_gid_maps. Postfix 2.0 and earlier will not create mailDIRs in world-
writable parent directories; you must create them in advance before you can use them. Postfix
may be able to create mailBOX files by itself, depending on parent directory write permissions,
but it is safer to create mailBOX files ahead of time.
More details about the virtual mailbox delivery agent are given in the virtual(8) manual page.
Non-Postfix mailbox store: separate domains, non-UNIX

accounts
This is a variation on the Postfix virtual mailbox example. Again, every hosted address can have
its own mailbox.
While non-Postfix software is being used for final delivery, some Postfix concepts are still
needed in order to glue everything together. For additional background on this glue you may
want to take a look at the virtual mailbox domain class as defined in the
The text in this section describes what things should look like from Postfix's point of view. See
CYRUS_README or MAILDROP_README for specific information about Cyrus or about
Courier maildrop.
Here is an example for a hosted domain example.com that delivers to a non-Postfix delivery
agent:
2 virtual_transport = ...see below...
3 virtual_mailbox_domains = example.com ...more
domains...
4 virtual_mailbox_maps = hash:/etc/postfix/vmailbox

6
7 /etc/postfix/vmailbox:
8 info@example.com whatever
9 sales@example.com whatever
10 # Comment out the entry below to implement a
catch-all.
11 # Configure the mailbox store to accept all
addresses.
12 # @example.com whatever
13 ...virtual mailboxes for more domains...
14
Notes:
● Line 2: With delivery to a non-Postfix mailbox store for hosted domains, the
virtual_transport parameter usually specifies the Postfix LMTP client, or the name of a
master.cf entry that executes non-Postfix software via the pipe delivery agent. Typical
examples (use only one):
virtual_transport = lmtp:unix:/path/name (uses

UNIX-domain socket)
virtual_transport = lmtp:hostname:port (uses TCP
socket)
virtual_transport = maildrop: (uses pipe
(8) to command)
Postfix comes ready with support for LMTP. And an example maildrop delivery method is
already defined in the default Postfix master.cf file. See the MAILDROP_README
document for more details.
● Line 3: The virtual_mailbox_domains setting tells Postfix that example.com is delivered

via the virtual_transport that was discussed in the previous paragraph. If you omit this
virtual_mailbox_domains setting then Postfix will either reject mail (relay access denied)
or will not be able to deliver it (mail for example.com loops back to myself).
NEVER list a virtual MAILBOX domain name as a mydestination domain!
NEVER list a virtual MAILBOX domain name as a virtual ALIAS domain!

● Lines 4, 7-13: The virtual_mailbox_maps parameter specifies the lookup table with all
valid recipient addresses. The lookup result is ignored by Postfix. In the above example,
info@example.com and sales@example.com are listed as valid addresses, and mail for
anything else is rejected with "User unknown". If you intend to use LDAP, MySQL or
PgSQL instead of local files, be sure to review the "local files versus databases" section at
the top of this document!
● Line 12: The commented out entry (text after #) shows how one would inform Postfix of
the existence of a catch-all address. Again, the lookup result is ignored by Postfix.
NEVER put a virtual MAILBOX wild-card in the virtual ALIAS file!!
Note: if you specify a wildcard in virtual_mailbox_maps, then you still need to configure
the non-Postfix mailbox store to receive mail for any address in that domain.
● Lines 5, 15, 16: As you see above, it is possible to mix virtual aliases with virtual
mailboxes. We use this feature to redirect mail for example.com's postmaster address to
the local postmaster. You can use the same mechanism to redirect any addresses to a local
or remote address.
● Line 16: This example assumes that in main.cf, $myorigin is listed under the
mydestination parameter setting. If that is not the case, specify an explicit domain name
on the right-hand side of the virtual alias table entries or else mail will go to the wrong
domain.
Execute the command "postmap /etc/postfix/virtual" after changing the virtual file, execute
"postmap /etc/postfix/vmailbox" after changing the vmailbox file, and execute the command
"postfix reload" after changing the main.cf file.
Mail forwarding domains

Some providers host domains that have no (or only a few) local mailboxes. The main purpose of
these domains is to forward mail elsewhere. The following example shows how to set up example.
com as a mail forwarding domain:
2 virtual_alias_domains = example.com ...other
hosted domains...
4

7 joe@example.com joe@somewhere
8 jane@example.com jane@somewhere-else
9 # Uncomment entry below to implement a catch-all
address
10 # @example.com jim@yet-another-site
11 ...virtual aliases for more domains...
Notes:
● Line 2: The virtual_alias_domains setting tells Postfix that example.com is a so-called

virtual alias domain. If you omit this setting then Postfix will reject mail (relay access
NEVER list a virtual alias domain name as a mydestination domain!
● Lines 3-11: The /etc/postfix/virtual file contains the virtual aliases. With the example
above, mail for postmaster@example.com goes to the local postmaster, while mail for
joe@example.com goes to the remote address joe@somewhere, and mail for
jane@example.com goes to the remote address jane@somewhere-else. Mail for all other
addresses in example.com is rejected with the error message "User unknown".
● Line 10: The commented out entry (text after #) shows how one would implement a catch-
all virtual alias that receives mail for every example.com address not listed in the virtual
alias file. This is not without risk. Spammers nowadays try to send mail from (or mail to)
every possible name that they can think of. A catch-all mailbox is likely to receive many
spam messages, and many bounces for spam messages that were sent in the name of
anything@example.com.
Execute the command "postmap /etc/postfix/virtual" after changing the virtual file, and execute
the command "postfix reload" after changing the main.cf file.
More details about the virtual alias file are given in the virtual(5) manual page, including multiple
addresses on the right-hand side.
Mailing lists
The examples that were given above already show how to direct mail for virtual postmaster
addresses to a local postmaster. You can use the same method to direct mail for any address to a
local or remote address.

There is one major limitation: virtual aliases and virtual mailboxes can't directly deliver to
mailing list managers such as majordomo. The solution is to set up virtual aliases that direct
virtual addresses to the local delivery agent:
/etc/postfix/virtual:
listname-request@example.com listname-request
listname@example.com listname
owner-listname@example.com owner-listname
/etc/aliases:
listname: "|/some/where/majordomo/wrapper ..."
owner-listname: ...
listname-request: ...
This example assumes that in main.cf, $myorigin is listed under the mydestination parameter
setting. If that is not the case, specify an explicit domain name on the right-hand side of the
virtual alias table entries or else mail will go to the wrong domain.
More information about the Postfix local delivery agent can be found in the local(8) manual page.
Why does this example use a clumsy virtual alias instead of a more elegant transport mapping?
The reason is that mail for the virtual mailing list would be rejected with "User unknown". In
order to make the transport mapping work one would still need a bunch of virtual alias or virtual
mailbox table entries.
● In case of a virtual alias domain, there would need to be one identity mapping from each
mailing list address to itself.
● In case of a virtual mailbox domain, there would need to be a dummy mailbox for each
mailing list address.
Autoreplies
In order to set up an autoreply for virtual recipients while still delivering mail as normal, set up a
rule in a virtual alias table:

user@domain.tld user@domain.tld, user@domain.
tld@autoreply.mydomain.tld
This delivers mail to the recipient, and sends a copy of the mail to the address that produces
automatic replies. The address can be serviced on a different machine, or it can be serviced
locally by setting up a transport map entry that pipes all mail for autoreply.mydomain.tld into
some script that sends an automatic reply back to the sender.
DO NOT list autoreply.mydomain.tld in mydestination!
/etc/postfix/transport:
autoreply.mydomain.tld autoreply:
#
=============================================================
# service type private unpriv chroot wakeup
maxproc command
# (yes) (yes) (yes) (never)
(100)
#
=============================================================
autoreply unix - n n -
- pipe
flags= user=nobody argv=/path/to/autoreply
$sender $mailbox
This invokes /path/to/autoreply with the sender address and the user@domain.tld recipient
address on the command line.
For more information, see the pipe(8) manual page, and the comments in the Postfix master.cf
file.

Rejecting Unknown Local Recipients with Postfix
Rejecting Unknown Local

Recipients with Postfix
Introduction
As of Postfix version 2.0, the Postfix SMTP server rejects mail for unknown recipients in local
domains (domains that match $mydestination or the IP addresses in $inet_interfaces or
$proxy_interfaces) with "User unknown in local recipient table". This feature was optional
with earlier Postfix versions.
The good news is that this keeps undeliverable mail out of your queue, so that your mail queue
is not clogged up with undeliverable MAILER-DAEMON messages.
The bad news is that it may cause mail to be rejected when you upgrade from a Postfix system
that was not configured to reject mail for unknown local recipients.
This document describes what steps are needed in order to reject unknown local recipients
correctly.
● Configuring local_recipient_maps in main.cf

● When you need to change the local_recipient_maps setting in main.cf
● Local recipient table format
Configuring local_recipient_maps in main.cf

The local_recipient_maps parameter specifies lookup tables with all names or addresses of
local recipients. A recipient address is local when its domain matches $mydestination,
$inet_interfaces or $proxy_interfaces. If a local username or address is not listed in
$local_recipient_maps, then the Postfix SMTP server will reject the address with "User
unknown in local recipient table".
http://www.subneural.net/postfix-master/LOCAL_RECIPIENT_README.html (1 of 3)01/16/2005 15:46:05

The default setting, shown below, assumes that you use the default Postfix local(8) delivery
agent for local delivery, where recipients are either UNIX accounts or local aliases:
local_recipient_maps = proxy:unix:passwd.byname
$alias_maps
To turn off unknown local recipient rejects by the SMTP server, specify:
That is, an empty value. With this setting, the Postfix SMTP server will not reject mail with
"User unknown in local recipient table".
When you need to change the local_recipient_maps

setting in main.cf
● Problem: you don't use the default Postfix local(8) delivery agent for domains matching
$mydestination, $inet_interfaces, or $proxy_interfaces. For example, you redefined the
"local_transport" setting in main.cf.
Solution: your local_recipient_maps setting needs to specify a database that lists all the
known user names or addresses for that delivery agent. For example, if you deliver users
in $mydestination etc. domains via the virtual(8) delivery agent, specify:
/etc/postfix/main.cf
localhost ...
local_transport = virtual
local_recipient_maps = $virtual_mailbox_maps
If you use a different delivery agent for $mydestination etc. domains, see the section
"Local recipient table format" below for a description of how the table should be
populated.
● Problem: you use the mailbox_transport or fallback_transport feature of the Postfix local
(8) delivery agent in order to deliver mail to non-UNIX accounts.

Solution: you need to add the database that lists the non-UNIX users:
local_recipient_maps = proxy:unix:passwd.byname,
$alias_maps,
<the database with non-UNIX accounts>
See the section "Local recipient table format" below for a description of how the table
should be populated.
● Problem: you use the luser_relay feature of the Postfix local delivery agent.
Solution: you must disable the local_recipient_maps feature completely, so that Postfix
accepts mail for all local addresses:
Local recipient table format

If you use local files in postmap(1) format, then local_recipient_maps expects the following
table format:
● In the left-hand side, specify a bare username, an "@domain.tld" wild-card, or specify a

complete "user@domain.tld" address.
● You have to specify something on the right-hand side of the table, but the value is
ignored by local_recipient_maps.
If you use lookup tables based on NIS, LDAP, MYSQL, or PGSQL, then local_recipient_maps
does the same queries as for local files in postmap(1) format, and expects the same results.
With regular expression tables, Postfix only queries with the full recipient address, and not
with the bare username or the "@domain.tld" wild-card.
NOTE: a lookup table should always return a result when the address exists, and should always
return "not found" when the address does not exist. In particular, a zero-length result does not
count as a "not found" result.

Postfix manual - local(8)
LOCAL(8) LOCAL
(8)
NAME
local - Postfix local mail delivery
SYNOPSIS
local [generic Postfix daemon options]
DESCRIPTION
The local daemon processes delivery requests from
the
Postfix queue manager to deliver mail to local
recipients.
Each delivery request specifies a queue file, a
sender
address, a domain or host to deliver to, and one or
more
recipients. This program expects to be run from the
mas-
ter(8) process manager.
The local daemon updates queue files and marks

recipients
as finished, or it informs the queue manager that
delivery
should be tried again at a later time. Delivery
status
reports are sent to the bounce(8), defer(8) or trace
(8)
daemon as appropriate.
SYSTEM-WIDE AND USER-LEVEL ALIASING

The system administrator can set up one or more
system-
wide sendmail-style alias databases. Users can have
send-
mail-style ~/.forward files. Mail for name is
delivered
to the alias name, to destinations in ~name/.forward,
to
http://www.subneural.net/postfix-master/local.8.html (1 of 20)01/16/2005 15:46:06

the mailbox owned by the user name, or it is sent back

as
undeliverable.
The system administrator can specify a comma/space

sepa-
rated list of ~/.forward like files through the
for-
ward_path configuration parameter. Upon delivery,
the
local delivery agent tries each pathname in the list
until
a file is found.
Delivery via ~/..forward files is done with the

privileges
of the recipient. Thus, ~/.forward like files must
be
readable by the recipient, and their parent
directory
needs to have "execute" permission for the recipient.
The forward_path parameter is subject to interpolation

of
$user (recipient username), $home (recipient home
direc-
tory), $shell (recipient shell), $recipient
(complete
recipient address), $extension (recipient address
exten-
sion), $domain (recipient domain), $local (entire
recipi-
ent address localpart) and $recipient_delimiter. The
forms
${name?value} and ${name:value} expand conditionally
to
value when $name is (is not) defined. Characters that
may
have special meaning to the shell or file system
are
replaced by underscores. The list of acceptable
charac-

ters is specified with the forward_expansion_filter

con-
figuration parameter.
An alias or ~/.forward file may list any combination

of
external commands, destination file names, :
include:
directives, or mail addresses. See aliases(5) for a
pre-
cise description. Each line in a user's .forward file
has
the same syntax as the right-hand part of an alias.
When an address is found in its own alias

expansion,
delivery is made to the user instead. When a user
is
listed in the user's own ~/.forward file, delivery is
made
to the user's mailbox instead. An empty ~/.forward
file
means do not forward mail.
In order to prevent the mail system from using up

unrea-
sonable amounts of memory, input records read
from
:include: or from ~/.forward files are broken up
into
chunks of length line_length_limit.
While expanding aliases, ~/.forward files, and so on,

the
program attempts to avoid duplicate deliveries. The
dupli-
cate_filter_limit configuration parameter limits the
num-
ber of remembered recipients.
MAIL FORWARDING
For the sake of reliability, forwarded mail is re-

submit-
ted as a new message, so that each recipient has a
sepa-
rate on-file delivery status record.
In order to stop mail forwarding loops early, the

software
adds an optional Delivered-To: header with the final
enve-
lope recipient address. If mail arrives for a
recipient
that is already listed in a Delivered-To: header, the
mes-
sage is bounced.
MAILBOX DELIVERY
The default per-user mailbox is a file in the UNIX
mail
spool directory (/var/mail/user or /var/spool/mail/
user);
the location can be specified with the
mail_spool_direc-
tory configuration parameter. Specify a name ending
in /
for qmail-compatible maildir delivery.
Alternatively, the per-user mailbox can be a file in

the
user's home directory with a name specified via
the
home_mailbox configuration parameter. Specify a
relative
path name. Specify a name ending in / for qmail-
compatible
maildir delivery.
Mailbox delivery can be delegated to an external

command
specified with the mailbox_command configuration
parame-
ter. The command executes with the privileges of
the

recipient user (exceptions: secondary groups are

not
enabled; in case of delivery as root, the command
executes
with the privileges of default_privs).
Mailbox delivery can be delegated to alternative

message
transports specified in the master.cf file. The
mail-
box_transport configuration parameter specifies a
message
transport that is to be used for all local
recipients,
regardless of whether they are found in the UNIX
passwd
database. The fallback_transport parameter specifies
a
message transport for recipients that are not found in
the
UNIX passwd database.
In the case of UNIX-style mailbox delivery, the local

dae-
mon prepends a "From sender time_stamp" envelope header
to
each message, prepends an X-Original-To: header with
the
recipient address as given to Postfix, prepends
an
optional Delivered-To: header with the final
envelope
recipient address, prepends a Return-Path: header with
the
envelope sender address, prepends a > character to
lines
beginning with "From ", and appends an empty line.
The
mailbox is locked for exclusive access while delivery
is
in progress. In case of problems, an attempt is made
to

truncate the mailbox to its original length.
In the case of maildir delivery, the local daemon

prepends
an optional Delivered-To: header with the final
envelope
recipient address, prepends an X-Original-To: header
with
the recipient address as given to Postfix, and prepends
a
Return-Path: header with the envelope sender address.
EXTERNAL COMMAND DELIVERY

The allow_mail_to_commands configuration
parameter
restricts delivery to external commands. The default
set-
ting (alias, forward) forbids command destinations
in
:include: files.
Optionally, the process working directory is changed

to
the path specified with command_execution_directory
(Post-
fix 2.2 and later). Failure to change directory
causes
mail to be deferred.
The command_execution_directory parameter value is

subject
to interpolation of $user (recipient username),
$home
(recipient home directory), $shell (recipient
shell),
$recipient (complete recipient address),
$extension
(recipient address extension), $domain (recipient
domain),
$local (entire recipient address localpart) and
$recipi-
ent_delimiter. The forms ${name?value} and ${name:

value}
expand conditionally to value when $name is (is
not)
defined. Characters that may have special meaning to
the
shell or file system are replaced by underscores.
The
list of acceptable characters is specified with the
execu-
tion_directory_expansion_filter configuration parameter.
The command is executed directly where possible.

Assis-
tance by the shell (/bin/sh on UNIX systems) is used
only
when the command contains shell magic characters, or
when
the command invokes a shell built-in command.
A limited amount of command output (standard output

and
standard error) is captured for inclusion with non-
deliv-
ery status reports. A command is forcibly terminated
if
it does not complete within command_time_limit
seconds.
Command exit status codes are expected to follow the
con-
ventions defined in <sysexits.h>.
A limited amount of message context is exported via

envi-
ronment variables. Characters that may have special
mean-
ing to the shell are replaced by underscores. The list
of
acceptable characters is specified with the
command_expan-
sion_filter configuration parameter.
SHELL The recipient user's login shell.

HOME The recipient user's home directory.
USER The bare recipient name.
EXTENSION
DOMAIN The recipient address domain part.
LOGNAME
The bare recipient name.
LOCAL The entire recipient address localpart (text to

the
left of the rightmost @ character).
RECIPIENT
The entire recipient address.
SENDER The entire sender address.
Additional remote client information is made available

via
the following environment variables:
CLIENT_ADDRESS
Remote client network address. Available as
of
Postfix 2.2.
CLIENT_HELO
Remote client EHLO command parameter. Available
as
of Postfix 2.2.
CLIENT_HOSTNAME
Remote client hostname. Available as of
Postfix
2.2.
CLIENT_PROTOCOL
Remote client protocol. Available as of

Postfix
2.2.
SASL_METHOD
SASL authentication method specified in the
remote
client AUTH command. Available as of Postfix 2.2.
SASL_SENDER
SASL sender address specified in the remote
client
MAIL FROM command. Available as of Postfix 2.2.
SASL_USERNAME
SASL username specified in the remote client
AUTH
command. Available as of Postfix 2.2.
The PATH environment variable is always reset to a

system-
dependent default path, and environment variables
whose
names are blessed by the export_environment
configuration
parameter are exported unchanged.
The current working directory is the mail queue

directory.
The local daemon prepends a "From sender time_stamp"

enve-
lope header to each message, prepends an X-Original-
To:
header with the recipient address as given to
Postfix,
prepends an optional Delivered-To: header with the
final
recipient envelope address, prepends a Return-Path:
header
with the sender envelope address, and appends no
empty
line.

EXTERNAL FILE DELIVERY

The delivery format depends on the destination
filename
syntax. The default is to use UNIX-style mailbox
format.
Specify a name ending in / for qmail-compatible
maildir
delivery.
The allow_mail_to_files configuration parameter

restricts
delivery to external files. The default setting
(alias,
forward) forbids file destinations in :include: files.
In the case of UNIX-style mailbox delivery, the local

dae-
mon prepends a "From sender time_stamp" envelope header
to
each message, prepends an X-Original-To: header with
the
recipient address as given to Postfix, prepends
an
optional Delivered-To: header with the final
recipient
envelope address, prepends a > character to lines
begin-
ning with "From ", and appends an empty line. The
enve-
lope sender address is available in the Return-
Path:
header. When the destination is a regular file, it
is
locked for exclusive access while delivery is in
progress.
In case of problems, an attempt is made to truncate a
reg-
ular file to its original length.
In the case of maildir delivery, the local daemon

prepends

an optional Delivered-To: header with the final

envelope
recipient address, and prepends an X-Original-To:
header
with the recipient address as given to Postfix. The
enve-
lope sender address is available in the Return-
Path:
header.
ADDRESS EXTENSION
The optional recipient_delimiter configuration
parameter
specifies how to separate address extensions from
local
recipient names.
For example, with "recipient_delimiter = +", mail

for
name+foo is delivered to the alias name+foo or to
the
alias name, to the destinations listed in ~name/.
for-
ward+foo or in ~name/.forward, to the mailbox owned by
the
user name, or it is sent back as undeliverable.
In all cases the local daemon prepends an optional

`Deliv-
ered-To: header line with the final recipient address.
DELIVERY RIGHTS
Deliveries to external files and external commands
are
made with the rights of the receiving user on whose
behalf
the delivery is made. In the absence of a user
context,
the local daemon uses the owner rights of the :
include:
file or alias database. When those files are owned by
the

superuser, delivery is made with the rights specified

with
the default_privs configuration parameter.
STANDARDS
DIAGNOSTICS
Cor-
rupted message files are marked so that the queue
manager
can move them to the corrupt queue afterwards.
Depending on the setting of the notify_classes

parameter,
the postmaster is notified of bounces and of other
trou-
ble.
BUGS
For security reasons, the message delivery status
of
external commands or of external files is never
check-
pointed to file. As a result, the program may
occasionally
deliver more than once to a command or external file.
Bet-
ter safe than sorry.
Mutually-recursive aliases or ~/.forward files are

not
detected early. The resulting mail forwarding loop
is
broken by the use of the Delivered-To: message header.
as
local(8) processes run for only a limited amount of
time.

Use the command "postfix reload" to speed up a change.

See
biff (yes)
Whether or not to use the local biff service.
expand_owner_alias (no)
When delivering to an alias "aliasname" that has
an
"owner-aliasname" companion alias, set the
envelope
sender address to the expansion of the
"owner-
aliasname" alias.
owner_request_special (yes)
Give special treatment to owner-listname and
list-
name-request address localparts: don't split
such
addresses when the recipient_delimiter is set
to
"-".
sun_mailtool_compatibility (no)
Obsolete SUN mailtool compatibility feature.
DELIVERY METHOD CONTROLS

The precedence of local(8) delivery methods from high
to
low is: aliases, .forward files, mailbox_transport,
mail-
box_command_maps, mailbox_command,
home_mailbox,
mail_spool_directory, fallback_transport and
luser_relay.

alias_maps (see 'postconf -d' output)

The alias databases that are used for local
(8)
delivery.
forward_path (see 'postconf -d' output)

The local(8) delivery agent search list for
finding
a .forward file with user-specified delivery
meth-
ods.
mailbox_transport (empty)
Optional message delivery transport that
the
local(8) delivery agent should use for
mailbox
delivery to all local recipients, whether or
not
they are found in the UNIX passwd database.
mailbox_command_maps (empty)
Optional lookup tables with per-recipient
external
commands to use for local(8) mailbox delivery.
mailbox_command (empty)
Optional external command that the local(8)
deliv-
ery agent should use for mailbox delivery.
home_mailbox (empty)
Optional pathname of a mailbox file relative to
a
local(8) user's home directory.
mail_spool_directory (see 'postconf -d' output)

The directory where local(8) UNIX-style
mailboxes
are kept.

fallback_transport (empty)
Optional message delivery transport that
the
local(8) delivery agent should use for names
that
are not found in the aliases(5) database or in
the
UNIX passwd database.
luser_relay (empty)
Optional catch-all destination for unknown local
(8)
recipients.
command_execution_directory (empty)
The local(8) delivery agent working directory
for
delivery to external command.
MAILBOX LOCKING CONTROLS

deliver_lock_attempts (20)
The maximal number of attempts to acquire an
exclu-
sive lock on a mailbox file or bounce(8) logfile.
deliver_lock_delay (1s)
The time between attempts to acquire an
exclusive
lock on a mailbox file or bounce(8) logfile.
stale_lock_time (500s)
The time after which a stale exclusive
mailbox
lockfile is removed.
mailbox_delivery_lock (see 'postconf -d' output)

How to lock a UNIX-style local(8) mailbox
before
attempting delivery.


command_time_limit (1000s)
Time limit for delivery to external commands.
the
vir-
dis-
plays.
local_destination_concurrency_limit (2)
The maximal number of parallel deliveries via
the
local mail delivery transport to the same
recipient
(when "local_destination_recipient_limit = 1")
or
the maximal number of parallel deliveries to
the
same local domain (when
"local_destination_recipi-
ent_limit > 1").
local_destination_recipient_limit (1)
The maximal number of recipients per message
deliv-
ery via the local mail delivery transport.
mailbox_size_limit (51200000)
The maximal size of any local(8) individual
mailbox
or maildir file, or zero (no limit).
SECURITY CONTROLS
allow_mail_to_commands (alias, forward)
Restrict local(8) mail delivery to external
com-

mands.
allow_mail_to_files (alias, forward)

Restrict local(8) mail delivery to external
files.
command_expansion_filter (see 'postconf -d' output)

Restrict the characters that the local(8)
delivery
agent allows in $name expansions of
$mailbox_com-
mand.
default_privs (nobody)
The default rights used by the local(8)
delivery
agent for delivery to external file or command.
forward_expansion_filter (see 'postconf -d' output)

delivery
$forward_path.
execution_directory_expansion_filter (see 'postconf -

d'
output)
delivery
$command_execu-
tion_directory.
and

to
a
export_environment (see 'postconf -d' output)

The list of environment variables that a
Postfix
process will export to non-Postfix processes.
ipc_timeout (3600s)
information
local_command_shell (empty)
Optional shell program for local(8) delivery
to
non-Postfix command.
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a
prepend_delivered_header (command, file, forward)

The message delivery contexts where the
Postfix
local(8) delivery agent prepends a Delivered-
To:
message header.

pro-
cess.
daemon
process.
propagate_unmatched_extensions (canonical, virtual)

What address lookup tables copy an address
exten-
sion from the lookup key to the lookup result.

direc-
tory.
exten-
sions (user+foo).
require_home_directory (no)
Whether or not a local(8) recipient's home
direc-
tory must exist before mail delivery is
attempted.
pro-
"smtpd"

FILES
The following are examples; details differ between
systems.
$HOME/.forward, per-user aliasing
/etc/aliases, sytem-wide alias database
/var/spool/mail, system mailboxes
SEE ALSO
bounce(8), delivery status reports
newaliases(1), create/update alias database
postalias(1), create/update alias database
aliases(5), format of alias database
LICENSE
this
software.
HISTORY
The Delivered-To: message header appears in the qmail
sys-
tem by Daniel Bernstein.
The maildir structure appears in the qmail system

by
Daniel Bernstein.
AUTHOR(S)
Wietse Venema
P.O. Box 704
LOCAL
(8)

Postfix manual - master(8)
MASTER(8) MASTER
(8)
NAME
master - Postfix master process
SYNOPSIS
master [-Dtv] [-c config_dir] [-e exit_time]
DESCRIPTION
The master daemon is the resident process that runs
Post-
fix daemons on demand: daemons to send or receive
messages
via the network, daemons to deliver mail locally,
etc.
These daemons are created on demand up to a
configurable
maximum number per service.
Postfix daemons terminate voluntarily, either after

being
idle for a configurable amount of time, or after
having
serviced a configurable number of requests. Exceptions
to
this rule are the resident queue manager and the
resident
address verification server.
The behavior of the master daemon is controlled by

the
master.cf configuration file, as described in master(5).
Options:
-c config_dir
Read the main.cf and master.cf configuration
files
in the named directory instead of the default
con-
http://www.subneural.net/postfix-master/master.8.html (1 of 6)01/16/2005 15:46:06

figuration directory. This also overrides the

con-
figuration files for other Postfix daemon
pro-
cesses.
-e exit_time
Terminate the master process after exit_time
sec-
onds. Child processes terminate at their
conve-
nience.
-D After initialization, run a debugger on the

master
process. The debugging command is specified
with
the debugger_command in the main.cf global
configu-
ration file.
-t Test mode. Return a zero exit status when the

mas-
ter.pid lock file does not exist or when that
file
is not locked. This is evidence that the
master
daemon is not running.

This
option is passed on to child processes. Multiple -
v
options make the software increasingly verbose.
Signals:
SIGHUP Upon receipt of a HUP signal (e.g., after

postfix
reload), the master process re-reads its
configura-
tion files. If a service has been removed from

the
master.cf file, its running processes are
termi-
nated immediately. Otherwise, running
processes
are allowed to terminate as soon as is
convenient,
so that changes in configuration settings
affect
only new service requests.
SIGTERM
Upon receipt of a TERM signal (e.g., after
postfix
abort), the master process passes the signal on
to
its child processes and terminates. This is
useful
for an emergency shutdown. Normally one would
ter-
minate only the master (postfix stop) and
allow
running processes to finish what they are doing.
DIAGNOSTICS
Problems are reported to syslogd(8).
ENVIRONMENT
MAIL_DEBUG
After initialization, start a debugger as
specified
with the debugger_command configuration
parameter
in the main.cf configuration file.
MAIL_CONFIG
Unlike most Postfix daemon processes, the master(8)
server
does not automatically pick up changes to main.cf.

Changes
to master.cf are never picked up automatically. Use
the
postfix reload command after a configuration change.

to
a
default_process_limit (100)
The default maximal number of Postfix child
pro-
cesses that provide a given service.
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a
service_throttle_time (60s)
How long the Postfix master(8) waits before
forking
a server that appears to be malfunctioning.
and


and
daemon programs.
debugger_command (empty)
The external command to execute when a Postfix
dae-
mon program is invoked with the -D option.
inet_interfaces (all)
The network interface addresses that this mail
sys-
tem receives mail on.

Postfix
pro-
cess.
queue
pro-
cess.
daemon
process.

direc-
tory.

pro-
"smtpd"
FILES
/etc/postfix/main.cf, global configuration file.
/etc/postfix/master.cf, master server configuration file.
/var/spool/postfix/pid/master.pid, master lock file.
SEE ALSO
verify(8), address verification
master(5), master.cf configuration file syntax
postconf(5), main.cf configuration parameter syntax
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
MASTER
(8)

MASTER(5) MASTER
(5)
NAME
master - Postfix master process configuration file format
DESCRIPTION
The Postfix mail system is implemented by small number
of
(mostly) client commands that are invoked by users, and
by
a larger number of services that run in the background.
Postfix services are implemented by daemon

processes.
These run in the background under control of the master
(8)
process. The master.cf configuration file defines how
a
client program connects to a service, and what daemon
pro-
gram runs when a service is requested. Most daemon
pro-
cesses are short-lived and terminate after serving
max_use
clients, or after inactivity for max_idle or more units
of
time.
All daemons specified here must speak a Postfix-

internal
protocol. In order to execute non-Postfix software use
the
local(8), pipe(8) or spawn(8) services, or run the
server
under control by inetd(8) or equivalent.
After changing master.cf you must execute "postfix

reload"
to reload the configuration.

SYNTAX
The general format of the master.cf file is as follows:
o Each logical line defines a single Postfix

service.
Each service is identified by its name and type
as
described below. When multiple lines specify
the
same service name and type, only the last one
is
remembered. Otherwise, the order of master.cf
ser-
vice definitions does not matter.

ignored,
character
is a `#'.

A
logi-
cal line.
Each logical line consists of eight fields separated

by
whitespace. These are described below in the order
as
they appear in the master.cf file.
Where applicable a field of "-" requests that the built-

in
default value be used. For boolean fields specify "y"
or
"n" to override the default value.
Service name
The service name syntax depends on the service
type
as described next.

Service type
Specify one of the following service types:
inet The service listens on a TCP/IP socket

and
is accessible via the network.
The service name is specified as host:

port,
denoting the host and port on which new
con-
nections should be accepted. The host
part
(and colon) may be omitted. Either host
or
port may be given in symbolic form (host
or
service name) or in numeric form (IP
address
or port number).
Examples: a service named 127.0.0.1:

smtp
receives mail via the loopback
interface
only; and a service named 10025 accepts
con-
nections on TCP port 10025 via all
inter-
faces configured with the
inet_interfaces
parameter.
unix The service listens on a UNIX-domain

socket
and is accessible for local clients only.
The service name is a pathname relative

to
the Postfix queue directory (pathname
con-

trolled with the queue_directory

configura-
tion parameter in main.cf).
On Solaris systems the unix type is

imple-
mented with streams sockets.
fifo The service listens on a FIFO (named

pipe)
and is accessible for local clients only.
The service name is a pathname relative

to
the Postfix queue directory (pathname
con-
trolled with the queue_directory
configura-
tion parameter in main.cf).
Private (default: y)
Whether or not access is restricted to the
mail
system. Internet (type inet) services can't
be
private.
Unprivileged (default: y)
Whether the service runs with root privileges or
as
the owner of the Postfix system (the owner name
is
controlled by the mail_owner configuration
variable
in the main.cf file).
The local(8), pipe(8), spawn(8), and virtual

(8)
daemons require privileges.
Chroot (default: y)
Whether or not the service runs chrooted to

the
mail queue directory (pathname is controlled by
the
queue_directory configuration variable in
the
main.cf file).
Chroot should not be used with the local

(8),
pipe(8) and spawn(8) daemons. Although the
prox-
ymap(8) server can run chrooted, doing so
defeats
most of the purpose of having that service in
the
first place.
The files in the examples/chroot-setup

subdirectory
of the Postfix source archive describe how to
set
up a Postfix chroot environment for your type
of
machine, and BASIC_CONFIGURATION_README
discusses
issues related to running daemons chrooted.
Wake up time (default: 0)

Automatically wake up the named service after
the
specified number of seconds. The wake up is
imple-
mented by connecting to the service and sending
a
wake up request. A ? at the end of the wake-
up
time field requests that wake up events be
sent
only to services that are actually being
used.
Specify 0 for no automatic wake up.

The pickup(8), qmgr(8) and flush(8) daemons

require
a wake up timer.
Process limit (default: $default_process_limit)

The maximum number of processes that may
execute
this service simultaneously. Specify 0 for no
pro-
cess count limit.
NOTE: Some Postfix services must be configured as

a
single-process service (for example, qmgr(8))
and
some services must be configured with no
process
limit (for example, cleanup(8)). These limits
must
not be changed.
Command name + arguments

The command to be executed. Characters that
are
special to the shell such as ">" or "|" have
no
special meaning here, and quotes cannot be used
to
protect arguments containing whitespace.
The command name is relative to the Postfix

daemon
directory (pathname is controlled by the
dae-
mon_directory configuration variable).
The command argument syntax for specific

commands
is specified in the respective daemon manual
page.
The following command-line options have the

same
effect for all daemon programs:
-D Run the daemon under control by the

command
specified with the debugger_command
variable
in the main.cf configuration file.
See
DEBUG_README for hints and tips.
-o name=value
Override the named main.cf
configuration
parameter. The parameter value can refer
to
other parameters as $name etc., just like
in
main.cf. See postconf(5) for syntax.
NOTE 1: do not specify whitespace around

the
"=". In parameter values, either
avoid
whitespace altogether, use commas instead
of
spaces, or consider overrides like "-
o
name=$override_parameter" with
$over-
ride_parameter set in main.cf.
NOTE 2: Over-zealous use of parameter

over-
rides makes the Postfix configuration
hard
to understand and maintain. At a
certain
point, it might be easier to configure
mul-
tiple instances of Postfix, instead of
con-

figuring multiple personalities via

mas-
ter.cf.
-v Increase the verbose logging level.

Specify
multiple -v options to make a Postfix
daemon
process increasingly verbose.
SEE ALSO
README FILES
BASIC_CONFIGURATION_README, basic configuration
DEBUG_README, Postfix debugging
LICENSE
this
software.
AUTHOR(S)
Initial version by
Magnus Baeck
Lund Institute of Technology
Sweden
Wietse Venema
P.O. Box 704
MASTER
(5)

Postfix manual - bounce(8)
BOUNCE(8) BOUNCE
(8)
NAME
bounce - Postfix message bounce or defer daemon
SYNOPSIS
bounce [generic Postfix daemon options]
DESCRIPTION
The bounce daemon maintains per-message log files
with
non-delivery status information. Each log file is
named
after the queue file that it corresponds to, and is
kept
in a queue subdirectory named after the service name
in
the master.cf file (either bounce, defer or trace).
This
program expects to be run from the master(8) process
man-
ager.
The bounce daemon processes two types of service

requests:
o Append a recipient (non-)delivery status record

to
a per-message log file.
o Enqueue a bounce message, with a copy of a per-

mes-
sage log file and of the corresponding
message.
When the bounce message is enqueued
successfully,
the per-message log file is deleted.
The software does a best notification effort. A non-

deliv-
http://www.subneural.net/postfix-master/bounce.8.html (1 of 5)01/16/2005 15:46:07

ery notification is sent even when the log file or

the
original message cannot be read.
Optionally, a bounce (defer, trace) client can

request
that the per-message log file be deleted when
the
requested operation fails. This is used by clients
that
cannot retry transactions by themselves, and that
depend
on retry logic in their own client.
STANDARDS
RFC 1894 (Delivery Status Notifications)
RFC 2045 (Format of Internet Message Bodies)
DIAGNOSTICS
as
bounce(8) processes run for only a limited amount of
time.

See
2bounce_notice_recipient (postmaster)
The recipient of undeliverable mail that cannot
be
returned to the sender.
backwards_bounce_logfile_compatibility (yes)
Produce additional bounce(8) logfile records
that
can be read by older Postfix versions.

bounce_notice_recipient (postmaster)
The recipient of postmaster notifications with
the
message headers of mail that Postfix did
not
deliver and of SMTP conversation transcripts
of
mail that Postfix did not receive.
bounce_size_limit (50000)
The maximal amount of original message text that
is
sent in a non-delivery notification.

and
to
a
delay_notice_recipient (postmaster)
the
message headers of mail that cannot be
delivered
within $delay_warning_time time units.
exclu-

exclusive
ipc_timeout (3600s)
information
mail_name (Postfix)
The mail system name that is displayed in
Received:
headers, in the SMTP greeting banner, and
in
bounced mail.
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a
notify_classes (resource, software)

The list of error classes that are reported to
the
postmaster.
pro-
cess.
daemon
process.


direc-
tory.
pro-
"smtpd"
FILES
/var/spool/postfix/bounce/* non-delivery records
/var/spool/postfix/defer/* non-delivery records
/var/spool/postfix/trace/* delivery status records
SEE ALSO
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
BOUNCE
(8)

Postfix manual - qmgr(8)
QMGR(8) QMGR
(8)
NAME
qmgr - Postfix queue manager
SYNOPSIS
qmgr [generic Postfix daemon options]
DESCRIPTION
The qmgr daemon awaits the arrival of incoming mail
and
arranges for its delivery via Postfix delivery
processes.
The actual mail routing strategy is delegated to the
triv-
ial-rewrite(8) daemon. This program expects to be
run
from the master(8) process manager.
Mail addressed to the local double-bounce address

is
logged and discarded. This stops potential loops
caused
by undeliverable bounce notifications.
MAIL QUEUES
The qmgr daemon maintains the following queues:
incoming
Inbound mail from the network, or mail picked up
by
the local pickup agent from the maildrop
directory.
active Messages that the queue manager has opened

for
delivery. Only a limited number of messages
is
allowed to enter the active queue (leaky
bucket
http://www.subneural.net/postfix-master/qmgr.8.html (1 of 13)01/16/2005 15:46:08

strategy, for a fixed delivery rate).
deferred
Mail that could not be delivered upon the
first
attempt. The queue manager implements
exponential
backoff by doubling the time between
delivery
attempts.
corrupt
Unreadable or damaged queue files are moved
here
for inspection.
hold Messages that are kept "on hold" are kept

here
until someone sets them free.
DELIVERY STATUS REPORTS

The qmgr daemon keeps an eye on per-message delivery
sta-
tus reports in the following directories. Each
status
report file has the same name as the corresponding
message
file:
bounce Per-recipient status information about why mail

is
bounced. These files are maintained by
the
bounce(8) daemon.
defer Per-recipient status information about why mail

is
delayed. These files are maintained by
the
defer(8) daemon.
trace Per-recipient status information as requested

with
the Postfix "sendmail -v" or "sendmail -bv"
com-
mand. These files are maintained by the trace
(8)
daemon.
The qmgr daemon is responsible for asking the bounce

(8),
defer(8) or trace(8) daemons to send delivery reports.
STRATEGIES
The queue manager implements a variety of strategies
for
either opening queue files (input) or for message
delivery
(output).
leaky bucket
This strategy limits the number of messages in
the
active queue and prevents the queue manager
from
running out of memory under heavy load.
fairness
When the active queue has room, the queue
manager
takes one message from the incoming queue and
one
from the deferred queue. This prevents a large
mail
backlog from blocking the delivery of new mail.
slow start
This strategy eliminates "thundering herd"
problems
by slowly adjusting the number of parallel
deliver-
ies to the same destination.
round robin

The queue manager sorts delivery requests by

desti-
nation. Round-robin selection prevents one
desti-
nation from dominating deliveries to other
destina-
tions.
exponential backoff
Mail that cannot be delivered upon the
first
attempt is deferred. The time interval
between
delivery attempts is doubled after each attempt.
destination status cache

The queue manager avoids unnecessary
delivery
attempts by maintaining a short-term, in-
memory
list of unreachable destinations.
preemptive message scheduling

The queue manager attempts to minimize the
average
per-recipient delay while still preserving the
cor-
rect per-message delays, using a sophisticated
pre-
emptive message scheduling.
TRIGGERS
On an idle system, the queue manager waits for the
arrival
of trigger events, or it waits for a timer to go off.
A
trigger is a one-byte message. Depending on the
message
received, the queue manager performs one of the
following
actions (the message is followed by the symbolic
constant
used internally by the software):

D (QMGR_REQ_SCAN_DEFERRED)
Start a deferred queue scan. If a deferred
queue
scan is already in progress, that scan will
be
restarted as soon as it finishes.
I (QMGR_REQ_SCAN_INCOMING)
Start an incoming queue scan. If an incoming
queue
scan is already in progress, that scan will
be
restarted as soon as it finishes.
A (QMGR_REQ_SCAN_ALL)
Ignore deferred queue file time stamps. The
request
affects the next deferred queue scan.
F (QMGR_REQ_FLUSH_DEAD)
Purge all information about dead transports
and
destinations.
W (TRIGGER_REQ_WAKEUP)
Wakeup call, This is used by the master server
to
instantiate servers that should not go away
for-
ever. The action is to start an incoming
queue
scan.
The qmgr daemon reads an entire buffer worth of

triggers.
Multiple identical trigger requests are collapsed
into
one, and trigger requests are sorted so that A and F
pre-
cede D and I. Thus, in order to force a deferred

queue
run, one would request A F D; in order to notify the
queue
manager of the arrival of new mail one would request I.
STANDARDS
None. The qmgr daemon does not interact with the
outside
world.
SECURITY
The qmgr daemon is not security sensitive. It reads
sin-
gle-character messages from untrusted local users,
and
thus may be susceptible to denial of service attacks.
The
qmgr daemon does not talk to the outside world, and it
can
be run at fixed low privilege in a chrooted environment.
DIAGNOSTICS
Problems and transactions are logged to the syslog
daemon.
Corrupted message files are saved to the corrupt queue
for
further inspection.

parameter,
trou-
ble.
BUGS
A single queue manager process has to compete for
disk
access with multiple front-end processes such as smtpd.
A
sudden burst of inbound mail can negatively impact
out-
bound delivery rates.

Changes to main.cf are not picked up automatically
as
qmgr(8) is a persistent process. Use the postfix
reload
command after a configuration change.

See
In the text below, transport is the first field in a

mas-
ter.cf entry.
allow_min_user (no)
Allow a recipient address to have `-' as the
first
character.
ACTIVE QUEUE CONTROLS

qmgr_clog_warn_time (300s)
The minimal delay between warnings that a
specific
destination is clogging up the Postfix
active
queue.
qmgr_message_active_limit (20000)
The maximal number of messages in the active
queue.
qmgr_message_recipient_limit (20000)
The maximal number of recipients held in memory
by
the Postfix queue manager, and the maximal size
of
the size of the short-term, in-memory "dead"
desti-
nation status cache.

qmgr_message_recipient_minimum (10)
The minimal number of in-memory recipients for
any
message.
default_recipient_limit (10000)
The default per-transport upper limit on the
number
of in-memory recipients.
transport_recipient_limit ($default_recipient_limit)
Idem, for delivery via the named message
transport.
default_extra_recipient_limit (1000)
The default value for the extra per-transport
limit
imposed on the number of in-memory recipients.
transport_extra_recipient_limit
($default_extra_recipi-
ent_limit)
transport.
DELIVERY CONCURRENCY CONTROLS

initial_destination_concurrency (5)
The initial per-destination concurrency level
for
parallel delivery to the same destination.
default_destination_concurrency_limit (20)
The default maximal number of parallel
deliveries
to the same destination.
transport_destination_concurrency_limit
($default_destina-
tion_concurrency_limit)

transport.
RECIPIENT SCHEDULING CONTROLS

default_destination_recipient_limit (50)
The default maximal number of recipients per
mes-
sage delivery.
transport_destination_recipient_limit
($default_destina-
tion_recipient_limit)
transport.
MESSAGE SCHEDULING CONTROLS

default_delivery_slot_cost (5)
How often the Postfix queue manager's scheduler
is
allowed to preempt delivery of one message
with
another.
transport_delivery_slot_cost
($default_delivery_slot_cost)
transport.
default_minimum_delivery_slots (3)
How many recipients a message must have in order
to
invoke the Postfix queue manager's scheduling
algo-
rithm at all.
transport_minimum_delivery_slots
($default_minimum_deliv-
ery_slots)
transport.
default_delivery_slot_discount (50)

The default value for transport-specific

_deliv-
ery_slot_discount settings.
transport_delivery_slot_discount
($default_deliv-
ery_slot_discount)
transport.
default_delivery_slot_loan (3)
The default value for transport-specific
_deliv-
ery_slot_loan settings.
transport_delivery_slot_loan
($default_delivery_slot_loan)
transport.
OTHER RESOURCE AND RATE CONTROLS

minimal_backoff_time (1000s)
The minimal time between attempts to deliver
a
deferred message.
maximal_backoff_time (4000s)
The maximal time between attempts to deliver
a
deferred message.
maximal_queue_lifetime (5d)
The maximal time a message is queued before it
is
sent back as undeliverable.
queue_run_delay (1000s)
The time between deferred queue scans by the
queue
manager.

transport_retry_time (60s)
The time between attempts by the Postfix queue
man-
ager to contact a malfunctioning message
delivery
transport.
bounce_queue_lifetime (5d)
The maximal time a bounce message is queued
before
it is considered undeliverable.
and
to
a
defer_transports (empty)
The names of message delivery transports
that
should not be delivered to unless someone
issues
"sendmail -q" or equivalent.
helpful_warnings (yes)
Log warnings about problematic configuration
set-
tings, and provide helpful suggestions.
ipc_timeout (3600s)
information

pro-
cess.
daemon
process.

direc-
tory.
pro-
"smtpd"
FILES
/var/spool/postfix/incoming, incoming queue
/var/spool/postfix/active, active queue
/var/spool/postfix/deferred, deferred queue
/var/spool/postfix/bounce, non-delivery status
/var/spool/postfix/defer, non-delivery status
/var/spool/postfix/trace, delivery status
SEE ALSO
trivial-rewrite(8), address routing

syslogd(8) system logging
README FILES
SCHEDULER_README, scheduling algorithm
QSHAPE_README, Postfix queue analysis
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
Scheduler enhancements:
Patrik Rak
Modra 6
155 00, Prague, Czech Republic
QMGR
(8)

Postfix manual - transport(5)
TRANSPORT(5) TRANSPORT
(5)
NAME
transport - format of Postfix transport table
SYNOPSIS
postmap /etc/postfix/transport
postmap -q "string" /etc/postfix/transport
postmap -q - /etc/postfix/transport <inputfile
DESCRIPTION
The optional transport table specifies a mapping
from
email addresses to message delivery transports and/
or
relay hosts. The mapping is used by the trivial-rewrite
(8)
daemon.
This mapping overrides the default routing that is

built
into Postfix:
mydestination
A list of domains that is by default delivered
via
$local_transport. This also includes domains
that
match $inet_interfaces or $proxy_interfaces.
virtual_mailbox_domains
via
$virtual_transport.
relay_domains
http://www.subneural.net/postfix-master/transport.5.html (1 of 9)01/16/2005 15:46:09

via
$relay_transport.
any other destination

Mail for any other destination is by default
deliv-
ered via $default_transport.
Normally, the transport table is specified as a text

file
The
for
command
postmap /etc/postfix/transport in order to rebuild
the
indexed file after changing the transport table.

NIS,
ordinary
indexed files.

regular-
expres-
In
different
TABLES"
TABLE FORMAT
follows:

pattern result
When pattern matches the recipient address
or
domain, use the corresponding result.

ignored,
character
is a `#'.
multi-line text
A
logi-
cal line.
The pattern specifies an email address, a domain name,

or
a domain name hierarchy, as described in section
"TABLE
LOOKUP".
The result is of the form transport:nexthop and

specifies
how or where to deliver mail. This is described in
section
"RESULT FORMAT".
TABLE LOOKUP
from
are
user+extension@domain transport:nexthop
Mail for user+extension@domain is delivered
through
transport to nexthop.

user@domain transport:nexthop
Mail for user@domain is delivered through
transport
to nexthop.
domain transport:nexthop
Mail for domain is delivered through transport
to
nexthop.
.domain transport:nexthop
Mail for any subdomain of domain is
delivered
through transport to nexthop. This applies
only
when the string transport_maps is not listed in
the
parent_domain_matches_subdomains configuration
set-
ting. Otherwise, a domain name matches itself
and
its subdomains.
Note 1: the special pattern * represents any address (i.

e.
it functions as the wild-card pattern).
Note 2: the null recipient address is looked up

as
$empty_address_recipient@$myhostname (default: mailer-
dae-
mon@hostname).
Note 3: user@domain or user+extension@domain lookup

is
available in Postfix 2.0 and later.
RESULT FORMAT
The lookup result is of the form transport:nexthop.
The
transport field specifies a mail delivery transport
such

as smtp or local. The nexthop field specifies where

and
how to deliver mail.
The transport field specifies the name of a mail

delivery
transport (the first name of a mail delivery service
entry
in the Postfix master.cf file).
The interpretation of the nexthop field is

transport
dependent. In the case of SMTP, specify a service on
a
non-default port as host:service, and disable MX
(mail
exchanger) DNS lookups with [host] or [host]:port. The
[]
form is required when you specify an IP address instead
of
a hostname.
A null transport and null nexthop result means "do

not
change": use the delivery transport and nexthop
informa-
tion that would be used when the entire transport
table
did not exist.
A non-null transport field with a null nexthop

field
resets the nexthop information to the recipient domain.
A null transport field with non-null nexthop field

does
not modify the transport information.
EXAMPLES
In order to deliver internal mail directly, while using
a
mail relay for all other mail, specify a null entry
for

internal destinations (do not change the delivery

trans-
port or the nexthop information) and specify a
wildcard
for all other destinations.
my.domain :
.my.domain :
* smtp:outbound-relay.my.domain
In order to send mail for example.com and its

subdomains
via the uucp transport to the UUCP host named example:
example.com uucp:example
.example.com uucp:example
When no nexthop host name is specified, the

destination
domain name is used instead. For example, the
following
directs mail for user@example.com via the slow
transport
to a mail exchanger for example.com. The slow
transport
could be configured to run at most one delivery process
at
a time:
example.com slow:
When no transport is specified, Postfix uses the

transport
that matches the address domain class (see
DESCRIPTION
above). The following sends all mail for example.com
and
its subdomains to host gateway.example.com:
example.com :[gateway.example.com]
.example.com :[gateway.example.com]

In the above example, the [] suppress MX lookups.

This
prevents mail routing loops when your machine is
primary
MX host for example.com.
In the case of delivery via SMTP, one may specify

host-
name:service instead of just a host:
example.com smtp:bar.example:2025
This directs mail for user@example.com to host bar.

example
port 2025. Instead of a numerical port a symbolic name
may
be used. Specify [] around the hostname if MX lookups
must
be disabled.
The error mailer can be used to bounce mail:
.example.com error:mail for *.example.com is

not
deliverable
This causes all mail for user@anything.example.com to

be
bounced.

when
For
syntax,

to
the entire address being looked up.

Thus,
some.domain.hierarchy is not looked up via its
parent
domains, nor is user+foo@domain looked up as
user@domain.

the
search
string.
Results are the same as with indexed file lookups,

with
from
TCP-BASED TABLES
when
descrip-
see
Postfix
version 2.1.
Each lookup operation uses the entire recipient

address
once. Thus, some.domain.hierarchy is not looked up
via
its parent domains, nor is user+foo@domain looked up
as
user@domain.
Results are the same as with indexed file lookups.
relevant.


See
empty_address_recipient
The address that is looked up instead of the
null
sender address.
parent_domain_matches_subdomains
List of Postfix features that use domain.tld
pat-
terns to match sub.domain.tld (as opposed
to
requiring .domain.tld patterns).
transport_maps
List of transport lookup tables.
SEE ALSO
trivial-rewrite(8), rewrite and resolve addresses
README FILES
FILTER_README, external content filter
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
TRANSPORT
(5)

Postfix manual - canonical(5)
CANONICAL(5) CANONICAL
(5)
NAME
canonical - format of Postfix canonical table
SYNOPSIS
postmap /etc/postfix/canonical
postmap -q "string" /etc/postfix/canonical
postmap -q - /etc/postfix/canonical <inputfile
DESCRIPTION
The optional canonical table specifies an address
mapping
for local and non-local addresses. The mapping is used
by
the cleanup(8) daemon. The address mapping is
recursive.
Normally, the canonical table is specified as a text

file
The
for
command
postmap /etc/postfix/canonical in order to rebuild
the
indexed file after changing the text file.

NIS,
ordinary
indexed files.

regular-
http://www.subneural.net/postfix-master/canonical.5.html (1 of 8)01/16/2005 15:46:09


expres-
In
different
TABLES"
By default the canonical mapping affects both

message
header addresses (i.e. addresses that appear inside
mes-
sages) and message envelope addresses (for example,
the
addresses that are used in SMTP protocol commands).
Think
Sendmail rule set S3, if you like. This is
controlled
with the canonical_classes parameter.
Typically, one would use the canonical table to

replace
login names by Firstname.Lastname, or to clean
up
addresses produced by legacy mail systems.
The canonical mapping is not to be confused with

virtual
domain support. Use the virtual(5) map for that purpose.
The canonical mapping is not to be confused with

local
aliasing. Use the aliases(5) map for that purpose.
TABLE FORMAT
follows:
pattern result
When pattern matches a mail address, replace it

by
the corresponding result.

ignored,
character
is a `#'.
multi-line text
A
logi-
cal line.

from
are
user@domain address
user@domain is replaced by address. This form
has
the highest precedence.
This is useful to clean up addresses produced

by
legacy mail systems. It can also be used to
pro-
duce Firstname.Lastname style addresses, but
see
below for a simpler solution.
user address
user@site is replaced by address when site is
equal
to $myorigin, when site is listed in
$mydestina-
tion, or when it is listed in $inet_interfaces

or
$proxy_interfaces.
This form is useful for replacing login names

by
Firstname.Lastname.
@domain address
Every address in domain is replaced by
address.
This form has the lowest precedence.
In all the above forms, when address has the form

@other-
domain, the result is the same user in otherdomain.
ADDRESS EXTENSION
recip-
order
becomes: user+foo@domain, user@domain, user+foo, user,
and
@domain.
The propagate_unmatched_extensions parameter

controls
whether an unmatched address extension (+foo) is
propa-
gated to the result of table lookup.

when
For
syntax,

to

the entire address being looked up. Thus, user@domain

mail
addresses are not broken up into their user and
@domain
constituent parts, nor is user+foo broken up into user
and
foo.

the
search
string.

with
from
TCP-BASED TABLES
when
descrip-
see
Postfix
version 2.1.
Each lookup operation uses the entire address once.

Thus,
their
user and @domain constituent parts, nor is user+foo
broken
BUGS


conventions.
relevant.
See
canonical_classes
What addresses are subject to canonical
address
mapping.
canonical_maps
List of canonical mapping tables.
recipient_canonical_maps
Address mapping lookup table for envelope
and
header recipient addresses.
sender_canonical_maps
Address mapping lookup table for envelope
and
header sender addresses.
propagate_unmatched_extensions
A list of address rewriting or forwarding
mecha-
nisms that propagate an address extension from
the
original address to the result. Specify zero
or
more of canonical, virtual, alias, forward,
or
include.
Other parameters of interest:
inet_interfaces

The network interface addresses that this

system
receives mail on. You need to stop and start
Post-
fix when this parameter changes.
proxy_interfaces
Other interfaces that this machine receives mail
on
by way of a proxy agent or network address
transla-
tor.
masquerade_classes
List of address classes subject to
masquerading:
zero or more of envelope_sender,
envelope_recipi-
ent, header_sender, header_recipient.
masquerade_domains
List of domains that hide their subdomain
struc-
ture.
masquerade_exceptions
List of user names that are not subject to
address
masquerading.
mydestination
List of domains that this mail system
considers
local.
myorigin
The domain that is appended to locally-posted
mail.
owner_request_special
Give special treatment to owner-xxx and xxx-
request

addresses.
SEE ALSO
cleanup(8), canonicalize and enqueue mail
virtual(5), virtual aliasing
README FILES
ADDRESS_REWRITING_README, address rewriting guide
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
CANONICAL
(5)

Postfix manual - virtual(5)
VIRTUAL(5) VIRTUAL
(5)
NAME
virtual - format of Postfix virtual alias table
SYNOPSIS
postmap /etc/postfix/virtual
postmap -q "string" /etc/postfix/virtual
postmap -q - /etc/postfix/virtual <inputfile
DESCRIPTION
The optional virtual alias table specifies address
alias-
ing for arbitrary local or non-local recipient
addresses.
Virtual aliasing is recursive, and is done by the
Postfix
cleanup(8) daemon.
The main applications of virtual aliasing are:
o To redirect mail for one address to one or

more
addresses.
o To implement virtual alias domains where

all
addresses are aliased to addresses in
other
domains.
Virtual alias domains are not to be confused

with
the virtual mailbox domains that are
implemented
with the Postfix virtual(8) mail delivery
agent.
With virtual mailbox domains, each
http://www.subneural.net/postfix-master/virtual.5.html (1 of 9)01/16/2005 15:46:10

recipient
address can have its own mailbox.
Virtual aliasing is applied only to recipient

envelope
addresses, and does not affect message headers.
Think
Sendmail rule set S0, if you like. Use canonical(5)
map-
ping to rewrite header and envelope addresses in
general.
Normally, the virtual alias table is specified as a

text
file that serves as input to the postmap(1) command.
The
for
command
postmap /etc/postfix/virtual in order to rebuild
the
indexed file after changing the text file.

NIS,
ordinary
indexed files.

regular-
expres-
In
different
TABLES"

TABLE FORMAT
follows:
pattern result
When pattern matches a mail address, replace it
by
the corresponding result.

ignored,
character
is a `#'.
multi-line text
A
logi-
cal line.

from
are
user@domain address, address, ...

Mail for user@domain is redirected to
address.
This form has the highest precedence.
user address, address, ...

Mail for user@site is redirected to address
when
site is equal to $myorigin, when site is listed
in
$mydestination, or when it is listed
in
$inet_interfaces or $proxy_interfaces.

This functionality overlaps with functionality

of
the local aliases(5) database. The difference
is
that virtual mapping can be applied to non-
local
addresses.
@domain address, address, ...

Mail for any user in domain is redirected
to
address. This form has the lowest precedence.
In all the above forms, when address has the form

@other-
domain, the result is the same user in otherdomain.
This
works for the first address in the expansion only.
ADDRESS EXTENSION
recip-
order
and
@domain.
The propagate_unmatched_extensions parameter

controls
whether an unmatched address extension (+foo) is
propa-
gated to the result of table lookup.
VIRTUAL ALIAS DOMAINS

Besides virtual aliases, the virtual alias table can
also
be used to implement virtual alias domains. With a
virtual
alias domain, all recipient addresses are aliased
to

addresses in other domains.
Virtual alias domains are not to be confused with the

vir-
tual mailbox domains that are implemented with the
Postfix
virtual(8) mail delivery agent. With virtual
mailbox
domains, each recipient address can have its own
mailbox.
With a virtual alias domain, the virtual domain has

its
own user name space. Local (i.e. non-virtual)
usernames
are not visible in a virtual alias domain. In
particular,
local aliases(5) and local mailing lists are not
visible
as localname@virtual-alias.domain.
Support for a virtual alias domain looks like:
Note: some systems use dbm databases instead of

hash.
See the output from postconf -m for available
database
types.
virtual-alias.domain anything (right-hand content
does not matter)
postmaster@virtual-alias.domain postmaster
user1@virtual-alias.domain address1
user2@virtual-alias.domain address2, address3
The virtual-alias.domain anything entry is required for

a
virtual alias domain. Without this entry, mail is

rejected
with "relay access denied", or bounces with "mail
loops
back to myself".
Do not specify virtual alias domain names in the main.

cf
mydestination or relay_domains configuration parameters.
With a virtual alias domain, the Postfix SMTP

server
accepts mail for known-user@virtual-alias.domain,
and
rejects mail for unknown-user@virtual-alias.domain
as
undeliverable.
Instead of specifying the virtual alias domain name

via
the virtual_alias_maps table, you may also specify it
via
the main.cf virtual_alias_domains configuration
parameter.
This latter parameter uses the same syntax as the main.
cf
mydestination configuration parameter.

when
For
syntax,

to
mail
@domain


and
foo.

the
search
string.

with
from
TCP-BASED TABLES
when
descrip-
see
Postfix
version 2.1.

Thus,
their
broken
BUGS
conventions.


relevant
to this topic. See the Postfix main.cf file for
syntax
details and for default values. Use the postfix
reload
command after a configuration change.
virtual_alias_maps
List of virtual aliasing tables.
virtual_alias_domains
List of virtual alias domains. This uses the
same
syntax as the mydestination parameter.
propagate_unmatched_extensions
A list of address rewriting or forwarding
mecha-
nisms that propagate an address extension from
the
original address to the result. Specify zero
or
more of canonical, virtual, alias, forward,
or
include.
inet_interfaces
system
Post-
mydestination
considers
local.
myorigin

The domain that is appended to any address

that
does not have a domain.
Give special treatment to owner-xxx and xxx-
request
addresses.
proxy_interfaces
on
transla-
tor.
SEE ALSO
canonical(5), canonical address mapping
README FILES
VIRTUAL_README, domain hosting guide
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
VIRTUAL
(5)

VIRTUAL(8) VIRTUAL
(8)
NAME
virtual - Postfix virtual domain mail delivery agent
SYNOPSIS
virtual [generic Postfix daemon options]
DESCRIPTION
The virtual(8) delivery agent is designed for virtual
mail
hosting services. Originally based on the Postfix local
(8)
delivery agent, this agent looks up recipients with
map
lookups of their full recipient address, instead of
using
hard-coded unix password file lookups of the address
local
part only.
This delivery agent only delivers mail. Other

features
such as mail forwarding, out-of-office
notifications,
etc., must be configured via virtual_alias maps or
via
similar lookup mechanisms.
MAILBOX LOCATION
The mailbox location is controlled by the
virtual_mail-
box_base and virtual_mailbox_maps configuration
parameters
(see below). The virtual_mailbox_maps table is indexed
by
the recipient address as described under TABLE
SEARCH
ORDER below.

The mailbox pathname is constructed as follows:
$virtual_mailbox_base/$virtual_mailbox_maps(recipient)
where recipient is the full recipient address.
UNIX MAILBOX FORMAT

When the mailbox location does not end in /, the
message
is delivered in UNIX mailbox format. This format
stores
multiple messages in one textfile.
The virtual delivery agent prepends a "From

sender
time_stamp" envelope header to each message, prepends
a
Delivered-To: message header with the envelope
recipient
address, prepends an X-Original-To: header with the
recip-
ient address as given to Postfix, prepends a Return-
Path:
message header with the envelope sender address,
prepends
a > character to lines beginning with "From ", and
appends
an empty line.
The mailbox is locked for exclusive access while

delivery
is in progress. In case of problems, an attempt is made
to
truncate the mailbox to its original length.
QMAIL MAILDIR FORMAT

When the mailbox location ends in /, the message is
deliv-
ered in qmail maildir format. This format stores one
mes-
sage per file.

The virtual delivery agent daemon prepends a Delivered-

To:
message header with the final envelope recipient
address,
prepends an X-Original-To: header with the
recipient
address as given to Postfix, and prepends a Return-
Path:
message header with the envelope sender address.
By definition, maildir format does not require

applica-
tion-level file locking during mail delivery or
retrieval.
MAILBOX OWNERSHIP
Mailbox ownership is controlled by the
virtual_uid_maps
and virtual_gid_maps lookup tables, which are indexed
with
the full recipient address. Each table provides a
string
with the numerical user and group ID, respectively.
The virtual_minimum_uid parameter imposes a lower bound

on
numerical user ID values that may be specified in any
vir-
tual_uid_maps.
TABLE SEARCH ORDER

Normally, a lookup table is specified as a text file
that
serves as input to the postmap(1) command. The result,
an
indexed file in dbm or db format, is used for fast
search-
ing by the mail system.
The search order is as follows. The search stops upon

the
first successful lookup.

o When the recipient has an optional address

exten-
sion the user+extension@domain.tld address
is
looked up first.
With Postfix versions before 2.1, the

optional
address extension is always ignored.
o The user@domain.tld address, without address

exten-
sion, is looked up next.
o Finally, the recipient @domain is looked up.

NIS,
ordinary
indexed files.
Alternatively, a table can be provided as a

regular-
expres-
sions. In that case, only the full recipient address
is
given to the regular-expression map.
SECURITY
The virtual delivery agent is not security sensitive,
pro-
vided that the lookup tables with recipient user/group
ID
information are adequately protected. This program is
not
designed to run chrooted.
STANDARDS

DIAGNOSTICS
Mail bounces when the recipient has no mailbox or when
the
recipient is over disk quota. In all other cases, mail
for
an existing recipient is deferred and a warning is
logged.

Cor-
manager
can move them to the corrupt queue afterwards.

parameter,
trou-
ble.
BUGS
This delivery agent supports address extensions in
email
addresses and in lookup table keys, but does not
propagate
address extension information to the result of
table
lookup.
Postfix should have lookup tables that can return

multiple
result attributes. In order to avoid the inconvenience
of
maintaining three tables, use an LDAP or MYSQL database.
Changes to main.cf are picked up automatically, as
vir-
tual(8) processes run for only a limited amount of
time.


See
MAILBOX DELIVERY CONTROLS

virtual_mailbox_base (empty)
A prefix that the virtual(8) delivery
agent
prepends to all pathname results from
$vir-
tual_mailbox_maps table lookups.
virtual_mailbox_maps (empty)
Optional lookup tables with all valid addresses
in
the domains that match $virtual_mailbox_domains.
virtual_minimum_uid (100)
The minimum user ID value that the virtual
(8)
delivery agent accepts as a result from
$vir-
tual_uid_maps table lookup.
virtual_uid_maps (empty)
Lookup tables with the per-recipient user ID
that
the virtual(8) delivery agent uses while writing
to
the recipient's mailbox.
virtual_gid_maps (empty)
Lookup tables with the per-recipient group ID
for
virtual(8) mailbox delivery.
virtual_mailbox_domains ($virtual_mailbox_maps)
Postfix is final destination for the specified

list
of domains; mail is delivered via the
$vir-
tual_transport mail delivery transport.
virtual_transport (virtual)
domains
that match the $virtual_mailbox_domains
parameter
value.
LOCKING CONTROLS
virtual_mailbox_lock (see 'postconf -d' output)
How to lock a UNIX-style virtual(8) mailbox
before
exclu-
exclusive
mailbox

virtual_destination_concurrency_limit
($default_destina-
The maximal number of parallel deliveries to
the
same destination via the virtual message
delivery

transport.
virtual_destination_recipient_limit
($default_destina-
The maximal number of recipients per delivery
via
the virtual message delivery transport.
virtual_mailbox_limit (51200000)
The maximal size in bytes of an individual
mailbox
or maildir file, or zero (no limit).
and
to
a
ipc_timeout (3600s)
information
max_idle (100s)
Postfix
request
before exiting.
max_use (100)

a
pro-
cess.
daemon
process.

direc-
tory.
pro-
"smtpd"
SEE ALSO
README_FILES
VIRTUAL_README, domain hosting howto
LICENSE
this
software.

HISTORY
This delivery agent was originally based on the
Postfix
local delivery agent. Modifications mainly consisted
of
removing code that either was not applicable or that
was
not safe in this context: aliases, ~user/.forward
files,
delivery to "|command" or to /file/name.
The Delivered-To: message header appears in the qmail

sys-
tem by Daniel Bernstein.
The maildir structure appears in the qmail system

by
Daniel Bernstein.
AUTHOR(S)
Wietse Venema
P.O. Box 704
Andrew McNamara
andrewm@connect.com.au
connect.com.au Pty. Ltd.
Level 3, 213 Miller St
North Sydney 2060, NSW, Australia
VIRTUAL
(8)

Postfix Bottleneck Analysis

This document describes the qshape(1) program which helps the administrator understand the
Postfix queue message distribution sorted by time and by sender or recipient domain. qshape(1)
is bundled with the Postfix 2.1 source under the "auxiliary" directory.
In order to understand the output of qshape(1), it useful to understand the various Postfix
queues. To this end the role of each Postfix queue directory is described briefly in the
"Background info: Postfix queue directories" section near the end of this document.
This document covers the following topics:
● Introducing the qshape tool

● Trouble shooting with qshape
● Example 1: Healthy queue
● Example 2: Deferred queue full of dictionary attack bounces
● Example 3: Congestion in the active queue
● Example 4: High volume destination backlog
● Background info: Postfix queue directories
❍ The "maildrop" queue
❍ The "hold" queue
❍ The "incoming" queue
❍ The "active" queue
❍ The "deferred" queue
● Credits
Introducing the qshape tool
http://www.subneural.net/postfix-master/QSHAPE_README.html (1 of 16)01/16/2005 15:46:12

When mail is draining slowly or the queue is unexpectedly large, run qshape(1) as the super-
user (root) to help zero in on the problem. The qshape(1) program displays a tabular view of
the Postfix queue contents.
● On the horizontal axis, it displays the queue age with fine granularity for recent
messages and (geometrically) less fine granularity for older messages.
● The vertical axis displays the destination (or with the "-s" switch the sender) domain.
Domains with the most messages are listed first.
For example, in the output below we see the top 10 lines of the (mostly forged) sender domain
distribution for captured spam in the "hold" queue:
$ qshape -s hold | head

T 5 10 20 40 80 160 320 640
1280 1280+
TOTAL 486 0 0 1 0 0 2 4
20 40 419
yahoo.com 14 0 0 1 0 0 0 0
1 0 12
extremepricecuts.net 13 0 0 0 0 0 0 0
2 0 11
ms35.hinet.net 12 0 0 0 0 0 0 0
0 1 11
winnersdaily.net 12 0 0 0 0 0 0 0
2 0 10
hotmail.com 11 0 0 0 0 0 0 0
0 1 10
worldnet.fr 6 0 0 0 0 0 0 0
0 0 6
ms41.hinet.net 6 0 0 0 0 0 0 0
0 0 6
osn.de 5 0 0 0 0 0 1 0
0 0 4
● The "T" column shows the total (in this case sender) count for each domain. The
columns with numbers above them, show counts for messages aged fewer than that
many minutes, but not younger than the age limit for the previous column. The row
labeled "TOTAL" shows the total count for all domains.
● In this example, there are 14 messages allegedly from yahoo.com, 1 between 10 and 20

minutes old, 1 between 320 and 640 minutes old and 12 older than 1280 minutes (1440
minutes in a day).
By default, qshape shows statistics for the union of both the incoming and active queues which
are the most relevant queues to look at when analyzing performance.
One can request an alternate list of queues:
$ qshape deferred | less

$ qshape incoming active deferred | less
this will show the age distribution of the deferred queue or the union of the incoming active
and deferred queues.
Command line options control the number of display "buckets", the age limit for the smallest
bucket, display of parent domain counts and so on. The "-h" option outputs a summary of the
available switches.
Trouble shooting with qshape

Large numbers in the qshape output represent a large number of messages that are destined to
(or alleged to come from) a particular domain. It should be possible to tell at a glance which
domains dominate the queue sender or recipient counts, approximately when a burst of mail
started, and when it stopped.
The problem destinations or sender domains appear near the top left corner of the output table.
Remember that the active queue can accommodate up to 20000 ($qmgr_message_active_limit)
messages. To check wether this limit has been reached, use:
$ qshape -s active | head (show sender

statistics)
If the total sender count is below 20000 the active queue is not yet saturated, any high volume
sender domains show near the top of the output.
The active queue is also limited to at most 20000 recipient addresses

($qmgr_message_recipient_limit). To check for exhaustion of this limit use:
$ qshape active | head (show recipient

statistics)

Having found the high volume domains, it is often useful to search the logs for recent messages
pertaining to the domains in question.
# Find deliveries to example.com

#
$ tail -10000 /var/log/maillog |
egrep -i ': to=<.*@example\.com>,' |
less
# Find messages from example.com

#
$ tail -10000 /var/log/maillog |
egrep -i ': from=<.*@example\.com>,' |
less
You may want to drill in on some specific queue ids:
# Find all messages for a specific queue id.

#
$ tail -10000 /var/log/maillog | egrep ': 2B2173FF68:
'
Also look for queue manager warning messages in the log. These warnings can suggest
strategies to reduce congestion.
$ egrep 'qmgr.*(panic|fatal|error|warning):' /var/log/

maillog
When all else fails try the Postfix mailing list for help, but please don't forget to include the top
10 or 20 lines of qshape(1) output.
Example 1: Healthy queue

When looking at just the incoming and active queues, under normal conditions (no congestion)
the incoming and active queues are nearly empty. Mail leaves the system almost as quickly as
it comes in or is deferred without congestion in the active queue.
$ qshape (show incoming and active queue

status)

T 5 10 20 40 80 160 320 640 1280

1280+
TOTAL 5 0 0 0 1 0 0 0 1
1 2
meri.uwasa.fi 5 0 0 0 1 0 0 0 1
1 2
If one looks at the two queues separately, the incoming queue is empty or perhaps briefly has
one or two messages, while the active queue holds more messages and for a somewhat longer
time:
$ qshape incoming
T 5 10 20 40 80 160 320 640 1280

1280+
TOTAL 0 0 0 0 0 0 0 0 0
0 0
$ qshape active
T 5 10 20 40 80 160 320 640 1280

1280+
TOTAL 5 0 0 0 1 0 0 0 1
1 2
meri.uwasa.fi 5 0 0 0 1 0 0 0 1
1 2
Example 2: Deferred queue full of dictionary attack

bounces
This is from a server where recipient validation is not yet available for some of the hosted
domains. Dictionary attacks on the unvalidated domains result in bounce backscatter. The
bounces dominate the queue, but with proper tuning they do not saturate the incoming or active
queues. The high volume of deferred mail is not a direct cause for alarm.
$ qshape deferred | head
T 5 10 20 40 80 160 320 640

1280 1280+

TOTAL 2234 4 2 5 9 31 57 108

201 464 1353
heyhihellothere.com 207 0 0 1 1 6 6 8
25 68 92
pleazerzoneprod.com 105 0 0 0 0 0 0 0
5 44 56
groups.msn.com 63 2 1 2 4 4 14 14
14 8 0
orion.toppoint.de 49 0 0 0 1 0 2 4
3 16 23
kali.com.cn 46 0 0 0 0 1 0 2
6 12 25
meri.uwasa.fi 44 0 0 0 0 1 0 2
8 11 22
gjr.paknet.com.pk 43 1 0 0 1 1 3 3
6 12 16
aristotle.algonet.se 41 0 0 0 0 0 1 2
11 12 15
The domains shown are mostly bulk-mailers and all the volume is the tail end of the time
distribution, showing that short term arrival rates are moderate. Larger numbers and lower
message ages are more indicative of current trouble. Old mail still going nowhere is largely
harmless so long as the active and incoming queues are short. We can also see that the groups.
msn.com undeliverables are low rate steady stream rather than a concentrated dictionary attack
that is now over.
$ qshape -s deferred | head
T 5 10 20 40 80 160 320 640

1280 1280+
TOTAL 2193 4 4 5 8 33 56 104 205
465 1309
MAILER-DAEMON 1709 4 4 5 8 33 55 101 198
452 849
example.com 263 0 0 0 0 0 0 0 0
2 261
example.org 209 0 0 0 0 0 1 3 6
11 188
example.net 6 0 0 0 0 0 0 0 0
0 6
example.edu 3 0 0 0 0 0 0 0 0
0 3

example.gov 2 0 0 0 0 0 0 0 1
0 1
example.mil 1 0 0 0 0 0 0 0 0
0 1
Looking at the sender distribution, we see that as expected most of the messages are bounces.
Example 3: Congestion in the active queue

This example is taken from a Feb 2004 discussion on the Postfix Users list. Congestion was
reported with the active and incoming queues large and not shrinking despite very large
delivery agent process limits. The thread is archived at: http://groups.google.com/groups?
th=636626c645f5bbde
Using an older version of qshape(1) it was quickly determined that all the messages were for
just a few destinations:
$ qshape (show incoming and active queue

status)
T A 5 10 20 40 80
160 320 320+
TOTAL 11775 9996 0 0 1 1 42
94 221 1420
user.sourceforge.net 7678 7678 0 0 0 0
0 0 0 0
lists.sourceforge.net 2313 2313 0 0 0 0
0 0 0 0
gzd.gotdns.com 102 0 0 0 0 0
0 0 2 100
The "A" column showed the count of messages in the active queue, and the numbered columns
showed totals for the deferred queue. At 10000 messages (Postfix 1.x active queue size limit)
the active queue is full. The incoming was growing rapidly.
With the trouble destinations clearly identified, the administrator quickly found and fixed the
problem. It is substantially harder to glean the same information from the logs. While a careful
reading of mailq(1) output should yield similar results, it is much harder to gauge the
magnitude of the problem by looking at the queue one message at a time.

Example 4: High volume destination backlog

When a site you send a lot of email to is down or slow, mail messages will rapidly build up in
the deferred queue, or worse, in the active queue. The qshape output will show large numbers
for the destination domain in all age buckets that overlap the starting time of the problem:
$ qshape deferred | head
T 5 10 20 40 80 160 320
640 1280 1280+
TOTAL 5000 200 200 400 800 1600 1000 200
200 200 200
highvolume.com 4000 160 160 320 640 1280 1440 0
0 0 0
...
Here the "highvolume.com" destination is continuing to accumulate deferred mail. The

incoming and active queues are fine, but the deferred queue started growing some time
between 1 and 2 hours ago and continues to grow.
If the high volume destination is not down, but is instead slow, one might see similar
congestion in the active queue. Active queue congestion is a greater cause for alarm; one might
need to take measures to ensure that the mail is deferred instead or even add an access(5) rule
asking the sender to try again later.
If a high volume destination exhibits frequent bursts of consecutive connections refused by all
MX hosts or "421 Server busy errors", it is possible for the queue manager to mark the
destination as "dead" despite the transient nature of the errors. The destination will be retried
again after the expiration of a $minimal_backoff_time timer. If the error bursts are frequent
enough it may be that only a small quantity of email is delivered before the destination is again
marked "dead".
The MTA that has been observed most frequently to exhibit such bursts of errors is Microsoft
Exchange, which refuses connections under load. Some proxy virus scanners in front of the
Exchange server propagate the refused connection to the client as a "421" error.
Note that it is now possible to configure Postfix to exhibit similarly erratic behavior by
misconfiguring the anvil(8) server (not included in Postfix 2.1.). Do not use anvil(8) for steady-
state rate limiting, its purpose is DoS prevention and the rate limits set should be very
generous!

In the long run it is hoped that the Postfix dead host detection and concurrency control
mechanism will be tuned to be more "noise" tolerant. If one finds oneself needing to deliver a
high volume of mail to a destination that exhibits frequent brief bursts of errors, there is a
subtle workaround.
● In master.cf set up a dedicated clone of the "smtp" transport for the destination in
question.
● In master.cf configure a reasonable process limit for the transport (a number in the 10-
20 range is typical).
● IMPORTANT!!! In main.cf configure a very large initial and destination concurrency

limit for this transport (say 200).
initial_destination_concurrency = 200
transportname_destination_concurrency_limit = 200
Where transportname is the name of the master.cf entry in question.
The effect of this surprising configuration is that up to 200 consecutive errors are tolerated
without marking the destination dead, while the total concurrency remains reasonable (10-20
processes). This trick is only for a very specialized situation: high volume delivery into a
channel with multi-error bursts that is capable of high throughput, but is repeatedly throttled by
the bursts of errors.
When a destination is unable to handle the load even after the Postfix process limit is reduced
to 1, a desperate measure is to insert brief delays between delivery attempts.
● In the transport map entry for the problem destination, specify a dead host as the
primary nexthop.
● In the master.cf entry for the transport specify the problem destination as the
fallback_relay and specify a small smtp_connect_timeout value.
problem.example.com slow:[dead.host]
maxproc command

slow unix - - n -
1 smtp
-o fallback_relay=problem.example.com
-o smtp_connect_timeout=1
This solution forces the Postfix smtp(8) client to wait for $smtp_connect_timeout seconds
between deliveries. The solution depends on Postfix connection management details, and needs
to be updated when SMTP connection caching is introduced.
Hopefully a more elegant solution to these problems will be found in the future.
Background info: Postfix queue directories

The following sections describe Postfix queues: their purpose, what normal behavior looks
like, and how to diagnose abnormal behavior.
The "maildrop" queue
Messages that have been submitted via the Postfix sendmail(1) command, but not yet brought
into the main Postfix queue by the pickup(8) service, await processing in the "maildrop" queue.
Messages can be added to the "maildrop" queue even when the Postfix system is not running.
They will begin to be processed once Postfix is started.
The "maildrop" queue is drained by the single threaded pickup(8) service scanning the queue
directory periodically or when notified of new message arrival by the postdrop(1) program.
The postdrop(1) program is a setgid helper that allows the unprivileged Postfix sendmail(1)
program to inject mail into the "maildrop" queue and to notify the pickup(8) service of its
arrival.
All mail that enters the main Postfix queue does so via the cleanup(8) service. The cleanup
service is responsible for envelope and header rewriting, header and body regular expression
checks, automatic bcc recipient processing and guaranteed insertion of the message into the
Postfix "incoming" queue.
In the absence of excessive CPU consumption in cleanup(8) header or body regular expression
checks or other software consuming all available CPU resources, Postfix performance is disk I/
O bound. The rate at which the pickup(8) service can inject messages into the queue is largely
determined by disk access times, since the cleanup(8) service must commit the message to
stable storage before returning success. The same is true of the postdrop(1) program writing the

message to the "maildrop" directory.
As the pickup service is single threaded, it can only deliver one message at a time at a rate that
does not exceed the reciprocal disk I/O latency (+ CPU if not negligible) of the cleanup service.
Congestion in this queue is indicative of an excessive local message submission rate or perhaps
excessive CPU consumption in the cleanup(8) service due to excessive body_checks.
Note, that once the active queue is full, the cleanup service will attempt to slow down message
injection by pausing $in_flow_delay for each message. In this case "maildrop" queue
congestion may be a consequence of congestion downstream, rather than a problem in its own
right.
Note also, that one should not attempt to deliver large volumes of mail via the pickup(8)
service. High volume sites must avoid using content filters that reinject scanned mail via
Postfix sendmail(1) and postdrop(1).
A high arrival rate of locally submitted mail may be an indication of an uncaught forwarding
loop, or a run-away notification program. Try to keep the volume of local mail injection to a
moderate level.
The "postsuper -r" command can place selected messages into the "maildrop" queue for
reprocessing. This is most useful for resetting any stale content_filter settings. Requeuing a
large number of messages using "postsuper -r" can clearly cause a spike in the size of the
"maildrop" queue.
The "hold" queue
The administrator can define "smtpd" access(5) policies, or cleanup(8) header/body checks that
cause messages to be automatically diverted from normal processing and placed indefinitely in
the "hold" queue. Messages placed in the "hold" queue stay there until the administrator
intervenes. No periodic delivery attempts are made for messages in the "hold" queue. The
postsuper(1) command can be used to manually release messages into the "deferred" queue.
Messages can potentially stay in the "hold" queue for a time exceeding the normal maximal
queue lifetime (after which undelivered messages are bounced back to the sender). If such
"old" messages need to be released from the "hold" queue, they should typically be moved into
the "maildrop" queue, so that the message gets a new timestamp and is given more than one
opportunity to be delivered. Messages that are "young" can be moved directly into the

"deferred" queue.
The "hold" queue plays little role in Postfix performance, and monitoring of the "hold" queue is
typically more closely motivated by tracking spam and malware, than by performance issues.
The "incoming" queue
All new mail entering the Postfix queue is written by the cleanup(8) service into the
"incoming" queue. New queue files are created owned by the "postfix" user with an access
bitmask (or mode) of 0600. Once a queue file is ready for further processing the cleanup(8)
service changes the queue file mode to 0700 and notifies the queue manager of new mail
arrival. The queue manager ignores incomplete queue files whose mode is 0600, as these are
still being written by cleanup.
The queue manager scans the incoming queue bringing any new mail into the "active" queue if
the active queue resource limits have not been exceeded. By default, the active queue
accommodates at most 20000 messages. Once the active queue message limit is reached, the
queue manager stops scanning the incoming (and deferred, see below) queue.
Under normal conditions the incoming queue is nearly empty (has only mode 0600 files), with
the queue manager able to import new messages into the active queue as soon as they become
available.
The incoming queue grows when the message input rate spikes above the rate at which the
queue manager can import messages into the active queue. The main factor slowing down the
queue manager is transport queries to the trivial-rewrite service. If the queue manager is
routinely not keeping up, consider not using "slow" lookup services (MySQL, LDAP, ...) for
transport lookups or speeding up the hosts that provide the lookup service.
The in_flow_delay parameter is used to clamp the input rate when the queue manager starts to
fall behind. The cleanup(8) service will pause for $in_flow_delay seconds before creating a
new queue file if it cannot obtain a "token" from the queue manager.
Since the number of cleanup(8) processes is limited in most cases by the SMTP server
concurrency, the input rate can exceed the output rate by at most "SMTP connection count" /
$in_flow_delay messages per second.
With a default process limit of 100, and an in_flow_delay of 1s, the coupling is strong enough
to limit a single run-away injector to 1 message per second, but is not strong enough to deflect

an excessive input rate from many sources at the same time.
If a server is being hammered from multiple directions, consider raising the in_flow_delay to
10 seconds, but only if the incoming queue is growing even while the active queue is not full
and the trivial-rewrite service is using a fast transport lookup mechanism.
The "active" queue
The queue manager is a delivery agent scheduler; it works to ensure fast and fair delivery of
mail to all destinations within designated resource limits.
The active queue is somewhat analogous to an operating system's process run queue. Messages
in the active queue are ready to be sent (runnable), but are not necessarily in the process of
being sent (running).
While most Postfix administrators think of the "active" queue as a directory on disk, the real
"active" queue is a set of data structures in the memory of the queue manager process.
Messages in the "maildrop", "hold", "incoming" and "deferred" queues (see below) do not
occupy memory; they are safely stored on disk waiting for their turn to be processed. The
envelope information for messages in the "active" queue is managed in memory, allowing the
queue manager to do global scheduling, allocating available delivery agent processes to an
appropriate message in the active queue.
Within the active queue, (multi-recipient) messages are broken up into groups of recipients that
share the same transport/nexthop combination; the group size is capped by the transport's
recipient concurrency limit.
Multiple recipient groups (from one or more messages) are queued for delivery via the
common transport/nexthop combination. The destination concurrency limit for the transports
caps the number of simultaneous delivery attempts for each nexthop. Transports with a
recipient concurrency limit of 1 are special: these are grouped by the actual recipient address
rather than the nexthop, thereby enabling per-recipient concurrency limits rather than per-
domain concurrency limits. Per-recipient limits are appropriate when performing final delivery
to mailboxes rather than when relaying to a remote server.
Congestion occurs in the active queue when one or more destinations drain slower than the
corresponding message input rate. If a destination is down for some time, the queue manager
will mark it dead, and immediately defer all mail for the destination without trying to assign it
to a delivery agent. In this case the messages will quickly leave the active queue and end up in

the deferred queue. If the destination is instead simply slow, or there is a problem causing an
excessive arrival rate the active queue will grow and will become dominated by mail to the
congested destination.
The only way to reduce congestion is to either reduce the input rate or increase the throughput.
Increasing the throughput requires either increasing the concurrency or reducing the latency of
deliveries.
For high volume sites a key tuning parameter is the number of "smtp" delivery agents allocated
to the "smtp" and "relay" transports. High volume sites tend to send to many different
destinations, many of which may be down or slow, so a good fraction of the available delivery
agents will be blocked waiting for slow sites. Also mail destined across the globe will incur
large SMTP command-response latencies, so high message throughput can only be achieved
with more concurrent delivery agents.
The default "smtp" process limit of 100 is good enough for most sites, and may even need to be
lowered for sites with low bandwidth connections (no use increasing concurrency once the
network pipe is full). When one finds that the queue is growing on an "idle" system (CPU, disk
I/O and network not exhausted) the remaining reason for congestion is insufficient concurrency
in the face of a high average latency. If the number of outbound SMTP connections (either
ESTABLISHED or SYN_SENT) reaches the process limit, mail is draining slowly and the
system and network are not loaded, raise the "smtp" and/or "relay" process limits!
Especially for the "relay" transport, consider lower SMTP connection timeouts (1-5 seconds)
and higher than default destination concurrency limits. Compute the expected latency when 1
out of N of the MX hosts for a high volume site is down and not responding, and make sure
that the configured concurrency divided by this latency exceeds the required steady-state
message rate. If the destination is managed by you, consider load balancers in front of groups
of MX hosts. Load balancers have higher uptime and will be able to hide individual MX host
failures.
If necessary, dedicate and tune custom transports for high volume destinations.
Another common cause of congestion is unwarranted flushing of the entire deferred queue. The
deferred queue holds messages that are likely to fail to be delivered and are also likely to be
slow to fail delivery (timeouts). This means that the most common reaction to a large deferred
queue (flush it!) is more than likely counter- productive, and is likely to make the problem
worse. Do not flush the deferred queue unless you expect that most of its content has recently
become deliverable (e.g. relayhost back up after an outage)!
Note that whenever the queue manager is restarted, there may already be messages in the active

queue directory, but the "real" active queue in memory is empty. In order to recover the in-
memory state, the queue manager moves all the active queue messages back into the incoming
queue, and then uses its normal incoming queue scan to refill the active queue. The process of
moving all the messages back and forth, redoing transport table (trivial-rewrite(8) resolve
service) lookups, and re-importing the messages back into memory is expensive. At all costs,
avoid frequent restarts of the queue manager.
The "deferred" queue
When all the deliverable recipients for a message are delivered, and for some recipients
delivery failed for a transient reason (it might succeed later), the message is placed in the
deferred queue.
The queue manager scans the deferred queue periodically. The scan interval is controlled by
the queue_run_delay parameter. While a deferred queue scan is in progress, if an incoming
queue scan is also in progress (ideally these are brief since the incoming queue should be
short), the queue manager alternates between bringing a new "incoming" message and a new
"deferred" message into the queue. This "round-robin" strategy prevents starvation of either the
incoming or the deferred queues.
Each deferred queue scan only brings a fraction of the deferred queue back into the active
queue for a retry. This is because each message in the deferred queue is assigned a "cool-off"
time when it is deferred. This is done by time-warping the modification times of the queue file
into the future. The queue file is not eligible for a retry if its modification time is not yet
reached.
The "cool-off" time is at least $minimal_backoff_time and at most $maximal_backoff_time.

The next retry time is set by doubling the message's age in the queue, and adjusting up or down
to lie within the limits. This means that young messages are initially retried more often than old
messages.
If a high volume site routinely has large deferred queues, it may be useful to adjust the
queue_run_delay, minimal_backoff_time and maximal_backoff_time to provide short enough
delays on first failure, with perhaps longer delays after multiple failures, to reduce the
retransmission rate of old messages and thereby reduce the quantity of previously deferred mail
in the active queue.
One common cause of large deferred queues is failure to validate recipients at the SMTP input
stage. Since spammers routinely launch dictionary attacks from unrepliable sender addresses,

the bounces for invalid recipient addresses clog the deferred queue (and at high volumes
proportionally clog the active queue). Recipient validation is strongly recommended through
use of the local_recipient_maps and relay_recipient_maps parameters.
When a host with lots of deferred mail is down for some time, it is possible for the entire
deferred queue to reach its retry time simultaneously. This can lead to a very full active queue
once the host comes back up. The phenomenon can repeat approximately every
maximal_backoff_time seconds if the messages are again deferred after a brief burst of
congestion. Ideally, in the future Postfix will add a random offset to the retry time (or use a
combination of strategies) to reduce the chances of repeated complete deferred queue flushes.
Credits
The qshape(1) program was developed by Victor Duchovni of Morgan Stanley, who also wrote
the initial version of this document.

Postfix manual - qshape(1)
QSHAPE(1) QSHAPE
(1)
NAME
qshape - Print Postfix queue domain and age distribution
SYNOPSIS
qshape [-s] [-p] [-m min_subdomains]
[-b bucket_count] [-t bucket_time]
[-l] [-w terminal_width]
[-c config_directory] [queue_name ...]
DESCRIPTION
The qshape program helps the administrator understand
the
Postfix queue message distribution in time and by
sender
domain or recipient domain. The program needs read
access
to the queue directories and queue files, so it must
run
as the superuser or the mail_owner specified in main.
cf
(typically postfix).
Options:
-s Display the sender domain distribution instead

of
the recipient domain distribution. By default
the
recipient distribution is displayed. There can
be
more recipients than messages, but as each
message
has only one sender, the sender distribution is
a
message distribution.
-p Generate aggregate statistics for parent

domains.
http://www.subneural.net/postfix-master/qshape.1.html (1 of 5)01/16/2005 15:46:13

Top level domains are not shown, nor are

domains
with fewer than min_subdomains subdomains.
The
names of parent domains are shown with a
leading
dot, (e.g. .example.com).
-m min_subdomains
When used with the -p option, sets the minimum
sub-
domain count needed to show a separate line for
a
parent domain. The default is 5.
-b bucket_count
The age distribution is broken up into a
sequence
of geometrically increasing intervals. This
option
sets the number of intervals or "buckets".
Each
bucket has a maximum queue age that is twice
as
large as that of the previous bucket. The
last
bucket has no age limit.
-t bucket_time
The age limit in minutes for the first time
bucket.
The default value is 5, meaning that the
first
bucket counts messages between 0 and 5 minutes
old.
-l Instead of using a geometric age sequence, use

a
linear age sequence, in other words simple
multi-
ples of bucket_time.

later.
-w terminal_width
The output is right justified, with the counts
for
the last bucket shown on the 80th column, the
ter-
minal_width can be adjusted for wider
screens
allowing more buckets to be displayed without
trun-
cating the domain names on the left. When a row
for
a full domain name and its counters does not fit
in
the specified number of columns, only the last
17
bytes of the domain name are shown with the
prefix
replaced by a '+' character. Truncated
parent
domain rows are shown as '.+' followed by the
last
16 bytes of the domain name. If this is still
too
narrow to show the domain name and all the
coun-
ters, the terminal_width limit is violated.
-c config_directory
named
configuration
directory.
Arguments:
queue_name
By default qshape displays the combined
distribu-
tion of the incoming and active queues. To

display
a different set of queues, just list their
direc-
tory names on the command line. Absolute paths
are
used as is, other paths are taken relative to
the
main.cf queue_directory parameter setting.
While
main.cf supports the use of $variable expansion
in
the definition of the queue_directory
parameter,
the qshape program does not. If you must use
vari-
able expansions in the queue_directory setting,
you
must specify an explicit absolute path for
each
queue subdirectory even if you want the
default
incoming and active queue distribution.
SEE ALSO
mailq(1) List all messages in the queue.
QSHAPE_README Examples and background material.
FILES
$config_directory/main.cf, Postfix installation
parameters.
$queue_directory/maildrop/, local submission directory.
$queue_directory/incoming/, new message queue.
$queue_directory/hold/, messages waiting for tech
support.
$queue_directory/active/, messages scheduled for
delivery.
$queue_directory/deferred/, messages postponed for later
delivery.
LICENSE

this
software.
AUTHOR(S)
Victor Duchovni
Morgan Stanley
QSHAPE
(1)

Postfix manual - postqueue(1)
POSTQUEUE(1) POSTQUEUE
(1)
NAME
postqueue - Postfix queue control
SYNOPSIS
postqueue [-c config_dir] -f
postqueue [-c config_dir] -p
postqueue [-c config_dir] -s site
DESCRIPTION
The postqueue program implements the Postfix user
inter-
face for queue management. It implements operations
that
are traditionally available via the sendmail(1)
command.
See the postsuper(1) command for queue operations
that
require super-user privileges such as deleting a
message
from the queue or changing the status of a message.
The following options are recognized:
-c config_dir
named
configuration
environment
setting below.
-f Flush the queue: attempt to deliver all

queued
mail.
This option implements the traditional sendmail -

q
http://www.subneural.net/postfix-master/postqueue.1.html (1 of 6)01/16/2005 15:46:14

command, by contacting the Postfix qmgr(8)

daemon.

frequently
all
other mail.
-p Produce a traditional sendmail-style queue

listing.
This option implements the traditional mailq
com-
mand, by contacting the Postfix showq(8) daemon.
Each queue entry shows the queue file ID,

message
size, arrival time, sender, and the recipients
that
still need to be delivered. If mail could not
be
delivered upon the last attempt, the reason
for
failure is shown. This mode of operation is
imple-
mented by executing the postqueue(1) command.
The
queue ID string is followed by an optional
status
character:
* The message is in the active queue, i.e.

the
message is selected for delivery.
! The message is in the hold queue, i.e.

no
further delivery attempt will be made
until
the mail is taken off hold.
-s site

Schedule immediate delivery of all mail that

is
queued for the named site. The site must be
eligi-
ble for the "fast flush" service. See flush(8)
for
more information about the "fast flush" service.
This option implements the traditional

sendmail
-qRsite command, by contacting the Postfix flush
(8)
daemon.

Mul-
increasingly
verbose.
SECURITY
This program is designed to run with set-group ID
privi-
leges, so that it can connect to Postfix daemon
processes.
DIAGNOSTICS
standard
error stream.
ENVIRONMENT
MAIL_CONFIG
Directory with the main.cf file. In order to
avoid
exploitation of set-group ID privileges, a
non-
standard directory is allowed only if:
o The name is listed in the standard main.

cf
file with the

alternate_config_directories
o The command is invoked by the super-user.
relevant
parameter
exam-
ples.
alternate_config_directories (empty)
A list of non-default Postfix configuration
direc-
tories that may be specified with "-c
config_direc-
tory" on the command line, or via the
MAIL_CONFIG
environment parameter.

and

com-
mands.
for
queued


Postfix
pro-
cess.

direc-
tory.
pro-
"smtpd"
Postfix
dae-
mon).
authorized_flush_users (static:anyone)
List of users who are authorized to flush
the
queue.
authorized_mailq_users (static:anyone)
List of users who are authorized to view the
queue.
FILES
/var/spool/postfix, mail queue

SEE ALSO
showq(8), list mail queue
flush(8), fast flush service
sendmail(1), Sendmail-compatible user interface
postsuper(1), privileged queue operations
README FILES
LICENSE
this
software.
HISTORY
The postqueue command was introduced with Postfix
version
1.1.
AUTHOR(S)
Wietse Venema
P.O. Box 704
POSTQUEUE
(1)

Postfix manual - postsuper(1)
POSTSUPER(1) POSTSUPER
(1)
NAME
postsuper - Postfix superintendent
SYNOPSIS
postsuper [-psv] [-c config_dir] [-d queue_id]
[-h queue_id] [-H queue_id]
[-r queue_id] [directory ...]
DESCRIPTION
The postsuper command does maintenance jobs on the
Postfix
queue. Use of the command is restricted to the
superuser.
See the postqueue command for unprivileged queue
opera-
tions such as listing or flushing the mail queue.
By default, postsuper performs the operations

requested
with the -s and -p command-line options on all
Postfix
queue directories - this includes the incoming, active
and
deferred directories with mail files and the
bounce,
defer, trace and flush directories with log files.
Options:
-c config_dir
named
configuration
environment
setting below.
http://www.subneural.net/postfix-master/postsuper.1.html (1 of 8)01/16/2005 15:46:15

-d queue_id
Delete one message with the named queue ID from
the
named mail queue(s) (default: hold,
incoming,
active and deferred). If a queue_id of - is
speci-
fied, the program reads queue IDs from
standard
input. For example, to delete all mail from or
to
user@example.com:
mailq | tail +2 | awk 'BEGIN { RS = "" } \

/ user@example\.com$/ { print $1 } \
' | tr -d '*!' | postsuper -d -
Specify -d ALL to remove all messages; for

example,
specify -d ALL deferred to delete mail in
the
deferred queue. As a safety measure, the word
ALL
must be specified in upper case.
Warning: Postfix queue IDs are reused. There is

a
very small possibility that postsuper deletes
the
wrong message file when it is executed while
the
Postfix mail system is delivering mail.
The scenario is as follows:
1) The Postfix queue manager deletes the

mes-
sage that postsuper is asked to
delete,
because Postfix is finished with the
message
(it is delivered, or it is returned to
the

sender).
2) New mail arrives, and the new message

is
given the same queue ID as the message
that
postsuper is supposed to delete. The
proba-
bility for reusing a deleted queue ID
is
about 1 in 2**15 (the number of
different
microsecond values that the system clock
can
distinguish within a second).
3) postsuper deletes the new message,

instead
of the old message that it should
have
deleted.
-h queue_id
Put mail "on hold" so that no attempt is made
to
deliver it. Move one message with the named
queue
ID from the named mail queue(s) (default:
incoming,
active and deferred) to the hold queue. If
a
queue_id of - is specified, the program reads
queue
IDs from standard input.
Specify -h ALL to hold all messages; for

example,
specify -h ALL deferred to hold mail in
the
deferred queue. As a safety measure, the word
ALL
must be specified in upper case.

Note: while mail is "on hold" it will not

expire
when its time in the queue exceeds the
maxi-
mal_queue_lifetime or bounce_queue_lifetime
set-
ting. It becomes subject to expiration after it
is
released from "hold".
-H queue_id
Release mail that was put "on hold". Move one
mes-
sage with the named queue ID from the named
mail
queue(s) (default: hold) to the deferred queue.
If
a queue_id of - is specified, the program
reads
queue IDs from standard input.

was
$maxi-
or
longer.
Specify -H ALL to release all mail that is

"on
hold". As a safety measure, the word ALL must
be
specified in upper case.
-p Purge old temporary files that are left over

after
system or software crashes.
-r queue_id
Requeue the message with the named queue ID

from
the named mail queue(s) (default: hold,
incoming,
active and deferred). To requeue multiple
mes-
sages, specify multiple -r command-line
options.
Alternatively, if a queue_id of - is specified,
the
program reads queue IDs from standard input.
Specify -r ALL to requeue all messages. As a

safety
measure, the word ALL must be specified in
upper
case.
A requeued message is moved to the maildrop

queue,
from where it is copied by the pickup daemon to
a
new file whose name is guaranteed to match the
new
queue file inode number. The new queue file is
sub-
jected again to mail address rewriting and
substi-
tution. This is useful when rewriting rules or
vir-
tual mappings have changed.
Warning: Postfix queue IDs are reused. There is

a
very small possibility that postsuper requeues
the
wrong message file when it is executed while
the
Postfix mail system is running, but no harm
should
be done.
-s Structure check and structure repair. This

should

be done once before Postfix startup.
o Rename files whose name does not match

the
message file inode number. This operation
is
necessary after restoring a mail queue
from
a different machine, or from backup media.
o Move queue files that are in the wrong

place
in the file system hierarchy and remove
sub-
directories that are no longer needed.
File
position rearrangements are necessary
after
a change in the hash_queue_names and/
or
hash_queue_depth configuration parameters.

Mul-
increasingly
verbose.
DIAGNOSTICS
Problems are reported to the standard error stream and
to
syslogd(8).
postsuper reports the number of messages deleted with -

d,
the number of messages requeued with -r, and the number
of
messages whose queue file name was fixed with -s.
The
report is written to the standard error stream and to
sys-
logd(8).

ENVIRONMENT
MAIL_CONFIG
Directory with the main.cf file.
BUGS
Mail that is not sanitized by Postfix (i.e. mail in
the
maildrop queue) cannot be placed "on hold".
relevant
parameter
exam-
ples.

and
hash_queue_depth (1)
The number of subdirectory levels for queue
direc-
tories listed with the hash_queue_names
parameter.
hash_queue_names (see 'postconf -d' output)

The names of queue directories that are
split
across multiple subdirectory levels.

direc-
tory.

pro-
"smtpd"
SEE ALSO
sendmail(1), Sendmail-compatible user interface
postqueue(1), unprivileged queue operations
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
POSTSUPER
(1)

Postfix manual - showq(8)
SHOWQ(8) SHOWQ
(8)
NAME
showq - list the Postfix mail queue
SYNOPSIS
showq [generic Postfix daemon options]
DESCRIPTION
The showq daemon reports the Postfix mail queue
status.
It is the program that emulates the sendmail `mailq'
com-
mand.
The showq daemon can also be run in stand-alone mode

by
the superuser. This mode of operation is used to
emulate
the `mailq' command while the Postfix mail system is
down.
SECURITY
The showq daemon can run in a chroot jail at fixed
low
privilege, and takes no input from the client. Its
service
port is accessible to local untrusted users, so the
ser-
vice can be susceptible to denial of service attacks.
STANDARDS
None. The showq daemon does not interact with the
outside
world.
DIAGNOSTICS
BUGS
http://www.subneural.net/postfix-master/showq.8.html (1 of 4)01/16/2005 15:46:16

The showq daemon runs at a fixed low privilege;

conse-
quently, it cannot extract information from queue files
in
the maildrop directory.
Changes to main.cf are picked up automatically as showq
(8)
processes run for only a limited amount of time. Use
the

See

and
to
a
the
vir-
dis-
plays.
null

address.
ipc_timeout (3600s)
information
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a
pro-
cess.
daemon
process.

direc-
tory.
pro-
"smtpd"

FILES
/var/spool/postfix, queue directories
SEE ALSO
pickup(8), local mail pickup service
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
SHOWQ
(8)

Postfix manual - aliases(5)
ALIASES(5) ALIASES
(5)
NAME
aliases - format of the Postfix alias database
SYNOPSIS
newaliases
DESCRIPTION
The aliases table provides a system-wide mechanism
to
redirect mail for local recipients. The redirections
are
processed by the Postfix local(8) delivery agent.
Normally, the aliases table is specified as a text

file
that serves as input to the postalias(1) command.
The
for
fast lookup by the mail system. Execute the
command
newaliases in order to rebuild the indexed file
after
changing the Postfix alias database.
The input and output file formats are expected to be

com-
patible with Sendmail version 8, and are expected to
be
suitable for the use as NIS maps.
Users can control delivery of their own mail by setting

up
.forward files in their home directory. Lines in per-
user
.forward files have the same syntax as the right-hand
side
of aliases entries.
http://www.subneural.net/postfix-master/aliases.5.html (1 of 6)01/16/2005 15:46:16

The format of the alias database input file is as

follows:
o An alias definition has the form
name: value1, value2, ...

ignored,
character
is a `#'.

A
logi-
cal line.
The name is a local address (no domain part). Use

double
quotes when the name contains any special characters
such
as whitespace, `#', `:', or `@'. The name is folded
to
lowercase, in order to make database lookups case
insensi-
tive.
In addition, when an alias exists for owner-name,

delivery
diagnostics are directed to that address, instead of
to
the originator. This is typically used to direct
delivery
errors to the owner of a mailing list, who is in a
better
position to deal with mailing list delivery problems
than
the originator of the undelivered mail.
The value contains one or more of the following:

address
Mail is forwarded to address, which is
compatible
with the RFC 822 standard.
/file/name
Mail is appended to /file/name. See local(8)
for
details of delivery to file. Delivery is not
lim-
ited to regular files. For example, to dispose
of
unwanted mail, deflect it to /dev/null.
|command
Mail is piped into command. Commands that
contain
special characters, such as whitespace, should
be
enclosed between double quotes. See local(8)
for
details of delivery to command.
When the command fails, a limited amount of

command
output is mailed back to the sender. The
file
/usr/include/sysexits.h defines the expected
exit
status codes. For example, use |"exit 67" to
simu-
late a "user unknown" error, and |"exit 0"
to
implement an expensive black hole.
:include:/file/name
Mail is sent to the destinations listed in
the
named file. Lines in :include: files have the
same
syntax as the right-hand side of alias entries.

A destination can be any destination that

is
described in this manual page. However, delivery
to
"|command" and /file/name is disallowed by
default.
To enable, edit the allow_mail_to_commands
and
allow_mail_to_files configuration parameters.
ADDRESS EXTENSION
When alias database search fails, and the recipient
local-
part contains the optional recipient delimiter (e.
g.,
user+foo), the search is repeated for the
unextended
address (e.g., user).
relevant.
See
alias_database
List of alias databases that are updated by
the
newaliases(1) command.
alias_maps
List of alias databases queried by the local
(8)
delivery agent.
allow_mail_to_commands
Restrict the usage of mail delivery to
external
command.

allow_mail_to_files
Restrict the usage of mail delivery to
external
file.
expand_owner_alias
When delivering to an alias that has an owner-
com-
panion alias, set the envelope sender address
to
the right-hand side of the owner alias,
instead
using of the left-hand side address.
Give special treatment to owner-listname and
list-
name-request addresses.
recipient_delimiter
Delimiter that separates recipients from
address
extensions.
BUGS
Regular expression alias lookup tables are allowed,
but
substitution of $1 etc. is forbidden because that
would
open a security loophole.
STANDARDS
SEE ALSO
local(8), local delivery agent
newaliases(1), create/update alias database
postalias(1), create/update alias database

README FILES
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
ALIASES
(5)

Postfix manual - postalias(1)
POSTALIAS(1) POSTALIAS
(1)
NAME
postalias - Postfix alias database maintenance
SYNOPSIS
postalias [-Nfinoprsvw] [-c config_dir] [-d key] [-q key]
[file_type:]file_name ...
DESCRIPTION
The postalias command creates or queries one or more
Post-
fix alias databases, or updates an existing one. The
input
and output file formats are expected to be compatible
with
Sendmail version 8, and are expected to be suitable
for
the use as NIS alias maps.
If the result files do not exist they will be created

with
the same group and other read permissions as the
source
file.
While a database update is in progress, signal delivery

is
postponed, and an exclusive, advisory, lock is placed
on
the entire database, in order to avoid surprises in
spec-
tator programs.
The format of Postfix alias input files is described

in
aliases(5).
Options:
http://www.subneural.net/postfix-master/postalias.1.html (1 of 8)01/16/2005 15:46:17

-c config_dir
named
configuration
directory.
-d key Search the specified maps for key and remove

one
entry per map. The exit status is zero when
the
requested information was found.

reads
key values from the standard input stream. The
exit
status is zero when at least one of the
requested
keys was found.
-f Do not fold the lookup key to lower case while

cre-
ating or querying a map.
-i Incremental mode. Read entries from standard

input
and do not truncate an existing database.
By
default, postalias creates a new database from
the
entries in file_name.
-N Include the terminating null character that

termi-
nates lookup keys and values. By default,
Postfix
does whatever is the default for the host
operating
system.
-n Don't include the terminating null character

that

terminates lookup keys and values. By

default,
Postfix does whatever is the default for the
host
operating system.
-o Do not release root privileges when processing

a
non-root input file. By default, postalias
drops
root privileges and runs as the source file
owner
instead.
-p Do not inherit the file access permissions from

the
input file when creating a new file. Instead,
cre-
ate a new file with default access
permissions
(mode 0644).
-q key Search the specified maps for key and write

the
first value found to the standard output
stream.
The exit status is zero when the requested
informa-
tion was found.

reads
key values from the standard input stream
and
writes one line of key: value output for each
key
that was found. The exit status is zero when
at
least one of the requested keys was found.
-r When updating a table, do not complain

about

attempts to update existing entries, and make

those
updates anyway.
-s Retrieve all database elements, and write one

line
of key: value output for each element. The
elements
are printed in database order, which is not
neces-
sarily the same as the original input order.
This
feature is available in Postfix version 2.2
and
later, and is not available for all database
types.

Mul-
increasingly
verbose.
-w When updating a table, do not complain

about
attempts to update existing entries, and
ignore
those attempts.
Arguments:
file_type
The database type. To find out what types are
sup-
ported, use the "postconf -m" command.
The postalias command can query any supported

file
type, but it can create only the following
file
types:
btree The output is a btree file,

named
on
dbm The output consists of two files,

named
is
for
dbm databases.
hash The output is a hashed file,

named
on
sdbm The output consists of two files,

named
is
for
sdbm databases.
When no file_type is specified, the software

uses
the database type specified via
the
default_database_type configuration parameter.
The
default value for this parameter depends on
the
host environment.
file_name
The name of the alias database source file
when
creating a database.

DIAGNOSTICS
Problems are logged to the standard error stream and
to
syslogd(8). No output means that no problems
were
detected. Duplicate entries are skipped and are
flagged
with a warning.
postalias terminates with zero exit status in case of

suc-
cess (including successful postalias -q lookup) and
termi-
nates with non-zero exit status in case of failure.
ENVIRONMENT
MAIL_CONFIG
MAIL_VERBOSE
relevant
to this program.

See
alias_database (see 'postconf -d' output)

The alias databases for local(8) delivery that
are
updated with "newaliases" or with "sendmail -bi".

and
berkeley_db_create_buffer_size (16777216)


that
create Berkeley DB hash or btree tables.
berkeley_db_read_buffer_size (131072)
that
read Berkeley DB hash or btree tables.

(1),
pro-
"smtpd"
STANDARDS
SEE ALSO
aliases(5), format of alias database input file.
local(8), Postfix local delivery agent.
postconf(1), supported database types
postmap(1), create/update/query lookup tables
newaliases(1), Sendmail compatibility interface.
README FILES
LICENSE

this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
POSTALIAS
(1)

Postfix manual - postconf(1)
POSTCONF(1) POSTCONF
(1)
NAME
postconf - Postfix configuration utility
SYNOPSIS
postconf [-dhmlnv] [-c config_dir] [parameter ...]
postconf [-ev] [-c config_dir] [parameter=value ...]
DESCRIPTION
The postconf command prints the actual value of
parameter
(all known parameters by default) one parameter per
line,
changes its value, or prints other information about
the
Postfix mail system.
Options:
-c config_dir
named
configuration
directory.
-d Print default parameter settings instead of

actual
settings.
-e Edit the main.cf configuration file. The file

is
copied to a temporary file then renamed into
place.
Parameters and values are specified on the
command
line. Use quotes in order to protect
shell

metacharacters and whitespace.
-h Show parameter values only, not the ``name =

''
label that normally precedes the value.
-l List the names of all supported mailbox

locking
methods. Postfix supports the following methods:
flock A kernel-based advisory locking method

for
local files only. This locking method
is
available only on systems with a BSD
compat-
ible library.
fcntl A kernel-based advisory locking method

for
local and remote files.
dotlock
An application-level locking method.
An
application locks a file named filename
by
creating a file named filename.lock.
The
application is expected to remove its
own
lock file, as well as stale lock files
that
were left behind after abnormal
termination.
-m List the names of all supported lookup table

types.
Postfix lookup tables are specified as type:
name,
where type is one of the types listed below.
The
table name syntax depends on the lookup table

type.
btree A sorted, balanced tree structure. This

is
for
Berkeley DB databases.
cidr A table that associates values with

Class-
less Inter-Domain Routing (CIDR)
patterns.
This is described in cidr_table(5).
dbm An indexed file type based on hashing.

This
is available only on systems with
support
for DBM databases.
environ
The UNIX process environment array.
The
lookup key is the variable name.
Originally
implemented for testing, someone may
find
this useful someday.
hash An indexed file type based on hashing.

This
support
for Berkeley DB databases.
ldap (read-only)
Perform lookups using the LDAP
protocol.
This is described in ldap_table(5).
mysql (read-only)
Perform lookups using the MYSQL

protocol.
This is described in mysql_table(5).
pcre (read-only)
A lookup table based on Perl Compatible
Reg-
ular Expressions. The file format
is
described in pcre_table(5).
pgsql (read-only)
Perform lookups using the PostgreSQL
proto-
col. This is described in pgsql_table(5).
proxy (read-only)
A lookup table that is implemented via
the
Postfix proxymap(8) service. The table
name
syntax is type:name.
regexp (read-only)
A lookup table based on regular
expressions.
The file format is described in
reg-
exp_table(5).
sdbm An indexed file type based on hashing.

This
support
for SDBM databases.
static (read-only)
A table that always returns its name
as
lookup result. For example, static:
foobar
always returns the string foobar as
lookup

result.
tcp (read-only)
Perform lookups using a simple request-
reply
protocol that is described in tcp_table
(5).
This feature is not included with
Postfix
2.1.
unix (read-only)
A limited way to query the UNIX
authentica-
tion database. The following tables
are
implemented:
unix:passwd.byname
The table is the UNIX
password
database. The key is a login
name.
The result is a password file
entry
in passwd(5) format.
unix:group.byname
The table is the UNIX
group
database. The key is a group
name.
The result is a group file entry
in
group(5) format.
Other table types may exist depending on how Postfix

was
built.
-n Print parameter settings that are not left at

their

built-in default value, because they are

explicitly
specified in main.cf.

Mul-
increasingly
verbose.
DIAGNOSTICS
Problems are reported to the standard error stream.
ENVIRONMENT
MAIL_CONFIG
relevant
to this program.

See

and
FILES
/etc/postfix/main.cf, Postfix configuration parameters
SEE ALSO
README FILES
LICENSE

this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
POSTCONF
(1)

Postfix manual - cidr_table(5)
CIDR_TABLE(5) CIDR_TABLE
(5)
NAME
cidr_table - format of Postfix CIDR tables
SYNOPSIS
postmap -q "string" cidr:/etc/postfix/filename
postmap -q - cidr:/etc/postfix/filename <inputfile
DESCRIPTION
The Postfix mail system uses optional lookup
tables.
These tables are usually in dbm or db format.
Alterna-
tively, lookup tables can be specified in CIDR
(Classless
Inter-Domain Routing) form.
To find out what types of lookup tables your Postfix

sys-
tem supports use the postconf -m command.
To test lookup tables, use the postmap command

as
described in the SYNOPSIS above.
TABLE FORMAT
The general form of a Postfix CIDR table is:
network_address/network_mask result
When a search string matches the specified
network
block, use the corresponding result value.
Specify
0.0.0.0/0 to match every address.
network_address result
When a search string matches the specified
network
http://www.subneural.net/postfix-master/cidr_table.5.html (1 of 3)01/16/2005 15:46:17

address, use the corresponding result value.

ignored,
character
is a `#'.
multi-line text
A
logi-
cal line.
SEARCH ORDER
the
search
string.
EXAMPLE SMTPD ACCESS MAP

smtpd_client_restrictions = ... cidr:/etc/postfix/
client.cidr ...
/etc/postfix/client.cidr:
# Rule order matters. Put more specific whitelist
entries
# before more general blacklist entries.
192.168.1.1 OK
192.168.0.0/16 REJECT
SEE ALSO
regexp_table(5) format of regular expression tables
pcre_table(5) format of PCRE tables
README FILES

AUTHOR(S)
The CIDR table lookup code was originally written by:
Jozsef Kadlecsik
kadlec@blackhole.kfki.hu
KFKI Research Institute for Particle and Nuclear Physics
POB. 49
1525 Budapest, Hungary
Adopted and adapted by:

Wietse Venema
P.O. Box 704
CIDR_TABLE
(5)

Postfix manual - regexp_table(5)
REGEXP_TABLE(5) REGEXP_TABLE
(5)
NAME
regexp_table - format of Postfix regular expression
tables
SYNOPSIS
postmap -fq "string" regexp:/etc/postfix/filename
postmap -fq - regexp:/etc/postfix/filename <inputfile
DESCRIPTION
The Postfix mail system uses optional tables for
address
rewriting or mail routing. These tables are usually in
dbm
or db format.
Alternatively, lookup tables can be specified in

POSIX
regular expression form. In this case, each input is
com-
pared against a list of patterns, and when a match
is
found the corresponding result is returned.

sys-
To test lookup tables, use the postmap -fq command

as
TABLE FORMAT
The general form of a Postfix regular expression table
is:
/pattern/flags result
When pattern matches the input string, use the
http://www.subneural.net/postfix-master/regexp_table.5.html (1 of 6)01/16/2005 15:46:18

cor-
responding result value.
!/pattern/flags result
When pattern does not match the input string,
use
the corresponding result value.
if /pattern/flags
endif Match the input string against the patterns

between
if and endif, if and only if that same input
string
also matches pattern. The if..endif can nest.
Note: do not prepend whitespace to patterns

inside
if..endif.
if !/pattern/flags

between
if and endif, if and only if that same input
string
does not match pattern. The if..endif can nest.

ignored,
character
is a `#'.
multi-line text
A
logi-
cal line.
Each pattern is a POSIX regular expression enclosed by

a
pair of delimiters. The regular expression syntax is
docu-
mented in re_format(7) with 4.4BSD, in regex(5)
with
Solaris, and in regex(7) with Linux. Other systems may
use
other document names.
The expression delimiter can be any character,

except
whitespace or characters that have special meaning
(tradi-
tionally the forward slash is used). The regular
expres-
sion can contain whitespace.
By default, matching is case-insensitive, and newlines

are
not treated as special characters. The behavior is
con-
trolled by flags, which are toggled by appending one
or
more of the following characters after the pattern:
i (default: on)
Toggles the case sensitivity flag. By
default,
matching is case insensitive.
x (default: on)
Toggles the extended expression syntax flag.
By
default, support for extended expression syntax
is
enabled.
m (default: off)
Toggle the multi-line mode flag. When this flag
is
on, the ^ and $ metacharacters match
immediately

after and immediately before a newline

character,
respectively, in addition to matching at the
start
and end of the input string.
TABLE SEARCH ORDER

the
input
string.
Each pattern is applied to the entire input

string.
entire
entire
network
search is done, and user@domain mail addresses are
not
broken up into their user and domain constituent
parts,
nor is user+foo broken up into user and foo.
TEXT SUBSTITUTION
Substitution of substrings from the matched
expression
into the result string is possible using $1, $2, etc..
The
macros in the result string may need to be written as
${n}
or $(n) if they aren't followed by whitespace.
Note: since negated patterns (those preceded by !)

return
a result when the expression does not match,
substitutions
are not available for negated patterns.

# Disallow sender-specified routing. This is a must if

you relay mail
# for other domains.
/[%!@].*[%!@]/ 550 Sender-specified routing
rejected
# Postmaster is OK, that way they can talk to us about

how to fix
# their problem.
/^postmaster@/ OK
# Protect your outgoing majordomo exploders

if !/ôwner-/
/^(.*)-outgoing@(.*)$/ 550 Use ${1}@${2} instead
endif
EXAMPLE HEADER FILTER MAP

# These were once common in junk mail.
/^Subject: make money fast/ REJECT
/^To: friend@public\.com/ REJECT
EXAMPLE BODY FILTER MAP

# First skip over base 64 encoded text to save CPU
cycles.
~^[[:alnum:]+/]{60,}$~ OK
# Put your own body patterns here.
SEE ALSO
pcre_table(5), format of PCRE tables
cidr_table(5), format of CIDR tables
README FILES
AUTHOR(S)
The regexp table lookup code was originally written by:
LaMont Jones
lamont@hp.com
That code was based on the PCRE dictionary contributed

by:
Andrew McNamara
North Sydney, NSW, Australia

Wietse Venema
P.O. Box 704
REGEXP_TABLE
(5)

Postfix manual - pcre_table(5)
PCRE_TABLE(5) PCRE_TABLE
(5)
NAME
pcre_table - format of Postfix PCRE tables
SYNOPSIS
postmap -fq "string" pcre:/etc/postfix/filename
postmap -fq - pcre:/etc/postfix/filename <inputfile
DESCRIPTION
address
dbm
or db format.
Alternatively, lookup tables can be specified in Perl

Com-
patible Regular Expression form. In this case, each
input
is compared against a list of patterns, and when a
match
is found the corresponding result is returned.

sys-
To test lookup tables, use the postmap -fq command

as
TABLE FORMAT
The general form of a PCRE table is:
/pattern/flags result
When pattern matches the input string, use the
cor-
responding result value.
http://www.subneural.net/postfix-master/pcre_table.5.html (1 of 7)01/16/2005 15:46:18

!/pattern/flags result
use
the corresponding result value.
if /pattern/flags

between
if and endif, if and only if the input string
also
matches pattern. The if..endif can nest.

inside
if..endif.
if !/pattern/flags

between
does
not match pattern. The if..endif can nest.

ignored,
character
is a `#'.
multi-line text
A
logi-
cal line.
Each pattern is a perl-like regular expression.

The
expression delimiter can be any character, except

whites-
pace or characters that have special meaning
(tradition-
ally the forward slash is used). The regular
expression
can contain whitespace.
By default, matching is case-insensitive, and newlines

are
not treated as special characters. The behavior is
con-
trolled by flags, which are toggled by appending one
or
more of the following characters after the pattern:
i (default: on)
Toggles the case sensitivity flag. By
default,
matching is case insensitive.
m (default: off)
Toggles the PCRE_MULTILINE flag. When this flag
is
on, the ^ and $ metacharacters match
immediately
after and immediately before a newline
character,
respectively, in addition to matching at the
start
and end of the subject string.
s (default: on)
Toggles the PCRE_DOTALL flag. When this flag is
on,
the . metacharacter matches the newline
character.
With Postfix versions prior to 2.0, The flag is
off
by default, which is inconvenient for multi-
line
message header matching.

x (default: off)
Toggles the pcre extended flag. When this flag
is
on, whitespace in the pattern (other than in
a
character class) and characters between a #
outside
a character class and the next newline
character
are ignored. An escaping backslash can be used
to
include a whitespace or # character as part of
the
pattern.
A (default: off)
Toggles the PCRE_ANCHORED flag. When this flag
is
on, the pattern is forced to be "anchored",
that
is, it is constrained to match only at the start
of
the string which is being searched (the
"subject
string"). This effect can also be achieved
by
appropriate constructs in the pattern itself.
E (default: off)
Toggles the PCRE_DOLLAR_ENDONLY flag. When
this
flag is on, a $ metacharacter in the
pattern
matches only at the end of the subject
string.
Without this flag, a dollar also matches
immedi-
ately before the final character if it is a
newline
character (but not before any other newline
charac-
ters). This flag is ignored if PCRE_MULTILINE
flag

is set.
U (default: off)
Toggles the ungreedy matching flag. When this
flag
is on, the pattern matching engine inverts
the
"greediness" of the quantifiers so that they
are
not greedy by default, but become greedy if
fol-
lowed by "?". This flag can also set by a (?
U)
modifier within the pattern.
X (default: off)
Toggles the PCRE_EXTRA flag. When this flag is
on,
any backslash in a pattern that is followed by
a
letter that has no special meaning causes an
error,
thus reserving these combinations for future
expan-
sion.
SEARCH ORDER
the
input
string.
Each pattern is applied to the entire input

string.
entire
entire
network
search is done, and user@domain mail addresses are

not
broken up into their user and domain constituent
parts,
nor is user+foo broken up into user and foo.
TEXT SUBSTITUTION
expression
into the result string is possible using the
conventional
perl syntax ($1, $2, etc.). The macros in the
result
string may need to be written as ${n} or $(n) if
they
aren't followed by whitespace.

return
substitutions

# Protect your outgoing majordomo exploders
/^(?!owner-)(.*)-outgoing@(.*)/ 550 Use ${1}@${2} instead
# Bounce friend@whatever, except when whatever is our

domain (you would
# be better just bouncing all friend@ mail - this is
just an example).
/^(friend@(?!my\.domain$).*)$/ 550 Stick this in your
pipe $1
# A multi-line entry. The text is sent as one line.

#
/^noddy@my\.domain$/
550 This user is a funny one. You really don't want to
send mail to
them as it only makes their head spin.
EXAMPLE HEADER FILTER MAP

/^Subject: make money fast/ REJECT
/^To: friend@public\.com/ REJECT

EXAMPLE BODY FILTER MAP

# First skip over base 64 encoded text to save CPU
cycles.
# Requires PCRE version 3.
~^[[:alnum:]+/]{60,}$~ OK
# Put your own body patterns here.
SEE ALSO
regexp_table(5), format of POSIX regular expression
tables
README FILES
AUTHOR(S)
The PCRE table lookup code was originally written by:
Andrew McNamara
North Sydney, NSW, Australia

Wietse Venema
P.O. Box 704
PCRE_TABLE
(5)

Postfix Lookup Table Overview
Postfix Lookup Table

Overview
Overview
● The Postfix lookup table model

● Postfix lists versus tables
● Preparing Postfix for LDAP or SQL lookups
● Maintaining Postfix lookup table files
● Updating Berkeley DB files safely
● Postfix lookup table types
The Postfix lookup table model

Postfix uses lookup tables to store and look up information for access control, address rewriting
and even for content filtering. All Postfix lookup tables are specified as "type:table", where
"type" is one of the database types described under "Postfix lookup table types" at the end of
this document, and where "table" is the lookup table name. The Postfix documentation uses the
terms "database" and "lookup table" for the same thing.
Examples of lookup tables that appear often in the Postfix documentation:
alias_maps = hash:/etc/postfix/aliases
(local aliasing)
header_checks = regexp:/etc/postfix/header_checks
(content filtering)
http://www.subneural.net/postfix-master/DATABASE_README.html (1 of 7)01/16/2005 15:46:19

(routing table)
(address rewriting)
All Postfix lookup tables store information as (key, value) pairs. This interface may seem
simplistic at first, but it turns out to be very powerful. The (key, value) query interface
completely hides the complexities of LDAP or SQL from Postfix. This is a good example of
connecting complex systems with simple interfaces.
Benefits of the Postfix (key, value) query interface:
● You can implement Postfix lookup tables first with local Berkeley DB files and then
switch to LDAP or MySQL without any impact on the Postfix configuration itself, as
described under "Preparing Postfix for LDAP or SQL lookups" below.
● You can use Berkeley DB files with fixed lookup strings for simple address rewriting
operations and you can use regular expression tables for the more complicated work.
Postfix lists versus tables

Most Postfix lookup tables are used to look up information. Examples are address rewriting
(the lookup string is the old address, and the result is the new address) or access control (the
lookup string is the client, sender or recipient, and the result is an action such as "reject").
With some tables, however, Postfix needs to know only if the lookup key exists. The lookup
result itself is not used. Examples are the local_recipient_maps that determine what local
recipients Postfix accepts in mail from the network, the mydestination parameter that specifies
what domains Postfix delivers locally, or the mynetworks parameter that specifies the IP
addresses of trusted clients or client networks. Technically, these are lists, not tables. Despite
the difference, Postfix lists are described here because they use the same underlying
infrastructure as Postfix lookup tables.
Preparing Postfix for LDAP or SQL lookups

LDAP and SQL are complex systems. Trying to set up both Postfix and LDAP or SQL at the
same time is definitely not a good idea. You can save yourself a lot of time by implementing
Postfix first with local files such as Berkeley DB. Local files have few surprises, and are easy
to debug with the postmap(1) command:
% postmap -q info@example.com hash:/etc/postfix/

virtual

Once you have local files working properly you can follow the instructions in ldap_table(5),
mysql_table(5) or pgsql_table(5) and replace local file lookups with LDAP or SQL lookups.
When you do this, you should use the postmap(1) command again, to verify that database
lookups still produce the exact same results as local file lookup:
% postmap -q info@example.com ldap:/etc/postfix/

virtual.cf
Be sure to exercise all the partial address or parent domain queries that are documented under
"table search order" in the relevant manual page: access(5), canonical(5), virtual(5), transport
(5), or under the relevant configuration parameter: mynetworks, relay_domains,
parent_domain_matches_subdomains.
Maintaining Postfix lookup table files

When you make changes to a database while the mail system is running, it would be desirable
if Postfix avoids reading information while that information is being changed. It would also be
nice if you can change a database without having to execute "postfix reload", in order to force
Postfix to use the new information. Each time you do "postfix reload" Postfix loses a lot of
performance.
● If you change a network database such as LDAP, NIS or SQL, there is no need to
execute "postfix reload". The LDAP, NIS or SQL server takes care of read/write access
conflicts and gives the new data to Postfix once that data is available.
● If you change a regexp: or pcre: file then Postfix may or may not pick up the file
changes immediately. This is because a Postfix process reads the entire file into memory
once and never examines the file again.
❍ If the file is used by a short-running process such as smtpd(8), cleanup(8) or local

(8), there is no need to execute "postfix reload" after making a change.
❍ If the file is being used by a long-running process such as trivial-rewrite(8) on a

busy server it may be necessary to execute "postfix reload".
● If you change a local file based database such as DBM or Berkeley DB, there is no need
to execute "postfix reload". Postfix uses file locking to avoid read/write access conflicts,
and whenever a Postfix daemon process notices that a file has changed it will terminate
before handling the next client request, so that a new process can initialize with the new

database.
Updating Berkeley DB files safely

Although Postfix uses file locking to avoid access conflicts while updating Berkeley DB or
other local database files, you still have a problem when the update fails because the disk is full
or because something else happens. This is because commands such as postmap(1) or postalias
(1) overwrite existing files. If the update fails in the middle then you have no usable database,
and Postfix will stop working. This is not an issue with the CDB database type available with
Postfix 2.2 and later, because CDB database rebuilds are atomic.
With multi-file databases such as DBM, there is no simple solution. With Berkeley DB and
other "one file" databases, it is possible to add some extra robustness by using "mv" to
REPLACE an existing database file instead of overwriting it:
# postmap access.in && mv access.in.db access.db
This converts the input file "access.in" into the output file "access.in.db", and replaces the file
"access.db" only when the postmap(1) command was successful. Of course typing such
commands becomes boring quickly, and this is why people use "make" instead, as shown
below. User input is shown in bold font.
# cat Makefile
all: aliases.db access.db virtual.db ...etcetera...
# Note 1: commands are specified after a TAB

character.
# Note 2: use postalias(1) for local aliases, postmap
(1) for the rest.
aliases.db: aliases.in
postalias aliases.in
mv aliases.in.db aliases.db
access.db: access.in
postmap access.in
mv access.in.db access.db
virtual.db: virtual.in
postmap virtual.in
mv virtual.in.db virtual.db

...etcetera...
# vi access.in
...editing session not shown...
# make
postmap access.in
mv access.in.db access.db
#
The "make" command updates only the files that have changed. In case of error, the "make"
command will stop and will not invoke the "mv" command, so that Postfix will keep using the
existing database file as if nothing happened.
Postfix lookup table types

To find out what database types your Postfix system supports, use the "postconf -m"
command. Here is a list of database types that are often supported:
btree
A sorted, balanced tree structure. This is available only on systems with
support for Berkeley DB databases. Database files are created with the
postmap(1) or postalias(1) command. The lookup table name as used in
"btree:table" is the database file name without the ".db" suffix.
cdb
A read-optimized structure with no support for incremental updates.
Database files are created with the postmap(1) or postalias(1) command.
The lookup table name as used in "cdb:table" is the database file name
without the ".cdb" suffix. This feature is available with Postfix 2.2 and
later.
cidr
A table that associates values with Classless Inter-Domain Routing
(CIDR) patterns. The table format is described in cidr_table(5).
dbm
An indexed file type based on hashing. This is available only on systems
with support for DBM databases. Database files are created with the
"dbm:table" is the database file name without the ".dir" or ".pag" suffix.
environ
The UNIX process environment array. The lookup key is the variable
name. The lookup table name in "environ:table" is ignored.
hash

with support for Berkeley DB databases. Database files are created with
the postmap(1) or postalias(1) command. The database name as used in
"hash:table" is the database file name without the ".db" suffix.
ldap (read-only)
Perform lookups using the LDAP protocol. Configuration details are
given in the ldap_table(5).
mysql (read-only)
Perform MySQL database lookups. Configuration details are given in
mysql_table(5).
netinfo (read-only)
Perform Netinfo database lookups.
nis (read-only)
Perform NIS database lookups.
nisplus (read-only)
Perform NIS+ database lookups. Configuration details are given in
nisplus_table(5).
pcre (read-only)
A lookup table based on Perl Compatible Regular Expressions. The file
format is described in pcre_table(5). The lookup table name as used in
"pcre:table" is the name of the regular expression file.
pgsql (read-only)
Perform PostgreSQL database lookups. Configuration details are given in
pgsql_table(5).
proxy (read-only)
Access information via the Postfix proxymap(8) service. The lookup table
name syntax is "proxy:type:table".
regexp (read-only)
A lookup table based on regular expressions. The file format is described
in regexp_table(5). The lookup table name as used in "regexp:table" is the
name of the regular expression file.
sdbm
with support for SDBM databases. Database files are created with the
"sdbm:table" is the database file name without the ".dir" or ".pag" suffix.
static (read-only)
Always returns its lookup table name as lookup result. For example, the
lookup table "static:foobar" always returns the string "foobar" as lookup
result.
tcp
Access information through a TCP/IP server. The protocol is described in

tcp_table(5). The lookup table name is "tcp:host:port" where "host"

specifies a symbolic hostname or a numeric IP address, and "port"
specifies a symbolic service name or a numeric port number. This
protocol is not available in Postfix version 2.1.
unix (read-only)
A limited way to query the UNIX authentication database. The following
tables are implemented:
unix:passwd.byname
The table is the UNIX password database. The key is a login
name. The result is a password file entry in passwd(5) format.
unix:group.byname
The table is the UNIX group database. The key is a group name.
The result is a group file entry in group(5) format.
Other lookup table types may be available depending on how Postfix was built. With some
Postfix distributions the list is dynamically extensible as support for lookup tables is
dynamically linked into Postfix.

Postfix manual - ldap_table(5)
LDAP_TABLE(5) LDAP_TABLE
(5)
NAME
ldap_table - Postfix LDAP client configuration
SYNOPSIS
postmap -q "string" ldap:/etc/postfix/filename
postmap -q - ldap:/etc/postfix/filename <inputfile
DESCRIPTION
address
dbm
or db format.
Alternatively, lookup tables can be specified as

LDAP
databases.
In order to use LDAP lookups, define an LDAP source as

a
lookup table in main.cf, for example:
alias_maps = ldap:/etc/postfix/ldap-aliases.cf
The file /etc/postfix/ldap-aliases.cf has the same

format
as the Postfix main.cf file, and can specify the
parame-
ters described below. An example is given at the end
of
this manual.
This configuration method is available with Postfix

ver-
sion 2.1 and later. See the section "BACKWARDS
COMPATI-
BILITY" below for older Postfix versions.
http://www.subneural.net/postfix-master/ldap_table.5.html (1 of 16)01/16/2005 15:46:20

For details about LDAP SSL and STARTTLS, see the

section
on SSL and STARTTLS below.
BACKWARDS COMPATIBILITY
For backwards compatibility with Postfix version 2.0
and
earlier, LDAP parameters can also be defined in main.
cf.
Specify as LDAP source a name that doesn't begin with
a
slash or a dot. The LDAP parameters will then be
accessi-
ble as the name you've given the source in its
definition,
an underscore, and the name of the parameter. For
exam-
ple, if the map is specified as "ldap:ldapsource",
the
"server_host" parameter below would be defined in main.
cf
as "ldapsource_server_host".
Note: with this form, the passwords for the LDAP

sources
are written in main.cf, which is normally world-
readable.
Support for this form will be removed in a future
Postfix
version.
LIST MEMBERSHIP
When using LDAP to store lists such as
$mynetworks,
$mydestination, $relay_domains,
$local_recipient_maps,
etc., it is important to understand that the table
must
store each list member as a separate key. The table
lookup
verifies the *existence* of the key. See "Postfix
lists

versus tables" in the DATABASE_README document for a

dis-
cussion.
Do NOT create tables that return the full list of

domains
in $mydestination or $relay_domains etc., or IP
addresses
in $mynetworks.
DO create tables with each matching item as a key and

with
an arbitrary value. With LDAP databases it is not
uncommon
to return the key itself.
For example, NEVER do this in a map defining

$mydestina-
tion:
query_filter = domain=*
result_attribute = domain
Do this instead:
query_filter = domain=%s
result_attribute = domain
GENERAL LDAP PARAMETERS

In the text below, default values are given in
parenthe-
ses. Note: don't use quotes in these variables; at
least,
not until the Postfix configuration routines
understand
how to deal with quoted strings.
server_host (default: localhost)

The name of the host running the LDAP server, e.
g.
server_host = ldap.example.com
Depending on the LDAP client library you're

using,

it should be possible to specify multiple

servers
here, with the library trying them in order
should
the first one fail. It should also be possible
to
give each server in the list a different
port
(overriding server_port below), by naming them
like
server_host = ldap.example.com:1444
With OpenLDAP, a (list of) LDAP URLs can be used

to
specify both the hostname(s) and the port(s):
server_host = ldap://ldap.example.com:1444
ldap://ldap2.example.com:1444
All LDAP URLs accepted by the OpenLDAP library

are
supported, including connections over UNIX
domain
sockets, and LDAP SSL (the last one provided
that
OpenLDAP was compiled with support for SSL):
server_host = ldapi://%2Fsome%2Fpath
ldaps://ldap.example.com:636
server_port (default: 389)

The port the LDAP server listens on, e.g.
server_port = 778
search_base (No default; you must configure this)

The RFC2253 base DN at which to conduct the
search,
e.g.
search_base = dc=your, dc=com
timeout (default: 10 seconds)

The number of seconds a search can take before
tim-
ing out, e.g.

timeout = 5
query_filter (default: mailacceptinggeneralid=%s)

The RFC2254 filter used to search the
directory,
where %s is a substitute for the address Postfix
is
trying to resolve, e.g.
query_filter = (&(mail=%s)(paid_up=true))
This parameter supports the following '%'

expan-
sions:
%s This is replaced by the input key. RFC

2254
quoting is used to make sure that the
input
key does not add unexpected
metacharacters.
%u When the input key is an address of the

form
user@domain, %u is replaced by the
(RFC
2254) quoted local part of the address.
Oth-
erwise, %u is replaced by the entire
search
string.
%d When the input key is an address of the

form
user@domain, %d is replaced by the
(RFC
2254) quoted domain part of the
address.
Otherwise, %d is replaced by the
entire
search string.
The "domain" parameter described below limits

the
input keys to addresses in matching domains.
When
the "domain" parameter is non-empty, LDAP
queries
for unqualified addresses or addresses in
non-
matching domains are suppressed and return
no
results.
NOTE: DO NOT put quotes around the query filter.
result_filter (default: %s)

Format template applied to result attributes.
Sup-
ports the same expansions as the query_filter,
and
can be easily used to append (or prepend)
text.
expan-
sions:
%s This is replaced by the value of the

result
attribute.
%u When the result attribute value is

an
address of the form user@domain, %u
is
replaced by the local part of the
address.
Otherwise, %u is replaced by the
entire
attribute value.
%d When a result attribute value is an

address
of the form user@domain, %d is replaced
by
the domain part of the attribute

value.
Otherwise, %d is replaced by the
entire
attribute value.
For example, using "result_filter = smtp:[%

s]"
allows one to use a mailHost attribute as the
basis
of a transport(5) table. After applying the
result
filter, multiple values are concatenated as
comma
separated strings. The expansion_limit
and
size_limit parameters explained below allow one
to
restrict the number of values in the result,
which
is especially useful for maps that should return
a
single value.
The default value %s specifies that each

attribute
value should be used as is.
NOTE: DO NOT put quotes around the result filter!
domain (default: no domain list)

This is a list of domain names, paths to files,
or
dictionaries. When specified, only fully
qualified
search keys with a *non-empty* localpart and
a
matching domain are eligible for lookup:
'user'
lookups, bare domain lookups and "@domain"
lookups
are not performed. This can significantly
reduce

the query load on the LDAP server.

domain = postfix.org, hash:/etc/postfix/
search-
domains
It is best not to use LDAP to store the

domains
eligible for LDAP lookups.
NOTE: DO NOT define this parameter for local

(8)
aliases.
result_attribute (default: maildrop)

The attribute(s) Postfix will read from any
direc-
tory entries returned by the lookup, to be
resolved
to an email address.
result_attribute = mailbox,maildrop
special_result_attribute (No default)

The attribute(s) of directory entries that can
con-
tain DNs or URLs. If found, a recursive
subsequent
search is done using their values.
special_result_attribute = member
DN recursion retrieves the same

result_attributes
as the main query, including the special
attributes
for further recursion. URI processing
retrieves
only those attributes that are included in the
URI
definition and are *also* listed
in
"result_attribute". If the URI lists any of
the
map's special result attributes, these are

also
retrieved and used recursively.
scope (default: sub)

The LDAP search scope: sub, base, or one.
These
translate into LDAP_SCOPE_SUBTREE,
LDAP_SCOPE_BASE,
and LDAP_SCOPE_ONELEVEL.
bind (default: yes)

Whether or not to bind to the LDAP server.
Newer
LDAP implementations don't require clients to
bind,
which saves time. Example:
bind = no
If you do need to bind, you might consider

config-
uring Postfix to connect to the local machine on
a
port that's an SSL tunnel to your LDAP server.
If
your LDAP server doesn't natively support SSL,
put
a tunnel (wrapper, proxy, whatever you want to
call
it) on that system too. This should prevent
the
password from traversing the network in the
clear.
bind_dn (default: empty)

If you do have to bind, do it with this
distin-
guished name. Example:
bind_dn = uid=postfix, dc=your, dc=com
bind_pw (default: empty)

The password for the distinguished name above.
If
you have to use this, you probably want to make

the
map configuration file readable only by the
Postfix
user. When using the obsolete ldap:ldapsource
syn-
tax, with map parameters in main.cf, it is not
pos-
sible to securely store the bind password. This
is
because main.cf needs to be world readable to
allow
local accounts to submit mail via the sendmail
com-
mand. Example:
bind_pw = postfixpw
cache (IGNORED with a warning)
cache_expiry (IGNORED with a warning)
cache_size (IGNORED with a warning)

The above parameters are NO LONGER SUPPORTED
by
Postfix. Cache support has been dropped
from
OpenLDAP as of release 2.1.13.
recursion_limit (default: 1000)

A limit on the nesting depth of DN and URL
special
result attribute evaluation. The limit must be
a
non-zero positive number.
expansion_limit (default: 0)
A limit on the total number of result
elements
returned (as a comma separated list) by a
lookup
against the map. A setting of zero disables
the
limit. Lookups fail with a temporary error if

the
limit is exceeded. Setting the limit to 1
ensures
that lookups do not return multiple values.
size_limit (default: $expansion_limit)

A limit on the number of LDAP entries returned
by
any single LDAP query performed as part of
the
lookup. A setting of 0 disables the limit.
Expan-
sion of DN and URL references involves nested
LDAP
queries, each of which is separately subjected
to
this limit.
Note: even a single LDAP entry can generate

multi-
ple lookup results, via multiple result
attributes
and/or multi-valued result attributes. This
limit
caps the per query resource utilization on the
LDAP
server, not the final multiplicity of the
lookup
result. It is analogous to the "-z" option
of
"ldapsearch".
dereference (default: 0)
When to dereference LDAP aliases. (Note that
this
has nothing do with Postfix aliases.) The
permitted
values are those legal for the OpenLDAP/UM
LDAP
implementations:
0 never

1 when searching
2 when locating the base object for the

search
3 always
See ldap.h or the ldap_open(3) or ldapsearch(1)

man
pages for more information. And if you're using
an
LDAP package that has other possible values,
please
bring it to the attention of the
postfix-
users@postfix.org mailing list.
chase_referrals (default: 0)
Sets (or clears) LDAP_OPT_REFERRALS (requires
LDAP
version 3 support).
version (default: 2)
Specifies the LDAP protocol version to use.
debuglevel (default: 0)
What level to set for debugging in the
OpenLDAP
libraries.
LDAP SSL AND STARTTLS PARAMETERS

If you're using the OpenLDAP libraries compiled with
SSL
support, Postfix can connect to LDAP SSL servers and
can
issue the STARTTLS command.
LDAP SSL service can be requested by using a LDAP SSL

URL
in the server_host parameter:
server_host = ldaps://ldap.example.com:636

STARTTLS can be turned on with the start_tls parameter:

start_tls = yes
Both forms require LDAP protocol version 3, which has

to
be set explicitly with:
version = 3
If any of the Postfix programs querying the map is

config-
ured in master.cf to run chrooted, all the
certificates
and keys involved have to be copied to the chroot jail.
Of
course, the private keys should only be readable by
the
user "postfix".
The following parameters are relevant to LDAP SSL

and
STARTTLS:
start_tls (default: no)

Whether or not to issue STARTTLS upon connection
to
the server. Don't set this with LDAP SSL (the
SSL
session is setup automatically when the TCP
connec-
tion is opened).
tls_ca_cert_dir (No default; set either this

or
tls_ca_cert_file)
Directory containing X509 Certificate
Authority
certificates in PEM format which are to be
recog-
nized by the client in SSL/TLS connections.
The
files each contain one CA certificate. The
files
are looked up by the CA subject name hash

value,
which must hence be available. If more than one
CA
certificate with the same name hash value
exist,
the extension must be different (e.g.
9d66eef0.0,
9d66eef0.1 etc). The search is performed in
the
ordering of the extension number, regardless
of
other properties of the certificates. Use
the
c_rehash utility (from the OpenSSL distribution)
to
create the necessary links.
tls_ca_cert_file (No default; set either this

or
tls_ca_cert_dir)
File containing the X509 Certificate Authority
cer-
tificates in PEM format which are to be
recognized
by the client in SSL/TLS connections. This
setting
takes precedence over tls_ca_cert_dir.
tls_cert (No default; you must set this)

File containing client's X509 certificate to
be
used by the client in SSL/ TLS connections.
tls_key (No default; you must set this)

File containing the private key corresponding
to
the above tls_cert.
tls_require_cert (default: no)

Whether or not to request server's X509
certificate
and check its validity when establishing SSL/

TLS
connections.
tls_random_file (No default)

Path of a file to obtain random bits from
when
/dev/[u]random is not available, to be used by
the
client in SSL/TLS connections.
tls_cipher_suite (No default)

Cipher suite to use in SSL/TLS negotiations.
EXAMPLE
Here's a basic example for using LDAP to look up local
(8)
aliases. Assume that in main.cf, you have:
alias_maps = hash:/etc/aliases,
ldap:/etc/postfix/ldap-aliases.cf
and in ldap:/etc/postfix/ldap-aliases.cf you have:

server_host = ldap.my.com
search_base = dc=my, dc=com
Upon receiving mail for a local address "ldapuser"

that
isn't found in the /etc/aliases database, Postfix
will
search the LDAP server listening at port 389
on
ldap.my.com. It will bind anonymously, search for
any
directory entries whose mailacceptinggeneralid
attribute
is "ldapuser", read the "maildrop" attributes of
those
found, and build a list of their maildrops, which will
be
treated as RFC822 addresses to which the message will
be
delivered.

SEE ALSO
mysql_table(5), MySQL lookup tables
pgsql_table(5), PostgreSQL lookup tables
README FILES
LDAP_README, Postfix LDAP client guide
LICENSE
this
software.
AUTHOR(S)
Carsten Hoeger, Hery Rakotoarisoa, John Hensley,
Keith
Stevenson, LaMont Jones, Liviu Daia, Manuel Guesdon,
Mike
Mattice, Prabhat K Singh, Sami Haahtinen, Samuel
Tardieu,
Victor Duchovni, and many others.
LDAP_TABLE
(5)

Postfix manual - smtp(8)
SMTP(8) SMTP
(8)
NAME
smtp - Postfix remote delivery via SMTP
SYNOPSIS
smtp [generic Postfix daemon options]
DESCRIPTION
The SMTP client processes message delivery requests
from
the queue manager. Each request specifies a queue file,
a
sender address, a domain or host to deliver to, and
recip-
ient information. This program expects to be run from
the
master(8) process manager.
The SMTP client updates the queue file and marks

recipi-
ents as finished, or it informs the queue manager
that
delivery should be tried again at a later time.
Delivery
status reports are sent to the bounce(8), defer(8)
or
trace(8) daemon as appropriate.
The SMTP client looks up a list of mail

exchanger
addresses for the destination host, sorts the list
by
preference, and connects to each listed address until
it
finds a server that responds.
When a server is not reachable, or when mail

delivery
fails due to a recoverable error condition, the
http://www.subneural.net/postfix-master/smtp.8.html (1 of 17)01/16/2005 15:46:21

SMTP
client will try to deliver the mail to an alternate
host.
After a successful mail transaction, a connection may

be
saved to the scache(8) connection cache server, so that
it
may be used by any SMTP client for a subsequent
transac-
tion.
By default, connection caching is enabled temporarily

for
destinations that have a high volume of mail in the
active
queue. Session caching can be enabled permanently for
spe-
cific destinations.
SECURITY
The SMTP client is moderately security-sensitive. It
talks
to SMTP servers and to DNS servers on the network.
The
SMTP client can be run chrooted at fixed low privilege.
STANDARDS
RFC 821 (SMTP protocol)
RFC 1651 (SMTP service extensions)
RFC 1652 (8bit-MIME transport)
RFC 1870 (Message Size Declaration)
RFC 2045 (MIME: Format of Internet Message Bodies)
RFC 2046 (MIME: Media Types)
RFC 2554 (AUTH command)
RFC 2920 (SMTP Pipelining)
RFC 3207 (STARTTLS command)
DIAGNOSTICS


Cor-
manager
can move them to the corrupt queue for further
inspection.

parameter,
the postmaster is notified of bounces, protocol
problems,
and of other trouble.
BUGS
SMTP connection caching does not work with TLS. The
neces-
sary support for TLS object passivation and re-
activation
does not exist without closing the session, which
defeats
the purpose.
SMTP connection caching assumes that SASL credentials

are
valid for all destinations that map onto the same
IP
address and TCP port.
Changes to main.cf are picked up automatically, as smtp
(8)
the

See
ignore_mx_lookup_error (no)
Ignore DNS MX lookups that produce no response.

smtp_always_send_ehlo (yes)
Always send EHLO at the start of an SMTP session.
smtp_never_send_ehlo (no)
Never send EHLO at the start of an SMTP session.
smtp_defer_if_no_mx_address_found (no)
Defer mail delivery when no MX record resolves
to
an IP address.
smtp_line_length_limit (990)
The maximal length of message header and body
lines
that Postfix will send via SMTP.
smtp_pix_workaround_delay_time (10s)
How long the Postfix SMTP client pauses
before
sending ".<CR><LF>" in order to work around the
PIX
firewall "<CR><LF>.<CR><LF>" bug.
smtp_pix_workaround_threshold_time (500s)
How long a message must be queued before the
PIX
firewall "<CR><LF>.<CR><LF>" bug workaround
is
turned on.
smtp_quote_rfc821_envelope (yes)
Quote addresses in SMTP MAIL FROM and RCPT TO
com-
mands as required by RFC 821.
smtp_skip_5xx_greeting (yes)
Skip SMTP servers that greet with a 5XX status
code
(go away, do not try again later).

smtp_skip_quit_response (yes)
Do not wait for the response to the SMTP QUIT
com-
mand.
Available in Postfix version 2.0 and earlier:
smtp_skip_4xx_greeting (yes)
Skip SMTP servers that greet with a 4XX status
code
(go away, try again later).
smtp_discard_ehlo_keyword_address_maps (empty)
Lookup tables, indexed by the remote SMTP
server
address, with case insensitive lists of EHLO
key-
words (pipelining, starttls, auth, etc.) that
the
SMTP client will ignore in the EHLO response from
a
remote SMTP server.
smtp_discard_ehlo_keywords (empty)
A case insensitive list of EHLO keywords
(pipelin-
ing, starttls, auth, etc.) that the SMTP
client
will ignore in the EHLO response from a remote
SMTP
server.
MIME PROCESSING CONTROLS

disable_mime_output_conversion (no)
Disable the conversion of 8BITMIME format to
7BIT
format.

boundary
strings.
processor
will handle.
EXTERNAL CONTENT INSPECTION CONTROLS

smtp_send_xforward_command (no)
Send the non-standard XFORWARD command when
the
Postfix SMTP server EHLO response announces
XFOR-
WARD support.
SASL AUTHENTICATION CONTROLS

smtp_sasl_auth_enable (no)
Enable SASL authentication in the Postfix
SMTP
client.
smtp_sasl_password_maps (empty)
Optional SMTP client lookup tables with one
user-
name:password entry per remote hostname or
domain.
smtp_sasl_security_options (noplaintext, noanonymous)

What authentication mechanisms the Postfix
SMTP
client is allowed to use.
smtp_sasl_mechanism_filter (empty)
If non-empty, a Postfix SMTP client filter for
the

remote SMTP server's list of offered SASL

mecha-
nisms.
STARTTLS SUPPORT CONTROLS

Detailed information about STARTTLS configuration may
be
found in the TLS_README document.
smtp_use_tls (no)
Opportunistic mode: use TLS when a remote
SMTP
server announces STARTTLS support, otherwise
send
the mail in the clear.
smtp_enforce_tls (no)
Enforcement mode: require that remote SMTP
servers
use TLS encryption, and never send mail in
the
clear.
smtp_sasl_tls_security_options
($smtp_sasl_secu-
rity_options)
The SASL authentication security options that
the
Postfix SMTP client uses for TLS encrypted
SMTP
sessions.
smtp_starttls_timeout (300s)
Time limit for Postfix SMTP client write and
read
operations during TLS startup and shutdown
hand-
shake procedures.
smtp_tls_CAfile (empty)
The file with the certificate of the
certification

authority (CA) that issued the Postfix SMTP

client
certificate.
smtp_tls_CApath (empty)
Directory with PEM format certificate
authority
certificates that the Postfix SMTP client uses
to
verify a remote SMTP server certificate.
smtp_tls_cert_file (empty)
File with the Postfix SMTP client RSA
certificate
in PEM format.
smtp_tls_cipherlist (empty)
Controls the Postfix SMTP client TLS cipher
selec-
tion scheme.
smtp_tls_dcert_file (empty)
File with the Postfix SMTP client DSA
certificate
in PEM format.
smtp_tls_dkey_file ($smtp_tls_dcert_file)
File with the Postfix SMTP client DSA private
key
in PEM format.
smtp_tls_enforce_peername (yes)
When TLS encryption is enforced, require that
the
remote SMTP server hostname matches the
information
in the remote SMTP server certificate.
smtp_tls_key_file ($smtp_tls_cert_file)
File with the Postfix SMTP client RSA private
key
in PEM format.

smtp_tls_loglevel (0)
Enable additional Postfix SMTP client logging
of
TLS activity.
smtp_tls_note_starttls_offer (no)
Log the hostname of a remote SMTP server
that
offers STARTTLS, when TLS is not already
enabled
for that server.
smtp_tls_per_site (empty)
Optional lookup tables with the Postfix SMTP
client
TLS usage policy by next-hop domain name and
by
remote SMTP server hostname.
smtp_tls_scert_verifydepth (5)
The verification depth for remote SMTP server
cer-
tificates.
smtp_tls_session_cache_database (empty)
Name of the file containing the optional
Postfix
SMTP client TLS session cache.
smtp_tls_session_cache_timeout (3600s)
The expiration time of Postfix SMTP client TLS
ses-
sion cache information.
tls_daemon_random_bytes (32)
The number of pseudo-random bytes that an smtp
(8)
or smtpd(8) process requests from the tlsmgr
(8)
server in order to seed its internal pseudo

random
number generator (PRNG).

smtp_destination_concurrency_limit
($default_destina-
The maximal number of parallel deliveries to
the
same destination via the smtp message
delivery
transport.
smtp_destination_recipient_limit
($default_destina-
The maximal number of recipients per delivery
via
the smtp message delivery transport.
smtp_connect_timeout (30s)
The SMTP client time limit for completing a
TCP
connection, or zero (use the operating
system
built-in time limit).
smtp_helo_timeout (300s)
The SMTP client time limit for sending the HELO
or
EHLO command, and for receiving the initial
server
response.
smtp_xforward_timeout (300s)
The SMTP client time limit for sending the
XFORWARD
command, and for receiving the server response.
smtp_mail_timeout (300s)

MAIL
FROM command, and for receiving the
server
response.
smtp_rcpt_timeout (300s)
SMTP
RCPT TO command, and for receiving the
server
response.
smtp_data_init_timeout (120s)
SMTP
DATA command, and for receiving the
server
response.
smtp_data_xfer_timeout (180s)
SMTP
message content.
smtp_data_done_timeout (600s)
SMTP
".", and for receiving the server response.
smtp_quit_timeout (300s)
QUIT
smtp_mx_address_limit (0)
The maximal number of MX (mail exchanger)
IP
addresses that can result from mail
exchanger
lookups, or zero (no limit).

smtp_mx_session_limit (2)
The maximal number of SMTP sessions per
delivery
request before giving up or delivering to a
fall-
back relay host, or zero (no limit).
smtp_rset_timeout (20s)
RSET
smtp_connection_cache_destinations (empty)
Permanently enable SMTP connection caching for
the
specified destinations.
smtp_connection_cache_on_demand (yes)
Temporarily enable SMTP connection caching while
a
destination has a high volume of mail in the
active
queue.
smtp_connection_cache_reuse_limit (10)
When SMTP connection caching is enabled, the
number
of times that an SMTP session is reused before
it
is closed.
smtp_connection_cache_time_limit (2s)
When SMTP connection caching is enabled, the
amount
of time that an unused SMTP client socket is
kept
open before it is closed.

a
the
hostname
verbose
specified
error_notice_recipient (postmaster)
The recipient of postmaster notifications
about
mail delivery problems that are caused by
policy,
resource, software or protocol errors.

the
postmaster.
best_mx_transport (empty)
Where the Postfix SMTP client should deliver
mail
when it detects a "mail loops back to myself"
error
condition.

and

to
a
disable_dns_lookups (no)
Disable DNS lookups in the Postfix SMTP and
LMTP
clients.
fallback_relay (empty)
Optional list of relay hosts for SMTP
destinations
that can't be found or that are unreachable.
sys-
ipc_timeout (3600s)
information
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a
pro-

cess.
daemon
process.
proxy_interfaces (empty)
sys-
tem receives mail on by way of a proxy or
network
address translation unit.
smtp_bind_address (empty)
An optional numerical network address that the
SMTP
client should bind to when making a connection.
smtp_helo_name">smtp_helo_name ($myhostname)
The hostname to send in the SMTP EHLO or HELO
com-
mand.
smtp_host_lookup (dns)
What mechanisms when the SMTP client uses to
look
up a host's IP address.
smtp_randomize_addresses (yes)
Randomize the order of equal-preference MX
host
addresses.
pro-

"smtpd"
SEE ALSO
scache(8), connection cache server
tlsmgr(8), TLS session and PRNG management
README FILES
SASL_README, Postfix SASL howto
TLS_README, Postfix STARTTLS howto
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
Command pipelining in cooperation with:

Jon Ribbens
Oaktree Internet Solutions Ltd.,
Internet House,
Canal Basin,
Coventry,
CV1 4LY, United Kingdom.
Connection caching in cooperation with:

Victor Duchovni
Morgan Stanley
TLS support originally by:

Lutz Jaenicke
BTU Cottbus
Allgemeine Elektrotechnik
Universitaetsplatz 3-4
D-03044 Cottbus, Germany
SMTP
(8)

Postfix manual - scache(8)
SCACHE(8) SCACHE
(8)
NAME
scache - Postfix connection cache server
SYNOPSIS
scache [generic Postfix daemon options]
DESCRIPTION
The scache server maintains a shared multi-
connection
cache. This information can be used by, for example,
Post-
fix SMTP clients or other Postfix delivery agents.
The connection cache is organized into logical

destination
names, physical endpoint names, and connections.
As a specific example, logical SMTP destinations

specify
(transport, domain, port), and physical SMTP
endpoints
specify (transport, IP address, port). An SMTP
connection
may be saved after a successful mail transaction.
In the general case, one logical destination may refer

to
zero or more physical endpoints, one physical endpoint
may
be referenced by zero or more logical destinations,
and
one endpoint may refer to zero or more connections.
The exact syntax of a logical destination or endpoint

name
is application dependent; the scache service does
not
care. A connection is stored as a file
http://www.subneural.net/postfix-master/scache.8.html (1 of 6)01/16/2005 15:46:21

descriptor
together with application-dependent information that
is
needed to re-activate a connection object. Again,
the
scache service is completely unaware about the details
of
that information.
All information is stored with a finite time to

live
(ttl). The connection cache daemon terminates when
no
client is connected for max_idle time units.
This server implements the following requests:
save_endp ttl endpoint endpoint_properties

file_descriptor
Save the specified file descriptor and
connection
property data under the specified endpoint
name.
The endpoint properties are used by the client
to
re-activate a passivated connection object.
find_endp endpoint
Look up cached properties and a cached
file
descriptor for the specified endpoint.
save_dest ttl destination destination_properties endpoint

Save the binding between a logical destination
and
an endpoint under the destination name,
together
with destination specific connection
properties.
The destination properties are used by the
client
to re-activate a passivated connection object.

find_dest destination
Look up cached destination properties, cached
end-
point properties, and a cached file descriptor
for
the specified logical destination.
SECURITY
The connection cache server is not security-sensitive.
It
does not talk to the network, and it does not talk
to
local users. The scache server can run chrooted at
fixed
low privilege.
The connection cache server is not a trusted process.

It
must not be used to store information that is
security
sensitive.
DIAGNOSTICS
BUGS
Sessions cannot be cached across multiple machines.
When a connection expires from the cache it is

closed
without protocol specific handshake.
Changes to main.cf are picked up automatically
as
scache(8) processes run for only a limited amount of
time.

See

RESOURCE CONTROLS
connection_cache_ttl_limit (2s)
The maximal time-to-live value that the
connection
cache server allows.
connection_cache_status_update_time (600s)
How frequently the scache(8) server logs
usage
statistics with connection cache hit and miss
rates
for logical destinations and for physical
end-
points.
and
to
a
ipc_timeout (3600s)
information
max_idle (100s)
Postfix
request
before exiting.

pro-
cess.
daemon
process.
pro-
"smtpd"
SEE ALSO
smtp(8), SMTP client
LICENSE
this
software.
HISTORY
This service was introduced with Postfix version 2.2.
AUTHOR(S)
Wietse Venema
P.O. Box 704
SCACHE
(8)


Postfix TLS Support
Postfix TLS Support
WARNING
By turning on TLS support in Postfix, you not only get the ability to encrypt mail and to
authenticate clients or servers. You also turn on thousands and thousands of lines of OpenSSL
library code. Assuming that OpenSSL is written as carefully as Wietse's own code, every 1000
lines introduce one additional bug into Postfix.

This document describes how to build Postfix with Transport Layer Security (TLS) support in
the Postfix SMTP client and Postfix SMTP server, and how to configure the TLS manager
daemon that maintains the Pseudo Random Number Generator (PRNG) pool and the TLS
session cache information.
● Compatibility with Postfix < 2.2 TLS support

● Building Postfix with TLS support
● SMTP Server specific settings
● SMTP Client specific settings
● TLS manager specific settings
● Reporting problems
● Credits
And last but not least, for the impatient:
● Getting started, quick and dirty
Compatibility with Postfix <2.2 TLS support

http://www.subneural.net/postfix-master/TLS_README.html (1 of 24)01/16/2005 15:46:23
Postfix TLS Support
Postfix version 2.2 TLS support is based on the Postfix/TLS patch by Lutz Jänicke, but differs
in a few minor ways.
● main.cf: Use btree instead of sdbm for TLS session cache databases.
TLS session cache databases are now accessed only by the tlsmgr(8) process, so there
are no more concurrency issues. Although Postfix has an sdbm client, the sdbm library
(1000 lines of code) is not included with Postfix.
TLS session caches can use any database that can store objects of several kbytes or
more, and that implements the sequence operation. In most cases, btree databases
should be adequate.
NOTE: You cannot use dbm databases. TLS session objects are too large.
● master.cf: Specify unix instead of fifo as the tlsmgr service type.
The smtp(8) and smtpd(8) processes now use a client-server protocol in order to access
the tlsmgr(8) pseudo-random number generation (PRNG) pool, and in order to access
the TLS session cache databases. Such a protocol cannot be run across fifos.
Building Postfix with TLS support

To build Postfix with TLS support, first we need to generate the make(1) files with the
necessary definitions. This is done by invoking the command "make makefiles in the
Postfix top-level directory and with arguments as shown next.
● If the OpenSSL include files (such as ssl.h) are in directory /usr/include/

openssl, and the OpenSSL libraries (such as libssl.so and libcrypto.so) are
in directory /usr/lib:
% make tidy # if you have left-over files from a

previous build
% make makefiles CCARGS="-DUSE_TLS" AUXLIBS="-
lssl -lcrypto"
● If the OpenSSL include files (such as ssl.h) are in directory /usr/local/

include/openssl, and the OpenSSL libraries (such as libssl.so and
libcrypto.so) are in directory /usr/local/lib:

Postfix TLS Support

previous build
% make makefiles CCARGS="-DUSE_TLS -I/usr/local/
include" \
AUXLIBS="-L/usr/local/lib -lssl -lcrypto"
If you need to apply other customizations (such as Berkeley DB databases, MySQL,

PosgreSQL, LDAP or SASL), see the respective Postfix README documents, and combine
their "make makefiles" instructions with the instructions above:

previous build
% make makefiles CCARGS="-DUSE_TLS \
(other -D or -I options)" \
AUXLIBS="-lssl -lcrypto \
(other -l options for libraries in /usr/lib) \
(-L/path/name + -l options for other libraries)"
To complete the build process, see the Postfix INSTALL instructions. Postfix has TLS support
turned off by default, so you can start using Postfix as soon as it is installed.
SMTP Server specific settings

Topics covered in this section:
● Server-side certificate and private key configuration

● Server-side TLS activity logging
● Enabling TLS in the Postfix SMTP server
● Client certificate verification
● Supporting AUTH over TLS only
● Server-side TLS session cache
● Server access control
● Server-side cipher controls
● Miscellaneous server controls
Server-side certificate and private key configuration
In order to use TLS, the Postfix SMTP server needs a certificate and a private key. Both must
be in "pem" format. The private key must not be encrypted, meaning: the key must be

Postfix TLS Support
accessible without password. Both certificate and private key may be in the same file.
Both RSA and DSA certificates are supported. Typically you will only have RSA certificates
issued by a commercial CA. In addition, the tools supplied with OpenSSL will by default issue
RSA certificates. You can have both at the same time, in which case the cipher used determines
which certificate is presented. For Netscape and OpenSSL clients without special cipher
choices, the RSA certificate is preferred.
In order for remote SMTP clients to check the Postfix SMTP server certificates, the CA
certificate (in case of a certificate chain, all CA certificates) must be available. You should add
these certificates to the server certificate, the server certificate first, then the issuing CA(s).
Example: the certificate for "server.dom.ain" was issued by "intermediate CA" which itself has
a certificate issued by "root CA". Create the server.pem file with:
% cat server_cert.pem intermediate_CA.pem > server.pem
A Postfix SMTP server certificate supplied here must be usable as SSL server certificate and
hence pass the "openssl verify -purpose sslserver ..." test.
A client that trusts the root CA has a local copy of the root CA certificate, so it is not necessary
to include the root CA certificate here. Leaving it out of the "server.pem" file reduces the
overhead of the TLS exchange.
If you want the Postfix SMTP server to accept remote SMTP client certificates issued by these
CAs, append the root certificate to $smtpd_tls_CAfile or install it in the $smtpd_tls_CApath
directory. When you configure trust in a root CA, it is not necessary to explicitly trust
intermediary CAs signed by the root CA, unless $smtpd_tls_verify_depth is less than the
number of CAs in the certificate chain for the clients of interest. With a verify depth of 1 you
can only verify certificates directly signed by a trusted CA, and all trusted intermediary CAs
need to be configured explicitly. With a verify depth of 2 you can verify clients signed by a
root CA or a direct intermediary CA (so long as the client is correctly configured to supply its
intermediate CA certificate).
RSA key and certificate examples:
smtpd_tls_cert_file = /etc/postfix/server.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
Their DSA counterparts:

Postfix TLS Support
smtpd_tls_dcert_file = /etc/postfix/server-dsa.pem
smtpd_tls_dkey_file = $smtpd_tls_dcert_file
To verify a remote SMTP client certificate, the Postfix SMTP server needs to trust the
certificates of the issuing certification authorities. These certificates in "pem" format can be
stored in a single $smtpd_tls_CAfile or in multiple files, one CA per file in the
$smtpd_tls_CApath directory. If you use a directory, don't forget to create the necessary "hash"
links with:
# $OPENSSL_HOME/bin/c_rehash /path/to/directory
The $smtpd_tls_CAfile contains the CA certificates of one or more trusted CAs. The file is
opened (with root privileges) before Postfix enters the optional chroot jail and so need not be
accessible from inside the chroot jail.
Additional trusted CAs can be specified via the $smtpd_tls_CApath directory, in which case
the certificates are read (with $mail_owner privileges) from the files in the directory when the
information is needed. Thus, the $smtpd_tls_CApath directory needs to be accessible inside the
optional chroot jail.
When you configure Postfix to request client certificates (by setting $smtpd_tls_asck_ccert =
yes), any certificates in $smtpd_tls_CAfile are sent to the client, in order to allow it to choose
an identity signed by a CA you trust. If no $smtpd_tls_CAfile is specified, no preferred CA list
is sent, and the client is free to choose an identity signed by any CA. Many clients use a fixed
identity regardless of the preferred CA list and you may be able to reduce TLS negotiation
overhead by installing client CA certificates mostly or only in $smtpd_tls_CApath. In the latter
case you need not specify a $smtpd_tls_CAfile.
Note, that unless client certificates are used to allow greater access to TLS authenticated
clients, it is best to not ask for client certificates at all, as in addition to increased overhead
some clients (notably in some cases qmail) are unable to complete the TLS handshake when
client certificates are requested.
Example:
smtpd_tls_CAfile = /etc/postfix/CAcert.pem
smtpd_tls_CApath = /etc/postfix/certs

Postfix TLS Support
Server-side TLS activity logging
To get additional information about Postfix SMTP server TLS activity you can increase the
loglevel from 0..4. Each logging level also includes the information that is logged at a lower
logging level.

3 Log hexadecimal and ASCII dump of TLS negotiation process
Log hexadecimal and ASCII dump of complete transmission after
4
STARTTLS
Use loglevel 3 only in case of problems. Use of loglevel 4 is strongly discouraged.
Example:
smtpd_tls_loglevel = 0
To include information about the protocol and cipher used as well as the client and issuer
CommonName into the "Received:" message header, set the smtpd_tls_received_header
variable to true. The default is no, as the information is not necessarily authentic. Only
information recorded at the final destination is reliable, since the headers may be changed by
intermediate servers.
Example:
smtpd_tls_received_header = yes
Enabling TLS in the Postfix SMTP server
By default, TLS is disabled in the Postfix SMTP server, so no difference to plain Postfix is
visible. Explicitly switch it on using "smtpd_use_tls = yes".
Example:

Postfix TLS Support
smtpd_use_tls = yes
With this, Postfix SMTP server announces STARTTLS support to SMTP clients, but does not
require that clients use TLS encryption.
Note: when an unprivileged user invokes "sendmail -bs", STARTTLS is never offered due to
You can ENFORCE the use of TLS, so that the Postfix SMTP server announces STARTTLS
and accepts no mail without TLS encryption, by setting "smtpd_enforce_tls = yes". According
to RFC 2487 this MUST NOT be applied in case of a publicly-referenced Postfix SMTP
server. This option is off by default and should only seldom be used.
Example:
smtpd_enforce_tls = yes
TLS is sometimes used in the non-standard "wrapper" mode where a server always uses TLS,
instead of announcing STARTTLS support and waiting for clients to request TLS service.
Some clients, namely Outlook [Express] prefer the "wrapper" mode. This is true for OE
(Win32 < 5.0 and Win32 >=5.0 when run on a port<>25 and OE (5.01 Mac on all ports).
It is strictly discouraged to use this mode from main.cf. If you want to support this service,
enable a special port in master.cf and specify "-o smtpd_tls_wrappermode = yes" as an smtpd
(8) command line option. Port 465 (smtps) was once chosen for this feature.
Example:
smtps inet n - n -
- smtpd
-o smtpd_tls_wrappermode=yes -o
smtpd_sasl_auth_enable=yes
Client certificate verification
To receive a remote SMTP client certificate, the Postfix SMTP server must explicitly ask for
one (any contents of $smtpd_tls_CAfile are also sent to the client as a hint for choosing a

Postfix TLS Support
certificate from a suitable CA). Unfortunately, Netscape clients will either complain if no
matching client certificate is available or will offer the user client a list of certificates to choose
from. Additionally some MTAs (notably some versions of qmail) are unable to complete TLS
negotiation when client certificates are requested, and abort the SMTP session. So this option is
"off" by default. You will however need the certificate if you want to use certificate based
relaying with, for example, the permit_tls_clientcerts feature.
Example:
smtpd_tls_ask_ccert = no
You may also decide to REQUIRE a remote SMTP client certificate before allowing TLS
connections. This feature is included for completeness, and implies "smtpd_tls_ask_ccert =
yes".
Please be aware, that this will inhibit TLS connections without a proper client certificate and
that it makes sense only when non-TLS submission is disabled (smtpd_enforce_tls = yes).
Otherwise, clients could bypass the restriction by simply not using STARTTLS at all.
When TLS is not enforced, the connection will be handled as if only "smtpd_tls_ask_ccert =
yes" is specified, and a warning is logged.
Example:
smtpd_tls_req_ccert = no
A client certificate verification depth of 1 is sufficient if the certificate is directly issued by a

CA listed in the CA file. The default value (5) should also suffice for longer chains (root CA
issues special CA which then issues the actual certificate...)
Example:
smtpd_tls_ccert_verifydepth = 5
Supporting AUTH over TLS only
Sending AUTH data over an unencrypted channel poses a security risk. When TLS layer

Postfix TLS Support
encryption is required (smtpd_enforce_tls = yes), the Postfix SMTP server will announce and
accept AUTH only after the TLS layer has been activated with STARTTLS. When TLS layer
encryption is optional (smtpd_enforce_tls = no), it may however still be useful to only offer
AUTH when TLS is active. To maintain compatibility with non-TLS clients, the default is to
accept AUTH without encryption. In order to change this behavior, set "smtpd_tls_auth_only =
yes".
Example:
smtpd_tls_auth_only = no
Server-side TLS session cache
The Postfix SMTP server and the remote SMTP client negotiate a session, which takes some
computer time and network bandwidth. By default, this session information is cached only in
the smtpd(8) process actually using this session and is lost when the process terminates. To
share the session information between multiple smtpd(8) processes, a persistent session cache
can be used. You can specify any database type that can store objects of several kbytes and that
supports the sequence operator. DBM databases are not suitable because they can only store
small objects. The cache is maintained by the tlsmgr(8) process, so there is no problem with
concurrent access.
Example:
smtpd_tls_session_cache_database = btree:/etc/
postfix/smtpd_scache
Cached Postfix SMTP server session information expires after a certain amount of time.
Postfix/TLS does not use the OpenSSL default of 300s, but a longer time of 3600sec (=1 hour).
RFC 2246 recommends a maximum of 24 hours.
Example:
smtpd_tls_session_cache_timeout = 3600s
Server access control

Postfix TLS Support
Postfix TLS support introduces two additional features for Postfix SMTP server access control:
Allow the remote SMTP client SMTP request if the client certificate
passes verification, and if its fingerprint is listed in the list of client
certificates (see relay_clientcerts discussion below).
Allow the remote client SMTP request if the client certificate passes
verification.
The permit_tls_all_clientcerts feature must be used with caution, because it can result in too
many access permissions. Use this feature only if a special CA issues the client certificates, and
only if this CA is listed as trusted CA. If other CAs are trusted, any owner of a valid client
certificate would be authorized. The permit_tls_all_clientcerts feature can be practical for a
specially created email relay server.
It is however recommended to stay with the permit_tls_clientcerts feature and list all
certificates via $relay_clientcerts, as permit_tls_all_clientcerts does not permit any control
when a certificate must no longer be used (e.g. an employee leaving).
Example:
...
...
The Postfix list manipulation routines give special treatment to whitespace and some other
characters, making the use of certificate names unpractical. Instead we use the certificate
fingerprints as they are difficult to fake but easy to use for lookup. Postfix lookup tables are in
the form of (key, value) pairs. Since we only need the key, the value can be chosen freely, e.g.
the name of the user or host.
Example:

Postfix TLS Support
relay_clientcerts = hash:/etc/postfix/
relay_clientcerts
/etc/postfix/relay_clientcerts:
D7:04:2F:A7:0B:8C:A5:21:FA:31:77:E1:41:8A:EE:80
lutzpc.at.home
Server-side cipher controls
To influence the Postfix SMTP server cipher selection scheme, you can give cipherlist string.
A detailed description would go to far here; please refer to the OpenSSL documentation. If you
don't know what to do with it, simply don't touch it and leave the (openssl-)compiled in
default!
DO NOT USE " to enclose the string, specify just the string!!!
Example:
smtpd_tls_cipherlist = DEFAULT
If you want to take advantage of ciphers with EDH, DH parameters are needed. Instead of
using the built-in DH parameters for both 1024bit and 512bit, it is better to generate "own"
parameters, since otherwise it would "pay" for a possible attacker to start a brute force attack
against parameters that are used by everybody. For this reason, the parameters chosen are
already different from those distributed with other TLS packages.
To generate your own set of DH parameters, use:
% openssl gendh -out /etc/postfix/dh_1024.pem -2 -

rand /var/run/egd-pool 1024
% openssl gendh -out /etc/postfix/dh_512.pem -2 -
rand /var/run/egd-pool 512
Examples:
smtpd_tls_dh1024_param_file = /etc/postfix/
dh_1024.pem
smtpd_tls_dh512_param_file = /etc/postfix/dh_512.

Postfix TLS Support
pem
Miscellaneous server controls
The smtpd_starttls_timeout parameter limits the time of Postfix SMTP server write and read
operations during TLS startup and shutdown handshake procedures.
Example:
smtpd_starttls_timeout = 300s
SMTP Client specific settings

Topics covered in this section:
● Client-side certificate and private key configuration

● Client-side TLS activity logging
● Client-side TLS session cache
● Enabling TLS in the Postfix SMTP client
● Server certificate verification
● Client-side cipher controls
● Miscellaneous client controls
Client-side certificate and private key configuration
During TLS startup negotiation the Postfix SMTP client may present a certificate to the remote
SMTP server. The Netscape client is rather clever here and lets the user select between only
those certificates that match CA certificates offered by the remote SMTP server. As the Postfix
SMTP client uses the "SSL_connect()" function from the OpenSSL package, this is not
possible and we have to choose just one certificate. So for now the default is to use _no_
certificate and key unless one is explicitly specified here.
Both RSA and DSA certificates are supported. You can have both at the same time, in which
case the cipher used determines which certificate is presented.
It is possible for the Postfix SMTP client to use the same key/certificate pair as the Postfix
SMTP server. If a certificate is to be presented, it must be in "pem" format. The private key
must not be encrypted, meaning: it must be accessible without password. Both parts (certificate

Postfix TLS Support
and private key) may be in the same file.
In order for remote SMTP servers to verify the Postfix SMTP client certificates, the CA
certificate (in case of a certificate chain, all CA certificates) must be available. You should add
these certificates to the client certificate, the client certificate first, then the issuing CA(s).
Example: the certificate for "client.example.com" was issued by "intermediate CA" which itself
has a certificate of "root CA". Create the client.pem file with:
% cat client_cert.pem intermediate_CA.pem > client.

pem
A Postfix SMTP client certificate supplied here must be usable as SSL client certificate and
hence pass the "openssl verify -purpose sslclient ..." test.
A server that trusts the root CA has a local copy of the root CA certificate, so it is not necessary
to include the root CA certificate here. Leaving it out of the "client.pem" file reduces the
overhead of the TLS exchange.
If you want the Postfix SMTP client to accept remote SMTP server certificates issued by these
CAs, append the root certificate to $smtp_tls_CAfile or install it in the $smtp_tls_CApath
directory. When you configure trust in a root CA, it is not necessary to explicitly trust
intermediary CAs signed by the root CA, unless $smtp_tls_verify_depth is less than the
number of CAs in the certificate chain for the servers of interest. With a verify depth of 1 you
can only verify certificates directly signed by a trusted CA, and all trusted intermediary CAs
need to be configured explicitly. With a verify depth of 2 you can verify servers signed by a
root CA or a direct intermediary CA (so long as the server is correctly configured to supply its
intermediate CA certificate).
RSA key and certificate examples:
smtp_tls_cert_file = /etc/postfix/client.pem
smtp_tls_key_file = $smtp_tls_cert_file
Their DSA counterparts:
smtp_tls_dcert_file = /etc/postfix/client-dsa.pem
smtp_tls_dkey_file = $smtpd_tls_cert_file

Postfix TLS Support
To verify a remote SMTP server certificate, the Postfix SMTP client needs to trust the
certificates of the issuing certification authorities. These certificates in "pem" format can be
stored in a single $smtp_tls_CAfile or in multiple files, one CA per file in the
$smtp_tls_CApath directory. If you use a directory, don't forget to create the necessary "hash"
links with:
# $OPENSSL_HOME/bin/c_rehash /path/to/directory
The $smtp_tls_CAfile contains the CA certificates of one or more trusted CAs. The file is
opened (with root privileges) before Postfix enters the optional chroot jail and so need not be
accessible from inside the chroot jail.
Additional trusted CAs can be specified via the $smtp_tls_CApath directory, in which case the
certificates are read (with $mail_owner privileges) from the files in the directory when the
information is needed. Thus, the $smtp_tls_CApath directory needs to be accessible inside the
optional chroot jail.
The choice between $smtp_tls_CAfile and $smtpd_tls_CApath is a space/time tradeoff. If there

are many trusted CAs, the cost of preloading them all into memory may not pay off in reduced
access time when the certificate is needed.
Example:
smtp_tls_CAfile = /etc/postfix/CAcert.pem
smtp_tls_CApath = /etc/postfix/certs
Client-side TLS activity logging
To get additional information about Postfix SMTP client TLS activity you can increase the
loglevel from 0..4. Each logging level also includes the information that is logged at a lower
logging level.

3 Log hexadecimal and ASCII dump of TLS negotiation process
Log hexadecimal and ASCII dump of complete transmission after
4
STARTTLS

Postfix TLS Support
Example:
smtp_tls_loglevel = 0
Client-side TLS session cache
The remote SMTP server and the Postfix SMTP client negotiate a session, which takes some
computer time and network bandwidth. By default, this session information is cached only in
the smtp(8) process actually using this session and is lost when the process terminates. To
share the session information between multiple smtp(8) processes, a persistent session cache
can be used. You can specify any database type that can store objects of several kbytes and that
supports the sequence operator. DBM databases are not suitable because they can only store
small objects. The cache is maintained by the tlsmgr(8) process, so there is no problem with
concurrent access.
Example:
smtp_tls_session_cache_database = btree:/etc/
postfix/smtp_scache
Cached Postfix SMTP client session information expires after a certain amount of time. Postfix/
TLS does not use the OpenSSL default of 300s, but a longer time of 3600s (=1 hour). RFC
2246 recommends a maximum of 24 hours.
Example:
smtp_tls_session_cache_timeout = 3600s
Enabling TLS in the Postfix SMTP client
By default, TLS is disabled in the Postfix SMTP client, so no difference to plain Postfix is
visible. If you enable TLS, the Postfix SMTP client will send STARTTLS when TLS support is
announced by the remote SMTP server.
WARNING: MS Exchange servers will announce STARTTLS support even when the service
is not configured, so that the TLS handshake will fail. It may be wise to not use this option on

Postfix TLS Support
your central mail hub, as you don't know in advance whether you are going to connect to such a
host. Instead, use the smtp_tls_per_site recipient/site specific options that are described below.
When the TLS handshake fails and no other server is available, the Postfix SMTP client defers
the delivery attempt, and the mail stays in the queue.
Example:
smtp_use_tls = yes
You can ENFORCE the use of TLS, so that the Postfix SMTP client will not deliver mail over
unencrypted connections. In this mode, the remote SMTP server hostname must match the
information in the remote server certificate, and the server certificate must be issued by a CA
that is trusted by the Postfix SMTP client. If the remote server certificate doesn't verify or the
remote SMTP server hostname doesn't match, and no other server is available, the delivery
attempt is deferred and the mail stays in the queue.
The remote SMTP server hostname used in the check is beyond question, as it must be the
principal hostname (no CNAME allowed here). Checks are performed against all names
provided as dNSNames in the SubjectAlternativeName. If no dNSNames are specified, the
CommonName is checked. The behavior may be changed with the smtp_tls_enforce_peername
option which is discussed below.
This option is useful only if you know that you will only connect to servers that support RFC
2487 _and_ that present server certificates that meet the above requirements. An example
would be a client only sends email to one specific mailhub that offers the necessary
STARTTLS support.
Example:
smtp_enforce_tls = no
As of RFC 2487 the requirements for hostname checking for MTA clients are not set. When
TLS is required (smtp_enforce_tls = yes), the option smtp_tls_enforce_peername can be set to
"no" to disable strict remote SMTP server hostname checking. In this case, the mail delivery
will proceed regardless of the CommonName etc. listed in the certificate.
Note: the smtp_tls_enforce_peername setting has no effect on sessions that are controlled via

Postfix TLS Support
the smtp_tls_per_site table.
Disabling the remote SMTP server hostname verification can make sense in closed
environment where special CAs are created. If not used carefully, this option opens the danger
of a "man-in-the-middle" attack (the CommonName of this possible attacker is logged).
Example:
smtp_tls_enforce_peername = yes
Generally, trying TLS can be a bad idea, as some servers offer STARTTLS but the negotiation
will fail leading to unexplainable failures. Instead, it may be a good idea to choose the TLS
usage policy based on the recipient or the mailhub to which you are connecting.
Deciding the TLS usage policy per recipient may be difficult, since a single email delivery
attempt can involve several recipients. Instead, use of TLS is controlled by the Postfix next-hop
destination domain name and by the remote SMTP server hostname. If either of these matches
an entry in the smtp_tls_per_site table, appropriate action is taken.
The remote SMTP server hostname is simply the DNS name of the server that the Postfix
SMTP client connects to. The next-hop destination is Postfix specific. By default, this is the
domain name in the recipient address, but this information can be overruled by the transport(5)
table or by the relayhost parameter setting. In these cases the relayhost etc. must be listed in the
smtp_tls_per_site table, instead of the recipient domain name.
Format of the table: domain or host names are specified on the left-hand side; no wildcards are
allowed. On the right hand side specify one of the following keywords:
NONE
Don't use TLS at all.
MAY
Try to use STARTTLS if offered, otherwise use the unencrypted
connection. NOTE: STARTTLS can be used only if TLS is already
enabled via main.cf, so that the client TLS engine is properly initialized at
program startup.
MUST
Require usage of STARTTLS, require that the remote SMTP server
hostname matches the information in the remote SMTP server certificate,
and require that the remote SMTP server certificate was issued by a
trusted CA.

Postfix TLS Support
MUST_NOPEERMATCH
Require usage of STARTTLS, but do not require that the remote SMTP
server hostname matches the information in the remote SMTP server
certificate, or that the server certificate was issued by a trusted CA.
The actual TLS usage policy depends not only on whether the next-hop destination or remote
SMTP server hostname are found in the smtp_tls_per_site table, but also on the
smtp_enforce_tls setting:
● If no match was found, the policy is applied as specified with smtp_enforce_tls.
● If a match was found, and the smtp_enforce_tls policy is "enforce", NONE explicitly
switches it off; otherwise the "enforce" mode is used even for entries that specify MAY.
Special hint for TLS enforcement mode: since no secure DNS lookup mechanism is available,
mail can be delivered to the wrong remote SMTP server. This is not prevented by specifying
MUST for the next-hop domain name. The recommended setup is: specify local transport(5)
table entries for sensitive domains with explicit smtp:[mailhost] destinations (since you can
assure security of this table unlike DNS), then specify MUST for these mail hosts in the
smtp_tls_per_site table.
Example:
smtp_tls_per_site = hash:/etc/postfix/tls_per_site
As we decide on a "per site" basis whether or not to use TLS, it would be good to have a list of
sites that offered "STARTTLS". We can collect it ourselves with this option.
If the smtp_tls_note_starttls_offer feature is enabled and a server offers STARTTLS while TLS
is not already enabled for that server, the Postfix SMTP client logs a line as follows:
postfix/smtp[pid]: Host offered STARTTLS: [hostname.

example.com]
Example:
smtp_tls_note_starttls_offer = yes

Postfix TLS Support
Server certificate verification
When verifying a remote SMTP server certificate, a verification depth of 1 is sufficient if the
certificate is directly issued by a CA specified with smtp_tls_CAfile or smtp_tls_CApath. The
default value of 5 should also suffice for longer chains (root CA issues special CA which then
issues the actual certificate...)
Example:
smtp_tls_scert_verifydepth = 5
Client-side cipher controls
To influence the Postfix SMTP client cipher selection scheme, you can give cipherlist string. A
detailed description would go to far here; please refer to the OpenSSL documentation. If you
don't know what to do with it, simply don't touch it and leave the (openssl-)compiled in
default!
DO NOT USE " to enclose the string, specify just the string!!!
Example:
smtp_tls_cipherlist = DEFAULT
Miscellaneous client controls
The smtp_starttls_timeout parameter limits the time of Postfix SMTP client write and read
operations during TLS startup and shutdown handshake procedures. In case of problems the
Postfix SMTP client tries the next network address on the mail exchanger list, and defers
delivery if no alternative server is available.
Example:
smtp_starttls_timeout = 300s
TLS manager specific settings

Postfix TLS Support
The security of cryptographic software such as TLS depends critically on the ability to generate
unpredictable numbers for keys and other information. To this end, the tlsmgr(8) process
maintains a Pseudo Random Number Generator (PRNG) pool. This is queried by the smtp(8)
and smtpd(8) processes when they initialize. By default, these daemons request 32 bytes, the
equivalent to 256 bits. This is more than sufficient to generate a 128bit (or 168bit) session key.
Example:
tls_daemon_random_bytes = 32
In order to feed its in-memory PRNG pool, the tlsmgr(8) reads entropy from an external
source, both at startup and during run-time. Specify a good entropy source, like EGD or /dev/
urandom; be sure to only use non-blocking sources. If the entropy source is not a regular file,
you must prepend the source type to the source name: "dev:" for a device special file, or "egd:"
for a source with EGD compatible socket interface.
Examples (specify only one in main.cf):
tls_random_source = dev:/dev/urandom
tls_random_source = egd:/var/run/egd-pool
By default, tlsmgr(8) reads 32 bytes from the external entropy source at each seeding event.
This amount (256bits) is more than sufficient for generating a 128bit symmetric key. With
EGD and device entropy sources, the tlsmgr(8) limits the amount of data read at each step to
255 bytes. If you specify a regular file as entropy source, a larger amount of data can be read.
Example:
tls_random_bytes = 32
In order to update its in-memory PRNG pool, the tlsmgr(8) queries the external entropy source
again after a pseudo-random amount of time. The time is calculated using the PRNG, and is
between 0 and the maximal time specified with tls_random_reseed_period. The default
maximal time interval is 1 hour.
Example:

Postfix TLS Support
tls_random_reseed_period = 3600s
The tlsmgr(8) process saves the PRNG state to a persistent exchange file at regular times and
when the process terminates, so that it can recover the PRNG state the next time it starts up.
This file is created when it does not exist. Its default location is under the Postfix configuration
directory, which is not the proper place for information that is modified by Postfix. Instead, the
file location should probably be on the /var partition (but not inside the chroot jail).
Examples:
tls_random_exchange_name = /etc/postfix/prng_exch
tls_random_prng_update_period = 3600s
Getting started, quick and dirty

The following steps will get you started quickly. Because you sign your own Postfix public key
certificate, you get TLS encryption but no TLS authentication. This is sufficient for testing, and
for exchanging email with sites that you have no trust relationship with. For real authentication,
your Postfix public key certificate needs to be signed by a recognized Certificate Authority,
and Postfix needs to be configured with a list of public key certificates of Certificate
Authorities, so that Postfix can verify the public key certificates of remote hosts.
In the examples below, user input is shown in bold font, and a "#" prompt indicates a super-
user shell.
● Become your own Certificate Authority, so that you can sign your own public keys.
This example uses the CA.pl script that ships with OpenSSL. By default, OpenSSL
installs this as /usr/local/ssl/misc/CA.pl, but your mileage may vary. The
script creates a private key in ./demoCA/private/cakey.pem and a public key
in ./demoCA/cacert.pem.
% /usr/local/ssl/misc/CA.pl -newca
CA certificate filename (or enter to create)
Making CA certificate ...

Using configuration from /etc/ssl/openssl.cnf
Generating a 1024 bit RSA private key
....................++++++

Postfix TLS Support
.....++++++
writing new private key to './demoCA/private/
cakey.pem'
Enter PEM pass phrase:whatever
● Create an unpassworded private key for host FOO and create an unsigned public key
certificate.
% openssl req -new -nodes -keyout FOO-key.pem -

out FOO-req.pem -days 365
Using configuration from /etc/ssl/openssl.cnf
Generating a 1024 bit RSA private key
........................................++++++
....++++++
writing new private key to 'FOO-key.pem'
-----
You are about to be asked to enter information
that will be incorporated
into your certificate request.
What you are about to enter is what is called a
Distinguished Name or a DN.
There are quite a few fields but you can leave
some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:
New York
Locality Name (eg, city) []:Westchester
Organization Name (eg, company) [Internet Widgits
Pty Ltd]:Porcupine
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:FOO
Email Address []:wietse@porcupine.org
Please enter the following 'extra' attributes

to be sent with your certificate request
A challenge password []:whatever
An optional company name []:
● Sign the public key certificate for host FOO with the Certification Authority private key

Postfix TLS Support
that we created a few steps ago.
% openssl ca -out FOO-cert.pem -infiles FOO-req.

pem
Uing configuration from /etc/ssl/openssl.cnf
Enter PEM pass phrase:whatever
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
countryName :PRINTABLE:'US'
stateOrProvinceName :PRINTABLE:'New York'
localityName :PRINTABLE:'Westchester'
organizationName :PRINTABLE:'Porcupine'
commonName :PRINTABLE:'FOO'
emailAddress :
IA5STRING:'wietse@porcupine.org'
Certificate is to be certified until Nov 21
19:40:56 2005 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified,

commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
● Install the host private key, the host public key certificate, and the Certification
Authority certificate files. This requires super-user privileges.
# cp demoCA/cacert.pem FOO-key.pem FOO-cert.pem /

etc/postfix
# chmod 644 /etc/postfix/FOO-cert.pem /etc/
postfix/cacert.pem
# chmod 400 /etc/postfix/FOO-key.pem
● Configure Postfix, by adding the following to /etc/postfix/main.cf.
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_tls_cert_file = /etc/postfix/FOO-cert.pem
smtp_tls_key_file = /etc/postfix/FOO-key.pem
smtp_tls_session_cache_database = btree:/var/run/

Postfix TLS Support
smtp_tls_session_cache
smtp_use_tls = yes
smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtpd_tls_cert_file = /etc/postfix/FOO-cert.pem
smtpd_tls_key_file = /etc/postfix/FOO-key.pem
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:/var/run/
smtpd_tls_session_cache
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
Reporting problems
When reporting a problem, please be thorough in the report. Patches, when possible, are greatly
appreciated too.
Please differentiate when possible between:
● Problems in the TLS code: <postfix_tls@aet.tu-cottbus.de>

● Problems in vanilla Postfix: <postfix-users@postfix.org>
Credits
● TLS support for Postfix was originally developed by Lutz Jänicke at Cottbus Technical
University.
● Wietse Venema adopted the code, did some restructuring, and compiled this part of the
documentation from Lutz's documents.

Postfix manual - tlsmgr(8)
TLSMGR(8) TLSMGR
(8)
NAME
tlsmgr - Postfix TLS session cache and PRNG manager
SYNOPSIS
tlsmgr [generic Postfix daemon options]
DESCRIPTION
The tlsmgr(8) maintains the TLS session caches for
Postfix
SMTP client and server processes. It periodically
removes
entries that have expired, and entries that are no
longer
compatible with the currently running Postfix version.
The tlsmgr(8) also maintains the PRNG (pseudo random

num-
ber generator) pool. This is queried by the smtpd(8)
and
smtp(8) processes to seed their internal PRNG pools.
The tlsmgr(8)'s internal PRNG pool is initially

seeded
from an external source (EGD, /dev/urandom, or
regular
file). It is updated at configurable pseudo-random
inter-
vals with data from the external source. It is
updated
periodically with data from TLS session cache entries
and
with the time of day, and is updated with the time of
day
whenever a process requests tlsmgr(8) service.
The tlsmgr(8) saves the PRNG state to an exchange

file
periodically and when the process terminates, and
http://www.subneural.net/postfix-master/tlsmgr.8.html (1 of 6)01/16/2005 15:46:23

reads
the exchange file when initializing its PRNG.
SECURITY
tlsmgr(8) is not security-sensitive. The code that
main-
tains the external and internal PRNG pools does
not
"trust" the data that it manipulates, and the code
that
maintains the TLS session cache does not touch the
con-
tents of the cached entries, except for seeding its
inter-
nal PRNG pool.
The tlsmgr(8) can be run chrooted and with reduced

privi-
leges. At process startup it connects to the
entropy
source and exchange file, and creates or truncates
the
optional TLS session cache files.
DIAGNOSTICS
Problems and transactions are logged to the syslog
daemon.
BUGS
There is no automatic means to limit the number of
entries
in the TLS session caches and/or the size of the TLS
cache
files.
Changes to main.cf are not picked up
automatically,
because tlsmgr(8) is a persistent processes. Use the
com-
mand "postfix reload" after a configuration change.


See
TLS SESSION CACHE

smtpd_tls_session_cache_database (empty)
Postfix
SMTP server TLS session cache.
smtpd_tls_session_cache_timeout (3600s)
The expiration time of Postfix SMTP server TLS
ses-
smtp_tls_session_cache_database (empty)
Postfix
SMTP client TLS session cache.
smtp_tls_session_cache_timeout (3600s)
The expiration time of Postfix SMTP client TLS
ses-
PSEUDO RANDOM NUMBER GENERATOR

tls_random_source (see 'postconf -d' output)
The external entropy source for the in-
memory
tlsmgr(8) pseudo random number generator
(PRNG)
pool.
tls_random_bytes (32)
The number of bytes that tlsmgr(8) reads
from
$tls_random_source when (re)seeding the in-
memory
pseudo random number generator (PRNG) pool.
tls_random_exchange_name (${config_directory}/prng_exch)

Name of the pseudo random number generator

(PRNG)
state file that is maintained by tlsmgr(8).
tls_random_prng_update_period (3600s)
The time between attempts by tlsmgr(8) to save
the
state of the pseudo random number generator
(PRNG)
to the file specified with
$tls_ran-
dom_exchange_name.
tls_random_reseed_period (3600s)
The maximal time between attempts by tlsmgr(8)
to
re-seed the in-memory pseudo random number
genera-
tor (PRNG) pool from external sources.
and
to
a
pro-
cess.
daemon

process.
pro-
"smtpd"
SEE ALSO
smtp(8) Postfix SMTP client
smtpd(8) Postfix SMTP server
README FILES
TLS_README, Postfix TLS configuration and operation
LICENSE
this
software.
AUTHOR(S)
Lutz Jaenicke
BTU Cottbus
Adapted by:
Wietse Venema
P.O. Box 704
TLSMGR

(8)

Postfix manual - smtpd(8)
SMTPD(8) SMTPD
(8)
NAME
smtpd - Postfix SMTP server
SYNOPSIS
smtpd [generic Postfix daemon options]
DESCRIPTION
The SMTP server accepts network connection requests
and
performs zero or more SMTP transactions per
connection.
Each received message is piped through the cleanup(8)
dae-
mon, and is placed into the incoming queue as one
single
queue file. For this mode of operation, the
program
expects to be run from the master(8) process manager.
Alternatively, the SMTP server takes an established

con-
nection on standard input and deposits messages
directly
into the maildrop queue. In this so-called stand-
alone
mode, the SMTP server can accept mail even while the
mail
system is not running.
The SMTP server implements a variety of policies for

con-
nection requests, and for parameters given to HELO,
ETRN,
MAIL FROM, VRFY and RCPT TO commands. They are
detailed
below and in the main.cf configuration file.
SECURITY
http://www.subneural.net/postfix-master/smtpd.8.html (1 of 32)01/16/2005 15:46:25

The SMTP server is moderately security-sensitive. It

talks
to SMTP clients and to DNS servers on the network.
The
SMTP server can be run chrooted at fixed low privilege.
STANDARDS
RFC 1123 (Host requirements)
RFC 1985 (ETRN command)
RFC 3207 (STARTTLS command)
DIAGNOSTICS

parameter,
problems,
policy violations, and of other trouble.
as
smtpd(8) processes run for only a limited amount of
time.

See
The following parameters work around implementation
errors

in other software, and/or allow you to override

standards
in order to prevent undesirable use.
broken_sasl_auth_clients (no)
Enable inter-operability with SMTP clients
that
implement an obsolete version of the AUTH
command
(RFC 2554).
disable_vrfy_command (no)
Disable the SMTP VRFY command.
smtpd_noop_commands (empty)
List of commands that the Postfix SMTP
server
replies to with "250 Ok", without doing any
syntax
checks and without changing state.
strict_rfc821_envelopes (no)
Require that addresses received in SMTP MAIL
FROM
and RCPT TO commands are enclosed with <>, and
that
those addresses do not contain RFC 822 style
com-
ments or phrases.
resolve_null_domain (no)
Resolve an address that ends in the "@" null
domain
as if the local hostname were specified, instead
of
rejecting the address as invalid.
smtpd_reject_unlisted_sender (no)
Request that the Postfix SMTP server rejects
mail

from unknown sender addresses, even when

no
explicit reject_unlisted_sender access
restriction
is specified.
smtpd_sasl_exceptions_networks (empty)
What SMTP clients Postfix will not offer AUTH
sup-
port to.
smtpd_discard_ehlo_keyword_address_maps (empty)
Lookup tables, indexed by the remote SMTP
client
address, with case insensitive lists of EHLO
key-
words (pipelining, starttls, auth, etc.) that
the
SMTP server will not send in the EHLO response to
a
remote SMTP client.
smtpd_discard_ehlo_keywords (empty)
A case insensitive list of EHLO keywords
(pipelin-
ing, starttls, auth, etc.) that the SMTP
server
will not send in the EHLO response to a remote
SMTP
client.
ADDRESS REWRITING CONTROLS

See the ADDRESS_REWRITING_README document for a
detailed
discussion of Postfix address rewriting.
in

local_header_rewrite_clients (see 'postconf -d' output)

Append the domain name in $myorigin or $mydomain
to
message header addresses from these clients
only;
either don't rewrite message headers from
other
clients at all, or append the domain specified
with
the remote_header_rewrite_domain parameter.
AFTER QUEUE EXTERNAL CONTENT INSPECTION CONTROLS

As of version 1.0, Postfix can be configured to send
new
mail to an external content filter AFTER the mail
is
queued. This content filter is expected to inject
mail
back into a (Postfix or other) MTA for further
delivery.
See the FILTER_README document for details.
filters
BEFORE QUEUE EXTERNAL CONTENT INSPECTION CONTROLS

As of version 2.1, the Postfix SMTP server can be
config-
ured to send incoming mail to a real-time SMTP-based
con-
tent filter BEFORE mail is queued. This content filter
is
expected to inject mail back into Postfix. See
the
SMTPD_PROXY_README document for details on how to
config-
ure and operate this feature.

smtpd_proxy_filter (empty)
The hostname and TCP port of the mail
filtering
proxy server.
smtpd_proxy_ehlo ($myhostname)
How the Postfix SMTP server announces itself to
the
proxy filter.
smtpd_proxy_timeout (100s)
The time limit for connecting to a proxy filter
and
for sending or receiving information.
GENERAL CONTENT INSPECTION CONTROLS

The following parameters are applicable for both built-
in
and external content filters.
in

The following parameters are applicable for both
before-
queue and after-queue content filtering.
smtpd_authorized_xforward_hosts (empty)
What SMTP clients are allowed to use the
XFORWARD
feature.

Postfix SASL support (RFC 2554) can be used to

authenti-
cate remote SMTP clients to the Postfix SMTP server,
and
to authenticate the Postfix SMTP client to a remote
SMTP
server. See the SASL_README document for details.
broken_sasl_auth_clients (no)
Enable inter-operability with SMTP clients
that
implement an obsolete version of the AUTH
command
(RFC 2554).
smtpd_sasl_auth_enable (no)
SMTP
server.
smtpd_sasl_application_name (smtpd)
The application name used for SASL server
initial-
ization.
smtpd_sasl_local_domain (empty)
The name of the local SASL authentication realm.
smtpd_sasl_security_options (noanonymous)
Restrict what authentication mechanisms the
Postfix
SMTP server will offer to the client.
smtpd_sender_login_maps (empty)
Optional lookup table with the SASL login
names
that own sender (MAIL FROM) addresses.
smtpd_sasl_exceptions_networks (empty)
What SMTP clients Postfix will not offer AUTH

sup-
port to.
STARTTLS SUPPORT CONTROLS

Detailed information about STARTTLS configuration may
be
found in the TLS_README document.
smtpd_use_tls (no)
Opportunistic mode: announce STARTTLS support
to
SMTP clients, but do not require that clients
use
TLS encryption.
smtpd_enforce_tls (no)
Enforcement mode: announce STARTTLS support to
SMTP
clients, and require that clients use TLS
encryp-
tion.
smtpd_sasl_tls_security_options
($smtpd_sasl_secu-
rity_options)
The SASL authentication security options that
the
Postfix SMTP server uses for TLS encrypted
SMTP
sessions.
smtpd_starttls_timeout (300s)
The time limit for Postfix SMTP server write
and
read operations during TLS startup and
shutdown
handshake procedures.
smtpd_tls_CAfile (empty)
certification

server
certificate.
smtpd_tls_CAfile (empty)
certification
server
certificate.
smtpd_tls_ask_ccert (no)
Ask a remote SMTP client for a client
certificate.
smtpd_tls_auth_only (no)
When TLS encryption is optional in the Postfix
SMTP
server, do not announce or accept SASL
authentica-
tion over unencrypted connections.
smtpd_tls_ccert_verifydepth (5)
The verification depth for remote SMTP client
cer-
tificates.
smtpd_tls_cert_file (empty)
File with the Postfix SMTP server RSA
certificate
in PEM format.
smtpd_tls_cipherlist (empty)
Controls the Postfix SMTP server TLS cipher
selec-
tion scheme.
smtpd_tls_dcert_file (empty)
File with the Postfix SMTP server DSA
certificate
in PEM format.

smtpd_tls_dh1024_param_file (empty)
File with DH parameters that the Postfix
SMTP
server should use with EDH ciphers.
smtpd_tls_dh512_param_file (empty)
File with DH parameters that the Postfix
SMTP
server should use with EDH ciphers.
smtpd_tls_dkey_file ($smtpd_tls_dcert_file)
File with the Postfix SMTP server DSA private
key
in PEM format.
smtpd_tls_key_file ($smtpd_tls_cert_file)
File with the Postfix SMTP server RSA private
key
in PEM format.
smtpd_tls_loglevel (0)
Enable additional Postfix SMTP server logging
of
TLS activity.
smtpd_tls_received_header (no)
Request that the Postfix SMTP server
produces
Received: message headers that include
information
about the protocol and cipher used, as well as
the
client CommonName and client certificate
issuer
CommonName.
smtpd_tls_req_ccert (no)
When TLS encryption is enforced, require a
remote
SMTP client certificate in order to allow TLS
con-
nections to proceed.

smtpd_tls_session_cache_database (empty)
Postfix
SMTP server TLS session cache.
smtpd_tls_session_cache_timeout (3600s)
The expiration time of Postfix SMTP server TLS
ses-
smtpd_tls_wrappermode (no)
Run the Postfix SMTP server in the non-
standard
"wrapper" mode, instead of using the STARTTLS
com-
mand.
tls_daemon_random_bytes (32)
The number of pseudo-random bytes that an smtp
(8)
or smtpd(8) process requests from the tlsmgr
(8)
server in order to seed its internal pseudo
random
number generator (PRNG).
VERP SUPPORT CONTROLS

With VERP style delivery, each recipient of a
message
receives a customized copy of the message with his/her
own
recipient address encoded in the envelope sender
address.
The VERP_README file describes configuration and
operation
details of Postfix support for variable envelope
return
path addresses. VERP style delivery is requested with
the
SMTP XVERP command or with the "sendmail -V" command-

line
option and is available in Postfix version 1.1 and
later.
default_verp_delimiters (+=)
The two default VERP delimiter characters.
delimiter
line
Available in Postfix version 1.1 and 2.0:
authorized_verp_clients ($mynetworks)
What SMTP clients are allowed to specify the
XVERP
command.
smtpd_authorized_verp_clients ($authorized_verp_clients)
What SMTP clients are allowed to specify the
XVERP
command.

The DEBUG_README document describes how to debug parts
of
the Postfix mail system. The methods vary from making
the
software log a lot of detail, to running some daemon
pro-
cesses under control of a call tracer or debugger.
a
the

hostname
verbose
specified
about
policy,

the
postmaster.
soft_bounce (no)
otherwise
smtpd_authorized_xclient_hosts (empty)
What SMTP clients are allowed to use the
XCLIENT
feature.
KNOWN VERSUS UNKNOWN RECIPIENT CONTROLS

As of Postfix version 2.0, the SMTP server rejects
mail
for unknown recipients. This prevents the mail queue
from
clogging up with undeliverable MAILER-DAEMON
messages.

Additional information on this topic is in

the
LOCAL_RECIPIENT_README and ADDRESS_CLASS_README
documents.
show_user_unknown_table_name (yes)
Display the name of the recipient table in
the
"User unknown" responses.
canonical_maps (empty)
message
headers and envelopes.
recipient_canonical_maps (empty)
envelope
and header recipient addresses.
Parameters concerning known/unknown local recipients:
mydestination ($myhostname, localhost.$mydomain,

local-
host)
The list of domains that are delivered via
the
$local_transport mail delivery transport.
sys-
proxy_interfaces (empty)
sys-
tem receives mail on by way of a proxy or
network
address translation unit.

local_recipient_maps (proxy:unix:passwd.
byname
$alias_maps)
Lookup tables with all names or addresses of
local
recipients: a recipient address is local when
its
domain matches $mydestination, $inet_interfaces
or
$proxy_interfaces.
unknown_local_recipient_reject_code (550)
The numerical Postfix SMTP server response
code
when a recipient address is local,
and
$local_recipient_maps specifies a list of
lookup
tables that does not match the recipient.
Parameters concerning known/unknown recipients of

relay
destinations:
relay_domains ($mydestination)
What destination domains (and subdomains
thereof)
this system will relay mail to.
relay_recipient_maps (empty)
in
the domains that match $relay_domains.
unknown_relay_recipient_reject_code (550)
The numerical Postfix SMTP server reply code when
a
recipient address matches $relay_domains,
and
relay_recipient_maps specifies a list of
lookup

tables that does not match the recipient address.
Parameters concerning known/unknown recipients in

virtual
alias domains:
virtual_alias_domains ($virtual_alias_maps)
list
of virtual alias domains, that is, domains
for
which all addresses are aliased to addresses
in
other local or remote domains.
virtual_alias_maps ($virtual_maps)
Optional lookup tables that alias specific
mail
addresses or domains to other local or
remote
address.
unknown_virtual_alias_reject_code (550)
The SMTP server reply code when a recipient
address
matches $virtual_alias_domains, and
$vir-
tual_alias_maps specifies a list of lookup
tables
Parameters concerning known/unknown recipients in

virtual
mailbox domains:
virtual_mailbox_domains ($virtual_mailbox_maps)
list
of domains; mail is delivered via the
$vir-
tual_transport mail delivery transport.

virtual_mailbox_maps (empty)
in
the domains that match $virtual_mailbox_domains.
unknown_virtual_mailbox_reject_code (550)
The SMTP server reply code when a recipient
address
matches $virtual_mailbox_domains, and
$vir-
tual_mailbox_maps specifies a list of lookup
tables

The following parameters limit resource usage by the
SMTP
server and/or control client request rates.
pieces
lines
are reconstructed.
queue_minfree (0)
The minimal amount of free space in bytes in
the
queue file system that is needed to receive mail.
including
smtpd_recipient_limit (1000)
The maximal number of recipients that the
Postfix
SMTP server accepts per message delivery request.

smtpd_timeout (300s)
The time limit for sending a Postfix SMTP
server
response and for receiving a remote SMTP
client
request.
smtpd_history_flush_threshold (100)
The maximal number of lines in the Postfix
SMTP
server command history before it is flushed
upon
receipt of EHLO, RSET, or end of DATA.
The per SMTP client connection count and request rate

lim-
its are implemented in co-operation with the anvil(8)
ser-
vice, and are available in Postfix version 2.2 and
later.
smtpd_client_connection_count_limit (50)
How many simultaneous connections any client
is
allowed to make to this service.
smtpd_client_connection_rate_limit (0)
The maximal number of connection attempts
any
client is allowed to make to this service per
time
unit.
smtpd_client_message_rate_limit (0)
The maximal number of message delivery
requests
that any client is allowed to make to this
service
per time unit, regardless of whether or not
Postfix
actually accepts those messages.

smtpd_client_recipient_rate_limit (0)
The maximal number of recipient addresses that
any
client is allowed to send to this service per
time
unit, regardless of whether or not Postfix
actually
accepts those recipients.
smtpd_client_event_limit_exceptions ($mynetworks)
Clients that are excluded from connection
count,
connection rate, message rate or recipient
rate
restrictions.
TARPIT CONTROLS
When a remote SMTP client makes errors, the Postfix
SMTP
server can insert delays before responding. This can
help
to slow down run-away software. The behavior is
con-
trolled by an error counter that counts the number
of
errors within an SMTP session that a client makes
without
delivering mail.
smtpd_error_sleep_time (1s)
With Postfix 2.1 and later: the SMTP
server
response delay after a client has made more
than
$smtpd_soft_error_limit errors, and fewer
than
$smtpd_hard_error_limit errors, without
delivering
mail.
smtpd_soft_error_limit (10)

The number of errors a remote SMTP client

is
allowed to make without delivering mail before
the
Postfix SMTP server slows down all its responses.
smtpd_hard_error_limit (20)
The maximal number of errors a remote SMTP
client
is allowed to make without delivering mail.
smtpd_junk_command_limit (100)
The number of junk commands (NOOP, VRFY, ETRN
or
RSET) that a remote SMTP client can send before
the
Postfix SMTP server starts to increment the
error
counter with each junk command.
smtpd_recipient_overshoot_limit (1000)
The number of recipients that a remote SMTP
client
can send in excess of the limit specified
with
$smtpd_recipient_limit, before the Postfix
SMTP
server increments the per-session error count
for
each excess recipient.
ACCESS POLICY DELEGATION CONTROLS

As of version 2.1, Postfix can be configured to
delegate
access policy decisions to an external server that
runs
outside Postfix. See the file SMTPD_POLICY_README
for
more information.

smtpd_policy_service_max_idle (300s)
The time after which an idle SMTPD policy
service
connection is closed.
smtpd_policy_service_max_ttl (1000s)
The time after which an active SMTPD policy
service
connection is closed.
smtpd_policy_service_timeout (100s)
The time limit for connecting to, writing to
or
receiving from a delegated SMTPD policy server.
ACCESS CONTROLS
The SMTPD_ACCESS_README document gives an introduction
to
all the SMTP server access control features.
smtpd_delay_reject (yes)
Wait until the RCPT TO command before
evaluating
$smtpd_client_restrictions,
$smtpd_helo_restric-
tions and $smtpd_sender_restrictions, or wait
until
the ETRN command before
evaluating
$smtpd_client_restrictions and
$smtpd_helo_restric-
tions.

out-
put)
of
an

smtpd_client_restrictions (empty)
Optional SMTP server access restrictions in
the
context of a client SMTP connection request.
smtpd_helo_required (no)
Require that a remote SMTP client introduces
itself
at the beginning of an SMTP session with the
HELO
or EHLO command.
smtpd_helo_restrictions (empty)
Optional restrictions that the Postfix SMTP
server
applies in the context of the SMTP HELO command.
smtpd_sender_restrictions (empty)
Optional restrictions that the Postfix SMTP
server
applies in the context of the MAIL FROM command.
smtpd_recipient_restrictions
(permit_mynetworks,
reject_unauth_destination)
The access restrictions that the Postfix
SMTP
server applies in the context of the RCPT TO
com-
mand.
smtpd_etrn_restrictions (empty)
Optional SMTP server access restrictions in
the
context of a client ETRN request.
allow_untrusted_routing (no)
Forward mail with sender-specified
routing
(user[@%!]remote[@%!]site) from untrusted

clients
to destinations matching $relay_domains.
smtpd_restriction_classes (empty)
User-defined aliases for groups of access
restric-
tions.
smtpd_null_access_lookup_key (<>)
The lookup key to be used in SMTP access(5)
tables
instead of the null sender address.
permit_mx_backup_networks (empty)
Restrict the use of the permit_mx_backup
SMTP
access feature to only domains whose primary
MX
hosts match the listed networks.
smtpd_data_restrictions (empty)
Optional access restrictions that the Postfix
SMTP
server applies in the context of the SMTP DATA
com-
mand.
smtpd_expansion_filter (see 'postconf -d' output)

What characters are allowed in $name expansions
of
RBL reply templates.
smtpd_reject_unlisted_sender (no)
mail
from unknown sender addresses, even when
no

explicit reject_unlisted_sender access

restriction
is specified.
smtpd_reject_unlisted_recipient (yes)
mail
for unknown recipient addresses, even when
no
explicit reject_unlisted_recipient access
restric-
tion is specified.
smtpd_end_of_data_restrictions (empty)
Optional access restrictions that the Postfix
SMTP
server applies in the context of the SMTP END-
OF-
DATA command.
SENDER AND RECIPIENT ADDRESS VERIFICATION CONTROLS

Postfix version 2.1 introduces sender and
recipient
address verification. This feature is implemented
by
sending probe email messages that are not actually
deliv-
ered. This feature is requested via the
reject_unveri-
fied_sender and reject_unverified_recipient
access
restrictions. The status of verification probes is
main-
tained by the verify(8) server. See the file
ADDRESS_VER-
IFICATION_README for information about how to
configure
and operate the Postfix sender/recipient address
verifica-
tion service.

address_verify_poll_count (3)
How many times to query the verify(8) service
for
the completion of an address verification
request
in progress.
address_verify_poll_delay (3s)
The delay between queries for the completion of
an
address verification request in progress.
address_verify_sender (postmaster)
The sender address to use in address
verification
probes.
unverified_sender_reject_code (450)
code
when a recipient address is rejected by
the
reject_unverified_sender restriction.
unverified_recipient_reject_code (450)
The numerical Postfix SMTP server response when
a
recipient address is rejected by the
reject_unveri-
fied_recipient restriction.
ACCESS CONTROL RESPONSES

The following parameters control numerical SMTP
reply
codes and/or text responses.
access_map_reject_code (554)
code
when a client is rejected by an access(5)

map
restriction.
defer_code (450)
code
when a remote SMTP client request is rejected
by
the "defer" restriction.
invalid_hostname_reject_code (501)
code
when the client HELO or EHLO command parameter
is
rejected by the reject_invalid_hostname
restric-
tion.
maps_rbl_reject_code (554)
code
when a remote SMTP client request is blocked by
the
reject_rbl_client,
reject_rhsbl_client,
reject_rhsbl_sender or
reject_rhsbl_recipient
restriction.
non_fqdn_reject_code (504)
The numerical Postfix SMTP server reply code when
a
client request is rejected by
the
reject_non_fqdn_hostname, reject_non_fqdn_sender
or
reject_non_fqdn_recipient restriction.
reject_code (554)

code
when a remote SMTP client request is rejected
by
the "reject" restriction.
relay_domains_reject_code (554)
code
when a client request is rejected by
the
reject_unauth_destination recipient restriction.
unknown_address_reject_code (450)
code
when a sender or recipient address is rejected
by
the reject_unknown_sender_domain
or
reject_unknown_recipient_domain restriction.
unknown_client_reject_code (450)
code
when a client without valid address <=> name
map-
ping is rejected by the
restriction.
unknown_hostname_reject_code (450)
code
when the hostname specified with the HELO or
EHLO
command is rejected by the
restriction.

default_rbl_reply (see 'postconf -d' output)

The default SMTP server response template for
a
request that is rejected by an RBL-based
restric-
tion.
multi_recipient_bounce_reject_code (550)
code
when a remote SMTP client request is blocked by
the
reject_multi_recipient_bounce restriction.
rbl_reply_maps (empty)
Optional lookup tables with RBL response
templates.
and
to
a

com-
mands.
double_bounce_sender (double-bounce)
The sender address of postmaster notifications
that
are generated by the mail system.

ipc_timeout (3600s)
information
mail_name (Postfix)
The mail system name that is displayed in
Received:
headers, in the SMTP greeting banner, and
in
bounced mail.
queue
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a
myhostname (see 'postconf -d' output)

The internet hostname of this mail system.
mynetworks (see 'postconf -d' output)

The list of "trusted" SMTP clients that have
more
privileges than "strangers".
to
deliv-

ered to.
pro-
cess.
daemon
process.

direc-
tory.
exten-
sions (user+foo).
smtpd_banner ($myhostname ESMTP $mail_name)

The text that follows the 220 status code in
the
SMTP greeting banner.
pro-
"smtpd"
smtpd_forbidden_commands (CONNECT, GET, POST)

List of commands that causes the Postfix

SMTP
server to immediately terminate the session with
a
221 code.
SEE ALSO
anvil(8), connection/rate limiting
tlsmgr(8), TLS session and PRNG management
trivial-rewrite(8), address resolver
verify(8), address verification service
README FILES
ADDRESS_CLASS_README, blocking unknown hosted or relay
recipients
ADDRESS_REWRITING_README Postfix address manipulation
FILTER_README, external after-queue content filter
LOCAL_RECIPIENT_README, blocking unknown local recipients
SMTPD_ACCESS_README, built-in access policies
SMTPD_POLICY_README, external policy server
SMTPD_PROXY_README, external before-queue content filter
SASL_README, Postfix SASL howto
TLS_README, Postfix STARTTLS howto
VERP_README, Postfix XVERP extension
XCLIENT_README, Postfix XCLIENT extension
XFORWARD_README, Postfix XFORWARD extension
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704

TLS support originally by:

Lutz Jaenicke
BTU Cottbus
SMTPD
(8)

Postfix Address Rewriting
Postfix address rewriting purpose

Address rewriting is at the heart of the Postfix mail system. Postfix rewrites addresses for many different
purposes. Some are merely cosmetic, and some are necessary to deliver correctly formatted mail to the
correct destination. Examples of address rewriting in Postfix are:
● Transform an incomplete address into a complete address. For example, transform "username" into
"username@example.com", or transform "username@hostname" into "username@hostname.
example.com".
● Replace an address by an equivalent address. For example, replace "username@example.com" by

"firstname.lastname@example.com" when sending mail, and do the reverse transformation when
receiving mail.
● Replace an address by multiple addresses. For example, replace the address of an alias by the
addresses listed under that alias.
● Determine how and where to deliver mail for a specific address. For example, deliver mail for
"username@example.com" with the smtp(8) delivery agent, to the hosts that are listed in the DNS
as the mail servers for the domain "example.com".
Although Postfix currently has no address rewriting language, it can do surprisingly powerful address
manipulation via table lookup. Postfix typically uses lookup tables with fixed strings to map one address
to one or multiple addresses, and typically uses regular expressions to map multiple addresses to one or
multiple addresses. Fixed-string lookup tables may be in the form of local files, or in the form of NIS,
LDAP or SQL databases. The DATABASE_README document gives an introduction to Postfix lookup
tables.
● To rewrite or not to rewrite, or to label as invalid

● Postfix address rewriting overview
● Address rewriting when mail is received
❍ Rewrite addresses to standard form
http://www.subneural.net/postfix-master/ADDRESS_REWRITING_README.html (1 of 16)01/16/2005 15:46:26

Canonical address mapping

❍
❍ Address masquerading
❍ Automatic BCC recipients
❍ Virtual aliasing
● Address rewriting when mail is delivered

❍ Resolve address to destination
❍ Mail transport switch
❍ Relocated users table
❍ Local alias database
❍ Local per-user .forward files
❍ Local catch-all address
● Debugging your address manipulations
To rewrite or not to rewrite, or to label as invalid

Postfix versions 2.1 and earlier always rewrite message header addresses, and append Postfix's own
domain information to incomplete addresses. While rewriting message headers is OK for mail with a local
origin, it is undesirable for remote mail:
● Header mangling is frowned upon by mail standards,

● Appending Postfix's own domain information produces incorrect results with remote incomplete
addresses,
● Appending Postfix's own domain information sometimes creates the appearance that spam is sent
by local users.
Postfix versions 2.2 give you the option to either not rewrite message headers from remote SMTP clients
at all, or to label incomplete addresses in such message headers as invalid. Here is how it works:
● Postfix does not rewrite message headers from remote SMTP clients at all when the
remote_header_rewrite_domain parameter value is empty.
● Otherwise, Postfix appends the specified domain name to incomplete addresses in message headers
from remote SMTP clients. This feature can be used to append a reserved domain such as "domain.
invalid", so that incomplete addresses cannot be mistaken for local addresses.
The local_header_rewrite_clients parameter controls what SMTP clients Postfix considers local instead of
remote.
Postfix address rewriting overview

The figure below zooms in on those parts of Postfix that are most involved with address rewriting activity.
See the OVERVIEW document for an overview of the complete Postfix architecture. Names followed by
a number are Postfix daemon programs, while unnumbered names represent Postfix queues or internal
sources of mail messages.

trivial- trivial-
rewrite(8) rewrite(8)
(std form) (resolve)
^ | ^ |
| v | v
smtp
smtpd(8)
(8)
qmqpd cleanup - - - - lmtp
>- incoming active qmgr(8)
(8) (8) > > > < (8)
pickup local
(8) (8)
^ ^ |
| | v
bounces
forwarding deferred
notices
The table below summarizes all Postfix address manipulations. If you're reading this document for the
first time, skip forward to "Address rewriting when mail is received". Once you've finished reading the
remainder of this document, the table will help you to quickly find what you need.
Address Global turn-on Selective turn-off

Scope Daemon
manipulation control control
append_at_myorigin,
trivial-
Rewrite addresses to append_dot_mydomain,
all mail rewrite none
standard form swap_bangpath,
(8)
allow_percent_hack
Canonical address cleanup
all mail canonical_maps receive_override_options
mapping (8)
cleanup
Address masquerading all mail masquerade_domains receive_override_options
(8)
always_bcc,
Automatic BCC new cleanup
sender_bcc_maps, receive_override_options
recipients mail (8)
recipient_bcc_maps
cleanup
Virtual aliasing all mail virtual_alias_maps receive_override_options
(8)

trivial-
Resolve address to
all mail rewrite none none
destination
(8)
trivial-
Mail transport switch all mail rewrite transport_maps none
(8)
trivial-
Relocated users table all mail rewrite relocated_maps none
(8)
Local alias database all mail local(8) alias_maps none
Local per-user .
all mail local(8) forward_path none
forward files
Local catch-all address all mail local(8) luser_relay none
Address rewriting when mail is received

The cleanup(8) server receives mail from outside of Postfix as well as mail from internal sources such as
forwarded mail, undeliverable mail that is bounced to the sender, and postmaster notifications about
problems with the mail system.
The cleanup(8) server transforms the sender, recipients and message content into a standard form before
writing it to an incoming queue file. The server cleans up sender and recipient addresses in message
headers and in the envelope, adds missing message headers such as From: or Date: that are required by
mail standards, and removes message headers such as Bcc: that should not be present. The cleanup(8)
server delegates the more complex address manipulations to the trivial-rewrite(8) server as described later
in this document.
Address manipulations at this stage are:
● Rewrite addresses to standard form

● Canonical address mapping
● Address masquerading
● Automatic BCC recipients
● Virtual aliasing
Rewrite addresses to standard form
Before the cleanup(8) daemon runs an address through any address mapping lookup table, it first rewrites
the address to the standard "user@fully.qualified.domain" form, by sending the address to the trivial-
rewrite(8) daemon. The purpose of rewriting to standard form is to reduce the number of entries needed in

lookup tables.
Postfix versions 2.2 and later do not rewrite message headers from remote SMTP clients at all, unless a
non-empty domain name is specified with the remote_header_rewrite_domain configuration parameter.
The local_header_rewrite_clients parameter controls what SMTP clients Postfix considers local.
The Postfix trivial-rewrite(8) daemon implements the following hard-coded address manipulations:
Rewrite "@hosta,@hostb:user@site" to "user@site"
In case you wonder what this is, the address form above is called a route address,
and specifies that mail for "user@site" be delivered via "hosta" and "hostb". Usage
of this form has been deprecated for a long time. Postfix has no ability to handle
route addresses, other than to strip off the route part.
Rewrite "site!user" to "user@site"
This feature is controlled by the boolean swap_bangpath parameter (default: yes).

The purpose is to rewrite UUCP-style addresses to domain style. This is useful only
when you receive mail via UUCP, but it probably does not hurt otherwise.
Rewrite "user%domain" to "user@domain"
This feature is controlled by the boolean allow_percent_hack parameter (default:

yes). Typically, this is used in order to deal with monstrosities such as "user%
domain@otherdomain".
Rewrite "user" to "user@$myorigin"
This feature is controlled by the boolean append_at_myorigin parameter (default:

yes). You should never turn off this feature, because a lot of Postfix components
expect that all addresses have the form "user@domain".
Postfix versions 2.2 and later either do not rewrite message headers from remote
SMTP clients at all, or they append the domain name specified with the
remote_header_rewrite_domain configuration parameter.
If your machine is not the main machine for $myorigin and you wish to have some
users delivered locally without going via that main machine, make an entry in the
virtual alias table that redirects "user@$myorigin" to "user@$myhostname". See
also the "delivering some users locally" section in the
STANDARD_CONFIGURATION_README document.
Rewrite "user@host" to "user@host.$mydomain"

This feature is controlled by the boolean append_dot_mydomain parameter (default:

yes). The purpose is to get consistent treatment of different forms of the same
hostname.
Postfix versions 2.2 and later either do not rewrite message headers from remote
clients at all, or they append the domain name specified with the
remote_header_rewrite_domain configuration parameter.
Some will argue that rewriting "host" to "host.domain" is bad. That is why it can be
turned off. Others like the convenience of having Postfix's own domain appended
automatically.
Rewrite "user@site." to "user@site" (without the trailing dot).
A single trailing dot is silently removed. However, an address that ends in multiple
dots will be rejected as an invalid address.
Canonical address mapping
The cleanup(8) daemon uses the canonical(5) tables to rewrite addresses in message envelopes and in
message headers. By default all header and envelope addresses are rewritten; this is controlled with the
canonical_classes configuration parameter.
Postfix versions 2.2 and later do not rewrite message headers from remote clients at all, unless a non-
empty domain name is specified with the remote_header_rewrite_domain configuration parameter. The
local_header_rewrite_clients parameter controls what SMTP clients Postfix considers local.
Address rewriting is done for local and remote addresses. The mapping is useful to replace login names
by "Firstname.Lastname" style addresses, or to clean up invalid domains in mail addresses produced by
legacy mail systems.
Canonical mapping is disabled by default. To enable, edit the canonical_maps parameter in the main.cf
file and specify one or more lookup tables, separated by whitespace or commas.
Example:
/etc/postfix/canonical:
wietse Wietse.Venema
For static mappings as shown above, lookup tables such as hash:, ldap:, mysql: or pgsql: are sufficient.

For dynamic mappings you can use regular expression tables. This requires that you become intimately
familiar with the ideas expressed in regexp_table(5), pcre_table(5) and canonical(5).
In addition to the canonical maps which are applied to both sender and recipient addresses, you can
specify canonical maps that are applied only to sender addresses or to recipient addresses.
Example:
sender_canonical_maps = hash:/etc/postfix/
sender_canonical
recipient_canonical_maps = hash:/etc/postfix/
recipient_canonical
The sender and recipient canonical maps are applied before the common canonical maps. The
sender_canonical_classes and recipient_canonical_classes parameters control what addresses are subject
to sender_canonical_maps and recipient_canonical_maps mappings, respectively.
Sender-specific rewriting is useful when you want to rewrite ugly sender addresses to pretty ones, and still
want to be able to send mail to the those ugly address without creating a mailer loop.
Canonical mapping can be turned off selectively for mail received by smtpd(8), qmqpd(8), or pickup(8),
by overriding main.cf settings in the master.cf file. This feature is available in Postfix version 2.1 and
later.
Example:
:10026 inet n - n -
- smtpd
-o receive_override_options=no_address_mapping
Note: do not specify whitespace around the "=" here.
Address masquerading
Address masquerading is a method to hide hosts inside a domain behind their mail gateway, and to make
it appear as if the mail comes from the gateway itself, instead of from individual machines.
Postfix versions 2.2 and later do not rewrite message headers from remote SMTP clients at all, unless a
non-empty domain name is specified with the remote_header_rewrite_domain configuration parameter.
The local_header_rewrite_clients parameter controls what SMTP clients Postfix considers local.
Address masquerading is disabled by default, and is implemented by the cleanup(8) server. To enable,

edit the masquerade_domains parameter in the main.cf file and specify one or more domain names
separated by whitespace or commas. When Postfix tries to masquerade a domain, it processes the list from
left to right, and processing stops at the first match.
Example:
masquerade_domains = foo.example.com example.com
strips "any.thing.foo.example.com" to "foo.example.com", but strips "any.thing.else.example.com" to

"example.com".
A domain name prefixed with "!" means do not masquerade this domain or its subdomains:
masquerade_domains = !foo.example.com example.com
does not change "any.thing.foo.example.com" and "foo.example.com", but strips "any.thing.else.example.

com" to "example.com".
The masquerade_exceptions configuration parameter specifies what user names should not be subjected to
address masquerading. Specify one or more user names separated by whitespace or commas.
Example:
masquerade_exceptions = root
By default, Postfix makes no exceptions.
Subtle point: by default, address masquerading is applied only to message headers and to envelope sender
addresses, but not to envelope recipients. This allows you to use address masquerading on a mail gateway
machine, while still being able to forward mail from outside to users on individual machines.
In order to subject envelope recipient addresses to masquerading, too, specify (Postfix version 1.1 and
later):
masquerade_classes = envelope_sender, envelope_recipient,
header_sender, header_recipient
If you rewrite the envelope recipient like this, Postfix will no longer be able to send mail to individual
machines.

Address masquerading can be turned off selectively for mail received by smtpd(8), qmqpd(8), or pickup
(8), by overriding main.cf settings in the master.cf file. This feature is available in Postfix version 2.1 and
later.
Example:
:10026 inet n - n -
- smtpd
Automatic BCC recipients
After applying the canonical and masquerade mappings, the cleanup(8) daemon can generate optional
BCC (blind carbon-copy) recipients. Postfix provides three mechanisms:
always_bcc = address
Deliver a copy of all mail to the specified address. In Postfix versions before 2.1,
this feature is implemented by smtpd(8), qmqpd(8), or pickup(8).
sender_bcc_maps = type:table
Search the specified "type:table" lookup table with the envelope sender address for
an automatic BCC address. This feature is available in Postfix 2.1 and later.
recipient_bcc_maps = type:table
Search the specified "type:table" lookup table with the envelope recipient address
for an automatic BCC address. This feature is available in Postfix 2.1 and later.
Note: automatic BCC recipients are produced only for new mail. To avoid mailer loops, automatic BCC
recipients are not generated for mail that Postfix forwards internally, nor for mail that Postfix generates
itself.
Automatic BCC recipients (including always_bcc) can be turned off selectively for mail received by smtpd
(8), qmqpd(8), or pickup(8), by overriding main.cf settings in the master.cf file. This feature is available
in Postfix version 2.1 and later.
Example:
:10026 inet n - n -
- smtpd

Virtual aliasing
Before writing the recipients to the queue file, the cleanup(8) daemon uses the optional virtual(5) alias
tables to redirect mail for recipients. The mapping affects only envelope recipient addresses; it has no
effect on message headers or envelope sender addresses. Virtual alias lookups are useful to redirect mail
for virtual alias domains to real user mailboxes, and to redirect mail for domains that no longer exist.
Virtual alias lookups can also be used to transform " Firstname.Lastname " back into UNIX login names,
although it seems that local aliases may be a more appropriate vehicle. See the VIRTUAL_README
document for an overview of methods to host virtual domains with Postfix.
Virtual aliasing is disabled by default. To enable, edit the virtual_alias_maps parameter in the main.cf file
and specify one or more lookup tables, separated by whitespace or commas.
Example:
Wietse.Venema wietse
Addresses found in virtual alias maps are subjected to another iteration of virtual aliasing, but are not
subjected to canonical mapping, in order to avoid loops.
For static mappings as shown above, lookup tables such as hash:, ldap:, mysql: or pgsql: are sufficient.
For dynamic mappings you can use regular expression tables. This requires that you become intimately
familiar with the ideas expressed in regexp_table(5), pcre_table(5) and virtual(5).
Note: automatic BCC recipients are produced only for new mail. To avoid mailer loops, automatic BCC
recipients are not generated for mail that is forwarded internally, and are not generated for mail that is
generated by Postfix itself.
Virtual aliasing can be turned off selectively for mail received by smtpd(8), qmqpd(8), or pickup(8), by
overriding main.cf settings in the master.cf file. This feature is available in Postfix version 2.1 and later.
Example:
:10026 inet n - n -
- smtpd

At this point the message is ready to be stored into the Postfix incoming queue.
Address rewriting when mail is delivered

The Postfix queue manager sorts mail according to its destination and gives it to Postfix delivery agents
such as local(8), smtp(8), or lmtp(8). Just like the cleanup(8) server, the Postfix queue manager delegates
the more complex address manipulations to the trivial-rewrite(8) server.
Address manipulations at this stage are:
● Resolve address to destination

● Mail transport switch
● Relocated users table
Each Postfix delivery agent tries to deliver the mail to its destination, while encapsulating the sender,
recipients, and message content according to the rules of the SMTP, LMTP, etc. protocol. When mail
cannot be delivered, it is either returned to the sender or moved to the deferred queue and tried again later.
Address manipulations when mail is delivered via the local(8) delivery agent:
● Local alias database

● Local per-user .forward files
● Local catch-all address
The remainder of this document presents each address manipulation step in more detail, with specific
examples or with pointers to documentation with examples.
Resolve address to destination
The Postfix qmgr(8) queue manager selects new mail from the incoming queue or old mail from the
deferred queue, and asks the trivial-rewrite(8) address rewriting and resolving daemon where it should be
delivered.
As of version 2.0, Postfix distinguishes four major address classes. Each class has its own list of domain
names, and each class has its own default delivery method, as shown in the table below. See the
ADDRESS_CLASS_README document for the fine details. Postfix versions before 2.0 only distinguish
between local delivery and everything else.
Default delivery
Destination domain list Availability
method

$mydestination, $inet_interfaces,
$local_transport Postfix 1.0
$proxy_interfaces
$virtual_mailbox_domains $virtual_transport Postfix 2.0
$relay_domains $relay_transport Postfix 2.0
none $default_transport Postfix 1.0
Mail transport switch
Once the trivial-rewrite(8) daemon has determined a default delivery method it searches the optional
transport(5) table for information that overrides the message destination and/or delivery method. Typical
use of the transport(5) is to send mail to a system that is not connected to the Internet, or to use a special
SMTP client configuration for destinations that have special requirements. See, for example, the
STANDARD_CONFIGURATION_README and UUCP_README documents, and the examples in
the transport(5) manual page.
Transport table lookups are disabled by default. To enable, edit the transport_maps parameter in the main.
cf file and specify one or more lookup tables, separated by whitespace or commas.
Example:
Relocated users table
Next, the trivial-rewrite(8) address rewriting and resolving daemon runs each recipient through the
relocated(5) database. This table provides information on how to reach users that no longer have an
account, or what to do with mail for entire domains that no longer exist. When mail is sent to an address
that is listed in this table, the message is returned to the sender with an informative message.
The relocated(5) database is searched after transport(5) table lookups, in anticipation of transport(5) tables
that can replace one recipient address by a different one.
Lookups of relocated users are disabled by default. To enable, edit the relocated_maps parameter in the
main.cf file and specify one or more lookup tables, separated by whitespace or commas.
Example:
/etc/postfix/relocated:

username@example.com otheruser@elsewhere.tld
As of Postfix version 2, mail for a relocated user will be rejected by the SMTP server with the reason
"user has moved to otheruser@elsewhere.tld". Older Postfix versions will receive the mail first, and then
return it to the sender as undeliverable, with the same reason.
Local alias database
When mail is to be delivered locally, the local(8) delivery agent runs each local recipient name through
the aliases(5) database. The mapping does not affect addresses in message headers. Local aliases are
typically used to implement distribution lists, or to direct mail for standard aliases such as postmaster to
real people. The table can also be used to map "Firstname.Lastname" addresses to login names.
Alias lookups are enabled by default. The default configuration depends on the operating system
environment, but it is typically one of the following:
alias_maps = hash:/etc/aliases
alias_maps = dbm:/etc/aliases, nis:mail.aliases
The pathname of the alias database file is controlled with the alias_database configuration parameter. The
value is system dependent. Usually it is one of the following:
alias_database = hash:/etc/aliases (4.4BSD, LINUX)
alias_database = dbm:/etc/aliases (4.3BSD, SYSV<4)
alias_database = dbm:/etc/mail/aliases (SYSV4)
An aliases(5) file can specify that mail should be delivered to a local file, or to a command that receives
the message in the standard input stream. For security reasons, deliveries to command and file
destinations are performed with the rights of the alias database owner. A default userid, default_privs, is
used for deliveries to commands or files in "root"-owned aliases.
Local per-user .forward files
With delivery via the local(8) deliver agent, users can control their own mail delivery by specifying
destinations in a file called .forward in their home directories. The syntax of these files is the same as with
the local aliases(5) file, except that the left-hand side of the alias (lookup key and colon) are not present.
Local catch-all address
When the local(8) delivery agent finds that a message recipient does not exist, the message is normally
returned to the sender ("user unknown"). Sometimes it is desirable to forward mail for non-existing

recipients to another machine. For this purpose you can specify an alternative destination with the
luser_relay configuration parameter.
Alternatively, mail for non-existent recipients can be delegated to an entirely different message transport,
as specified with the fallback_transport configuration parameter. For details, see the local(8) delivery
agent documentation.
Note: if you use the luser_relay feature in order to receive mail for non-UNIX accounts, then you must
specify:
(i.e. empty) in the main.cf file, otherwise the Postfix SMTP server will reject mail for non-UNIX accounts
with "User unknown in local recipient table". See the LOCAL_RECIPIENT_README file for more
information on this.
luser_relay can specify one address. It is subjected to "$name" expansions. Examples:
$user@other.host
The bare username, without address extension, is prepended to "@other.host". For

example, mail for "username+foo" is sent to "username@other.host".
$local@other.host
The entire original recipient localpart, including address extension, is prepended to

"@other.host". For example, mail for "username+foo" is sent to "username
+foo@other.host".
sysadmin+$user
The bare username, without address extension, is appended to "sysadmin". For

example, mail for "username+foo" is sent to "sysadmin+username".
sysadmin+$local
The entire original recipient localpart, including address extension, is appended to

"sysadmin". For example, mail for "username+foo" is sent to "sysadmin+username
+foo".
Debugging your address manipulations

With Postfix version 2.1 and later you can ask Postfix to produce mail delivery reports for debugging

purposes. These reports not only show sender/recipient addresses after address rewriting and alias
expansion or forwarding, they also show information about delivery to mailbox, delivery to non-Postfix
command, responses from remote SMTP servers, and so on.
Postfix can produce two types of mail delivery reports for debugging:
● What-if: report what would happen, but do not actually deliver mail. This mode of operation is
requested with:
$ /usr/sbin/sendmail -bv address...

Mail Delivery Status Report will be mailed to <your login name>.
● What happened: deliver mail and report successes and/or failures, including replies from remote
SMTP servers. This mode of operation is requested with:
$ /usr/sbin/sendmail -v address...
Mail Delivery Status Report will be mailed to <your login name>.
These reports contain information that is generated by Postfix delivery agents. Since these run as daemon
processes and do not interact with users directly, the result is sent as mail to the sender of the test
message. The format of these reports is practically identical to that of ordinary non-delivery notifications.
As an example, below is the delivery report that is produced with the command "sendmail -bv postfix-
users@postfix.org". The first part of the report contains human-readable text. In this case, mail would be
delivered via mail.cloud9.net, and the SMTP server replies with "250 Ok". Other reports may show
delivery to mailbox, or delivery to non-Postfix command.
Content-Description: Notification
Content-Type: text/plain
This is the Postfix program at host spike.porcupine.org.
Enclosed is the mail delivery report that you requested.
The Postfix program
<postfix-users@postfix.org>: delivery via mail.cloud9.net

[168.100.1.4]: 250 Ok
The second part of the report is in machine-readable form, and includes the following information:
● The envelope sender address (wietse@porcupine.org).

● The envelope recipient address (postfix-users@postfix.org). If the recipient address was changed
by Postfix then Postfix also includes the original recipient address.
● The delivery status.

Some details are still preliminary and will change as Postfix implements the DSN (delivery status
notification) standards.
Content-Description: Delivery report

Content-Type: message/delivery-status
Reporting-MTA: dns; spike.porcupine.org

X-Postfix-Queue-ID: 84863BC0E5
X-Postfix-Sender: rfc822; wietse@porcupine.org
Arrival-Date: Tue, 13 Apr 2004 19:27:43 -0400 (EDT)
Final-Recipient: rfc822; postfix-users@postfix.org

Action: deliverable
Status: 2.0.0
Diagnostic-Code: X-Postfix; delivery via mail.cloud9.net
[168.100.1.4]: 250 Ok
The third part of the report contains the message that Postfix would have delivered, including From: and
To: message headers, so that you can see any effects of address rewriting on those. Mail submitted with
"sendmail -bv" has no body content so none is shown in the example below.
Content-Description: Message
Content-Type: message/rfc822
Received: by spike.porcupine.org (Postfix, from userid 1001)

id 84863BC0E5; Tue, 13 Apr 2004 19:27:43 -0400 (EDT)
Subject: probe
To: postfix-users@postfix.org
Message-Id: <20040413232743.84863BC0E5@spike.porcupine.org>
Date: Tue, 13 Apr 2004 19:27:43 -0400 (EDT)
From: wietse@porcupine.org (Wietse Venema)

Postfix Architecture Overview
Postfix Architecture
Overview
Introduction
This document presents an overview of the Postfix architecture, and is the place where you find
a pointer to every Postfix command or server program. The text gives the general context in
which each command or server program is used, and provides pointers to documents with
specific usage examples and background information.
Topics covered by this document:
● How Postfix receives mail

● How Postfix delivers mail
● Postfix behind the scenes
● Postfix support commands
How Postfix receives mail

When a message enters the Postfix mail system, the first stop on the inside is the incoming
queue. The figure below shows the main processes that are involved with new mail. Names
followed by a number are Postfix commands or server programs, while unnumbered names
inside shaded areas represent Postfix queues.
trivial-
rewrite(8)
-
Network smtpd(8) ^ |
>
| v
\
http://www.subneural.net/postfix-master/OVERVIEW.html (1 of 9)01/16/2005 15:46:27

- -
Network qmqpd(8) -> cleanup(8) incoming
> >
/
pickup(8) <- maildrop
^
|
- sendmail postdrop
Local ->
> (1) (1)
● Network mail enters Postfix via the smtpd(8) or qmqpd(8) servers. These servers
remove the SMTP or QMQP protocol encapsulation, enforce some sanity checks to
protect Postfix, and give the sender, recipients and message content to the cleanup(8)
server. The smtpd(8) server can be configured to block unwanted mail, as described in
the SMTPD_ACCESS_README document.
● Local submissions are received with the Postfix sendmail(1) compatibility command,
and are queued in the maildrop queue by the privileged postdrop(1) command. This
arrangement even works while the Postfix mail system is not running. The local pickup
(8) server picks up local submissions, enforces some sanity checks to protect Postfix,
and gives the sender, recipients and message content to the cleanup(8) server.
● Mail from internal sources is given directly to the cleanup(8) server. These sources are
not shown in the figure, and include: mail that is forwarded by the local(8) delivery
agent (see next section), messages that are returned to the sender by the bounce(8)
server (see second-next section), and postmaster notifications about problems with
Postfix.
● The cleanup(8) server implements the final processing stage before mail is queued. It
adds missing From: and other message headers, transforms addresses as described in the
ADDRESS_REWRITING_README document. Optionally, the cleanup(8) server can
be configured to do light-weight content inspection with regular expressions as
described in the BUILTIN_FILTER_README document. The cleanup(8) server places
the result as a single file into the incoming queue, and notifies the queue manager (see
next section) of the arrival of new mail.
● The trivial-rewrite(8) server rewrites addresses to the standard "user@fully.qualified.

domain" form, as described in the ADDRESS_REWRITING_README document.
Postfix currently does not implement a rewriting language, but a lot can be done via

table lookups and, if need be, regular expressions.
How Postfix delivers mail

Once a message has reached the incoming queue the next step is to deliver it. The figure shows
the main components of the Postfix mail delivery apparatus. Names followed by a number are
Postfix commands or server programs, while unnumbered names inside shaded areas represent
Postfix queues.
trivial- -
smtp(8) Network
rewrite >
(8) /
-
^ | - lmtp(8) Network
>
| v
/
- - - File,
incoming active qmgr(8) --- local(8)
> > > command
\
^ |
virtual -
| v - File
(8) >
deferred \
-
pipe(8) Command
>
● The queue manager (the qmgr(8) server process in the figure) is the heart of Postfix mail
delivery. It contacts the smtp(8), lmtp(8), local(8), virtual(8), pipe(8), discard(8) or error
(8) delivery agents, and sends a delivery request for one or more recipient addresses.
The discard(8) and error(8) delivery agents are special: they discard or bounce all mail,
they are not shown in the figure above.
The queue manager maintains a small active queue with the messages that it has opened
for delivery. The active queue acts as a limited window on potentially large incoming or
deferred queues. The limited active queue prevents the queue manager from running out
of memory under heavy load.
The queue manager maintains a separate deferred queue for mail that cannot be
delivered, so that a large mail backlog will not slow down normal queue accesses. The
queue manager's strategy for delayed mail delivery attempts is described in the

QSHAPE_README and TUNING_README documents.
● The trivial-rewrite(8) server resolves each recipient address according to its local and
remote address class, as defined in the ADDRESS_CLASS_README document.
Additional routing information can be specified with the optional transport(5) table. The
trivial-rewrite(8) server optionally queries the relocated(5) table for recipients whose
address has changed; mail for such recipients is returned to the sender with an
explanation.
● The smtp(8) client looks up a list of mail exchangers for the destination host, sorts the
list by preference, and tries each server in turn until it finds a server that responds. It
then encapsulates the sender, recipient and message content as required by the SMTP
protocol; this includes conversion of 8-bit MIME to 7-bit encoding.
● The lmtp(8) client speaks a protocol similar to SMTP that is optimized for delivery to
mailbox servers such as Cyrus. The advantage of this setup is that one Postfix machine
can feed multiple mailbox servers over LMTP. The opposite is true as well: one
mailbox server can be fed over LMTP by multiple Postfix machines. The
LMTP_README document gives examples of how to use the lmtp(8) client.
● The local(8) delivery agent understands UNIX-style mailboxes, qmail-compatible

maildir files, Sendmail-style system-wide aliases(5) databases, and Sendmail-style per-
user .forward files. Multiple local delivery agents can be run in parallel, but parallel
delivery to the same user is usually limited.
The local(8) delivery agent has hooks for alternative forms of local delivery: you can
configure it to deliver to mailbox files in user home directories, you can configure it to
delegate mailbox delivery to an external command such as procmail, or you can
delegate delivery to a different Postfix delivery agent.
● The virtual(8) delivery agent is a bare-bones delivery agent that delivers to UNIX-style
mailbox or qmail-style maildir files only. This delivery agent can deliver mail for
multiple domains, which makes it especially suitable for hosting lots of small domains
on a single machine. This is described in the VIRTUAL_README document.
● The pipe(8) mailer is the outbound interface to other mail processing systems (the
Postfix sendmail(1) command being the inbound interface). The interface is UNIX
compatible: it provides information on the command line and on the standard input
stream, and expects a process exit status code as defined in <sysexits.h>. Examples of
delivery via the pipe(8) mailer are in the MAILDROP_README and

UUCP_README documents.
Postfix behind the scenes

The previous sections gave an overview of how Postfix server processes send and receive mail.
These server processes rely on other server processes that do things behind the scenes. The text
below attempts to visualize each service in its own context. As before, names followed by a
number are Postfix commands or server programs, while unnumbered names inside shaded
areas represent Postfix queues.
● The resident master(8) server is the supervisor that keeps an eye on the well-being of the
Postfix mail system. It is typically started at system boot time with the "postfix start"
command, and keeps running until the system goes down. The master(8) server is
responsible for starting Postfix server processes to receive and deliver mail, and for
restarting servers that terminate prematurely because of some problem. The master(8)
server is also responsible for enforcing the server process count limits as specified in the
master.cf configuration file. The picture below gives the program hierarchy when
Postfix is started up. Only some of the mail handling daemon processes are shown.
postfix(1)
|
|
postfix-script
(1)
/ | \
/ | \
postsuper postlog
master(8)
(1) (1)
/ | \
/ | \
smtpd(8) qmgr(8) local(8)
● The anvil(8) server implements client connection and rate limiting for all smtpd(8)
servers. The TUNING_README document provides guidance for dealing with mis-
behaving SMTP clients. The anvil(8) service is not included with Postfix version 2.1 or
earlier.

- <-
Network smtpd(8) anvil(8)
> >
● The bounce(8), defer(8) and trace(8) servers each maintain their own queue directory
trees with per-message logfiles. This information is used to send delivery or non-
delivery notifications to the sender.
The trace(8) service implements support for the Postfix "sendmail -bv" and "sendmail -
v" commands which produce reports about how Postfix delivers mail, and is available
with Postfix version 2.1 and later. See DEBUG_README for examples.
qmgr(8)
cleanup Delivery
-> Postfix ->
(8) agents
queue
^ | |
| v v
(Non-) bounce(8) Queue id,
delivery <- defer(8) <- recipient,
notice trace(8) status
^ |
| v
Per-
message
logfiles
● The flush(8) servers maintain per-destination logs and implement both ETRN and
"sendmail -qRdestination", as described in the ETRN_README document. This moves
selected queue files from the deferred queue back to the incoming queue and requests
their delivery. The flush(8) service is available with Postfix version 1.0 and later.
incoming
^
deferred
^
|

smtpd(8) Delivery
sendmail(1) Deferred agents,
Destination -
- flush(8) <- destination, -
postqueue to flush > qmgr
queue id
(1) (8)
^ |
| v
Per-dest-
ination
logs
● The proxymap(8) servers provide read-only table lookup service to Postfix processes.
This overcomes chroot restrictions, and reduces the number of open lookup tables by
sharing one open table among multiple processes.
● The scache(8) server maintains the connection cache for the Postfix smtp(8) client.
When connection caching is enabled for selected destinations, the smtp(8) client does
not disconnect immediately after a mail transaction, but gives the connection to the
connection cache server. The smtp(8) client continues with some other mail delivery
request. Meanwhile, the connection cache server keeps the connection open for a
limited amount of time. During that time, any smtp(8) process can ask the scache(8)
server for that cached connection and use it for mail delivery.
smtp - scache - smtp

(8) > (8) > (8)
● The showq(8) servers list the Postfix queue status. This is the queue listing service that
does the work for the mailq(1) and postqueue(1) commands.
mailq(1)
post- showq Postfix
Output <- <- <-
queue (8) queue
(1)
● The spawn(8) servers run non-Postfix commands on request, with the client connected
via socket or FIFO to the command's standard input, output and error streams. You can
find examples of its use in the SMTPD_POLICY_README document.
● The verify(8) server verifies that a sender or recipient address is deliverable before the
smtpd(8) server accepts it. The verify(8) server injects probe messages into the Postfix

queue and processes status updates from delivery agents and/or queue manager. This
process is described in the ADDRESS_VERIFICATION_README document. The
verify(8) service is available with Postfix version 2.1 and later.
qmgr(8)
- smtpd <- verify - cleanup - Delivery
Network -> Postfix
> (8) > (8) > (8) > agents
queue
\ | /
\ <- <- v /
Postfix support commands

The Postfix architecture overview ends with a summary of command-line utilities for day-to-
day use of the Postfix mail system. Besides the Sendmail-compatible sendmail(1), mailq(1),
and newaliases(1) commands, the Postfix system comes with it own collection of command-
line utilities. For consistency, these are all named postsomething.
● The postfix(1) command controls the operation of the mail system. It is the interface for
starting, stopping, and restarting the mail system, as well as for some other
administrative operations. This command is reserved to the super-user.
● The postalias(1) command maintains Postfix aliases(5) type databases. This is the
program that does the work for the newaliases(1) command.
● The postcat(1) command displays the contents of Postfix queue files. This is a limited,
preliminary utility. This program is likely to be superseded by something more powerful
that can also edit Postfix queue files.
● The postconf(1) command displays or updates Postfix main.cf parameters and displays
system dependent information about the supported file locking methods, and the
supported types of lookup tables.
● The postdrop(1) command is the mail posting utility that is run by the Postfix sendmail
(1) command in order to deposit mail into the maildrop queue directory.
● The postkick(1) command makes some Postfix internal communication channels

available for use in, for example, shell scripts.

● The postlock(1) command provides Postfix-compatible mailbox locking for use in, for
example, shell scripts.
● The postlog(1) command provides Postfix-compatible logging for shell scripts.
● The postmap(1) command maintains Postfix lookup tables such as canonical(5), virtual
(5) and others. It is a cousin of the UNIX makemap command.
● The postqueue(1) command is the privileged command that is run by Postfix sendmail
(1) and mailq(1) in order to flush or list the mail queue.
● The postsuper(1) command maintains the Postfix queue. It removes old temporary files,
and moves queue files into the right directory after a change in the hashing depth of
queue directories. This command is run at mail system startup time and when Postfix is
restarted.

Postfix manual - qmqpd(8)
QMQPD(8) QMQPD
(8)
NAME
qmqpd - Postfix QMQP server
SYNOPSIS
qmqpd [generic Postfix daemon options]
DESCRIPTION
The Postfix QMQP server receives one message per
connec-
tion. Each message is piped through the cleanup(8)
dae-
mon, and is placed into the incoming queue as one
single
queue file. The program expects to be run from the
mas-
The QMQP server implements one access policy: only

explic-
itly authorized client hosts are allowed to use the
ser-
vice.
SECURITY
The QMQP server is moderately security-sensitive. It
talks
to QMQP clients and to DNS servers on the network.
The
QMQP server can be run chrooted at fixed low privilege.
DIAGNOSTICS
BUGS
The QMQP protocol provides only one server reply per
mes-
sage delivery. It is therefore not possible to
reject
http://www.subneural.net/postfix-master/qmqpd.8.html (1 of 6)01/16/2005 15:46:28

individual recipients.
The QMQP protocol requires the server to receive

the
entire message before replying. If a message is
malformed,
or if any netstring component is longer than
acceptable,
Postfix replies immediately and closes the connection.
It
is left up to the client to handle the situation.
as
qmqpd(8) processes run for only a limited amount of
time.

See
CONTENT INSPECTION CONTROLS

filters
in
content filtering, or address rewriting.

pieces
lines
are reconstructed.

hopcount_limit (50)
headers
including
qmqpd_timeout (300s)
information
over the network.

a
the
hostname
verbose
specified
soft_bounce (no)
otherwise
TARPIT CONTROLS
qmqpd_error_delay (1s)
How long the QMQP server will pause before
sending

a negative reply to the client.
and
to
a
ipc_timeout (3600s)
information
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a
pro-
cess.
daemon
process.

qmqpd_authorized_clients (empty)
What clients are allowed to connect to the
QMQP
server port.

direc-
tory.
pro-
"smtpd"
delimiter
line
SEE ALSO
http://cr.yp.to/proto/qmqp.html, QMQP protocol
README FILES
QMQP_README, Postfix ezmlm-idx howto.
LICENSE
this
software.

HISTORY
The qmqpd service was introduced with Postfix version
1.1.
AUTHOR(S)
Wietse Venema
P.O. Box 704
QMQPD
(8)

Postfix qmail and ezmlm support
Postfix qmail and ezmlm

support
This document will be made available via http://www.postfix.org/.
http://www.subneural.net/postfix-master/QMQP_README.html01/16/2005 15:46:28
Postfix SMTP relay and access control
Postfix SMTP relay and

access control
Introduction
The Postfix SMTP server receives mail from the network and is exposed to the big bad world
of junk email and viruses. This document introduces the built-in and external methods that
control what SMTP mail Postfix will accept, what mistakes to avoid, and how to test your
configuration.
● Relay control, junk mail control, and per-user policies

● Restrictions that apply to all SMTP mail
● Getting selective with SMTP access restriction lists
● Delayed evaluation of SMTP access restriction lists
● Dangerous use of smtpd_recipient_restrictions
● SMTP access rule testing
Relay control, junk mail control, and per-user policies

In a distant past, the Internet was a friendly environment. Mail servers happily forwarded mail
on behalf of anyone towards any destination. On today's Internet, spammers abuse servers that
forward mail from arbitrary systems, and abused systems end up on anti-spammer blacklists.
See, for example, the information on http://www.mail-abuse.org/ and other websites.
By default, Postfix has a moderately restrictive approach to mail relaying. Postfix forwards
mail only from clients in trusted networks, or to domains that are configured as authorized
relay destinations. For a description of the default policy, see the smtpd_recipient_restrictions
parameter in the postconf(5) manual page, and the information that is referenced from there.
http://www.subneural.net/postfix-master/SMTPD_ACCESS_README.html (1 of 7)01/16/2005 15:46:29

Most of the Postfix SMTP server access controls are targeted at stopping junk email.
● Protocol oriented: some SMTP server access controls block mail by being very strict
with respect to the SMTP protocol; these catch poorly implemented and/or poorly
configured junk email software, as well as email worms that come with their own non-
standard SMTP client implementations. Protocol-oriented access controls become less
useful over time as spammers and worm writers learn to read RFC documents.
● Blacklist oriented: some SMTP server access controls query blacklists with known to be
bad sites such as open mail relays, open web proxies, and home computers that have
been compromised and that are under remote control by criminals. The effectiveness of
these blacklists depends on how complete and how up to date they are.
● Threshold oriented: some SMTP server access controls attempt to raise the bar by either
making the client do more work (greylisting) or by asking for a second opinion (SPF
and sender/recipient address verification). The greylisting and SPF policies are
implemented externally, and are the subject of the SMTPD_POLICY_README
document. Sender/recipient address verification is the subject of the
ADDRESS_VERIFICATION_README document.
Unfortunately, all junk mail controls have the possibility of falsely rejecting legitimate mail.
This can be a problem for sites with many different types of users. For some users it is
unacceptable when any junk email slips through, while for other users the world comes to an
end when a single legitimate email message is blocked. Because there is no single policy that is
"right" for all users, Postfix supports different SMTP access restrictions for different users.
This is described in the RESTRICTION_CLASS_README document.
Restrictions that apply to all SMTP mail

Besides the restrictions that can be made configurable per client or per user as described in the
next section, Postfix implements a few restrictions that apply to all SMTP mail.
● The built-in header_checks and body_checks content restrictions, as described in the

BUILTIN_FILTER_README document. This happens while Postfix receives mail,
before it is stored in the incoming queue.
● The external before-queue content restrictions, as described in the

SMTPD_PROXY_README document. This happens while Postfix receives mail,
before it is stored in the incoming queue.

● Requiring that the client sends the HELO or EHLO command before sending the MAIL
FROM or ETRN command. This may cause problems with home-grown applications
that send mail. For this reason, the requirement is disabled by default
("smtpd_helo_required = no").
● Disallowing illegal syntax in MAIL FROM or RCPT TO commands. This may cause
problems with home-grown applications that send mail, and with ancient PC mail
clients. For this reason, the requirement is disabled by default ("strict_rfc821_envelopes
= no").
❍ Disallowing RFC 822 address syntax (example: "MAIL FROM: the dude
<dude@example.com>").
❍ Disallowing addresses that are not enclosed with <> (example: "MAIL FROM:
dude@example.com").
● Rejecting mail from a non-existent sender address. This form of egress filtering helps to
slow down worms and other malware, but may cause problems with home-grown
software that sends out mail software with an unreplyable address. For this reason the
requirement is disabled by default ("smtpd_reject_unlisted_sender = no").
● Rejecting mail for a non-existent recipient address. This form of ingress filtering helps
to keep the mail queue free of undeliverable MAILER-DAEMON messages. This
requirement is enabled by default ("smtpd_reject_unlisted_recipient = yes").
Getting selective with SMTP access restriction lists

Postfix allows you to specify lists of access restrictions for each stage of the SMTP
conversation. Individual restrictions are described in the postconf(5) manual page.
Examples of simple restriction lists are:
# Allow connections from trusted networks only.
smtpd_client_restrictions = permit_mynetworks, reject
# Don't talk to mail systems that don't know their own

hostname.
smtpd_helo_restrictions = reject_unknown_hostname

# Don't accept mail from domains that don't exist.

smtpd_sender_restrictions = reject_unknown_sender_domain
# Whitelisting: local clients may specify any destination.

Others may not.
smtpd_recipient_restrictions = permit_mynetworks,
Each restriction list is evaluated from left to right until some restriction produces a result of
PERMIT, REJECT or DEFER (try again later). The end of the list is equivalent to a PERMIT
result. By placing a PERMIT restriction before a REJECT restriction you can make exceptions
for specific clients or users. This is called whitelisting; the last example above allows mail
from local networks but otherwise rejects mail to arbitrary destinations.
The table below summarizes the purpose of each SMTP access restriction list. All lists use the
exact same syntax; they differ only in the time of evaluation and in the effect of a REJECT or
DEFER result.
Effect of REJECT or DEFER

Restriction list name Status
result
smtpd_client_restrictions Optional Reject all client commands
smtpd_helo_restrictions Optional Reject HELO/EHLO information
smtpd_sender_restrictions Optional Reject MAIL FROM information
smtpd_recipient_restrictions Required Reject RCPT TO information
smtpd_data_restrictions Optional Reject DATA command
smtpd_end_of_data_restrictions Optional Reject END-OF-DATA command
smtpd_etrn_restrictions Optional Reject ETRN command
Delayed evaluation of SMTP access restriction lists

Early Postfix versions evaluated SMTP access restrictions lists as early as possible. The client
restriction list was evaluated before Postfix sent the "220 $myhostname..." greeting banner to
the SMTP client, the helo restriction list was evaluated before Postfix replied to the HELO
(EHLO) command, the sender restriction list was evaluated before Postfix replied to the MAIL
FROM command, and so on. This approach turned out to be difficult to use.
Current Postfix versions postpone the evaluation of client, helo and sender restriction lists until

the RCPT TO or ETRN command. This behavior is controlled by the smtpd_delay_reject

parameter. Restriction lists are still evaluated in the proper order of (client, helo, etrn) or
(client, helo, sender, recipient, data, or end-of-data) restrictions. When a restriction list
(example: client) evaluates to REJECT or DEFER the other restriction lists (example: helo,
sender, etc.) are skipped.
Around the time that smtpd_delay_reject was introduced, Postfix was also changed to support
mixed restriction lists that combine information about the client, helo, sender and recipient or
etrn command.
Benefits of delayed restriction evaluation, and of restriction mixing:
● Some SMTP clients do not expect a negative reply early in the SMTP session. When the
bad news is postponed until the RCPT TO reply, the client goes away as it is supposed
to, instead of hanging around until a timeout happens, or worse, going into an endless
connect-reject-connect loop.
● Postfix can log more useful information. For example, when Postfix rejects a client
name or address and delays the action until the RCPT TO command, it can log the
sender and the recipient address. This is more useful than logging only the client
hostname and IP address and not knowing whose mail was being blocked.
● Mixing is needed for complex whitelisting policies. For example, in order to reject local
sender addresses in mail from non-local clients, you need to be able to mix restrictions
on client information with restrictions on sender information in the same restriction list.
Without this ability, many per-user access restrictions would be impossible to express.
Dangerous use of smtpd_recipient_restrictions

By now the reader may wonder why we need smtpd client, helo or sender restrictions, when
their evaluation is postponed until the RCPT TO or ETRN command. Some people recommend
placing ALL the access restrictions in the smtpd_recipient_restrictions list. Unfortunately, this
can result in too permissive access. How is this possible?
The purpose of the smtpd_recipient_restrictions feature is to control how Postfix replies to the
RCPT TO command. If the restriction list evaluates to REJECT or DEFER, the recipient
address is rejected; no surprises here. If the result is PERMIT, then the recipient address is
accepted. And this is where surprises can happen.
Here is an example that shows when a PERMIT result can result in too much access

permission:
2 smtpd_recipient_restrictions =
3 permit_mynetworks
4 check_helo_access hash:/etc/postfix/helo_access
5 reject_unknown_hostname
6 reject_unauth_destination
7
8 /etc/postfix/helo_access:
9 localhost.localdomain PERMIT
Line 5 rejects mail from hosts that don't specify a proper hostname in the HELO command.
Lines 4 and 9 make an exception to allow mail from some machine that announces itself with
"HELO localhost.localdomain".
The problem with this configuration is that smtpd_recipient_restrictions evaluates to PERMIT

for EVERY host that announces itself as "localhost.localdomain", making Postfix an open relay
for all such hosts.
In order to avoid surprises like these with smtpd_recipient_restrictions, you should place non-
recipient restrictions AFTER the reject_unauth_destination restriction, not before. In the above
example, the HELO based restrictions should be placed AFTER reject_unauth_destination, or
better, the HELO based restrictions should be placed under smtpd_helo_restrictions where they
can do no harm.
SMTP access rule testing

Postfix has several features that aid in SMTP access rule testing:
soft_bounce
This is a safety net that changes SMTP server REJECT actions into DEFER (try again
later) actions. This keeps mail queued that would otherwise be returned to the sender.
Specify "soft_bounce = yes" in the main.cf file to prevent the Postfix SMTP server from
rejecting mail permanently, by changing all 5xx SMTP reply codes into 4xx.
warn_if_reject

This is a different safety net that changes SMTP server REJECT actions into warnings.
Instead of rejecting a command, Postfix logs what it would reject. Specify
"warn_if_reject" in an SMTP access restriction list, before the restriction that you want
to test without actually rejecting mail.
XCLIENT
With this Postfix 2.1 feature, authorized SMTP clients can impersonate other systems,
so that you can do realistic SMTP access rule tests. Examples of how to impersonate
other systems for access rule testing are given at the end of the XCLIENT_README
document.

Postfix SMTP Access Policy Delegation
Postfix SMTP Access

Policy Delegation
Purpose of Postfix SMTP access policy delegation

The Postfix SMTP server has a number of built-in mechanisms to block or accept mail at
specific SMTP protocol stages. As of version 2.1, Postfix can delegate policy decisions to an
external server that runs outside Postfix.
With this policy delegation mechanism, a simple greylist policy can be implemented with only
a dozen lines of Perl, as is shown at the end of this document. Another example of policy
delegation is the SPF policy server by Meng Wong at http://spf.pobox.com/. Examples of both
policies can be found in the Postfix source code, in the directory examples/smtpd-policy.
Policy delegation is now the preferred method for adding policies to Postfix. It's much easier to
develop a new feature in few lines of Perl, than trying to do the same in C code. The difference
in performance will be unnoticeable except in the most demanding environments.
● Policy protocol description

● Policy client/server configuration
● Example: greylist policy server
● Greylisting mail from frequently forged domains
● Greylisting all your mail
● Routine greylist maintenance
● Example Perl greylist server
Protocol description
http://www.subneural.net/postfix-master/SMTPD_POLICY_README.html (1 of 10)01/16/2005 15:46:29

The Postfix policy delegation protocol is really simple. The client request is a sequence of
name=value attributes separated by newline, and is terminated by an empty line. The server
reply is one name=value attribute and it, too, is terminated by an empty line.
Here is an example of all the attributes that the Postfix SMTP server sends in a delegated
SMTPD access policy request:
request=smtpd_access_policy
protocol_state=RCPT
protocol_name=SMTP
helo_name=some.domain.tld
queue_id=8045F2AB23
sender=foo@bar.tld
recipient=bar@foo.tld
client_address=1.2.3.4
client_name=another.domain.tld
instance=123.456.7
sasl_method=plain
sasl_username=you
sasl_sender=
size=12345
[empty line]
Notes:
● The "request" attribute is required. In this example the request type is

"smtpd_access_policy".
● The order of the attributes does not matter. The policy server should ignore any
attributes that it does not care about.
● When the same attribute name is sent more than once, the server may keep the first
value or the last attribute value.
● When an attribute value is unavailable, the client either does not send the attribute, or
sends the attribute with an empty value ("name=").
● An attribute name must not contain "=", null or newline, and an attribute value must not
contain null or newline.
● The "instance" attribute value can be used to correlate different requests regarding the

same message delivery.
● The "size" attribute value specifies the message size that the client specified in the
MAIL FROM command (zero if none was specified). With Postfix 2.2 and later, it
specifies the actual message size when the client sends the END-OF-DATA command.
The following is specific to SMTPD delegated policy requests:
● Protocol names are ESMTP or SMTP.
● Protocol states are CONNECT, EHLO, HELO, MAIL, RCPT, DATA, END-OF-
DATA, VRFY or ETRN; these are the SMTP protocol states where the Postfix SMTP
server makes an OK/REJECT/HOLD/etc. decision.
● The SASL attributes are sent only when SASL support is built into Postfix.
The policy server replies with any action that is allowed in a Postfix SMTPD access(5) table.
Example:
action=defer_if_permit Service temporarily unavailable

[empty line]
This causes the Postfix SMTP server to reject the request with a 450 temporary error code and
with text "Service temporarily unavailable", if the Postfix SMTP server finds no reason to
reject the request permanently.
In case of trouble the policy server must not send a reply. Instead the server must log a warning
and disconnect. Postfix will retry the request at some later time.
Policy client/server configuration

The Postfix delegated policy client can connect to a TCP socket or to a UNIX-domain socket.
Examples:
inet:127.0.0.1:9998
unix:/some/where/policy
unix:private/policy
The first example specifies that the policy server listens on a TCP socket at 127.0.0.1 port
9998. The second example specifies an absolute pathname of a UNIX-domain socket. The third

example specifies a pathname relative to the Postfix queue directory; use this for policy servers
that are spawned by the Postfix master daemon.
To create a policy service that listens on a UNIX-domain socket called "policy", and that runs
under control of the Postfix spawn(8) daemon, you would use something like this:
1 /etc/postfix/master.cf:
2 policy unix - n n -
- spawn
3 user=nobody argv=/some/where/policy-server
4
7 ...
9 check_policy_service unix:private/policy
10 ...
11 policy_time_limit = 3600
NOTES:
● Lines 2, 11: the Postfix spawn(8) daemon by default kills its child process after 1000
seconds. This is too short for a policy daemon that may run for as long as an SMTP
client is connected to an SMTP server process. The default time limit is overruled in
main.cf with an explicit "policy_time_limit" setting. The name of the parameter is the
name of the master.cf entry ("policy") concatenated with the "_time_limit" suffix.
● Lines 8, 9: always specify "check_policy_service" AFTER "reject_unauth_destination"

or else your system could become an open relay.
● Solaris UNIX-domain sockets do not work reliably. Use TCP sockets instead:
2 127.0.0.1:9998 inet n n n
- - spawn
3 user=nobody argv=/some/where/policy-server
4
7 ...

9 check_policy_service inet:127.0.0.1:9998
10 ...
11 127.0.0.1:9998_time_limit = 3600
Other configuration parameters that control the client side of the policy delegation protocol:
● smtpd_policy_service_max_idle (default: 300s): The amount of time before the Postfix

SMTP server closes an unused policy client connection.
● smtpd_policy_service_max_ttl (default: 1000s): The amount of time before the Postfix

SMTP server closes an active policy client connection.
● smtpd_policy_service_timeout (default: 100s): The time limit to connect to, send to or

receive from a policy server.
Example: greylist policy server

Greylisting is a defense against junk email that is described at http://www.greylisting.org/. The
idea was discussed on the postfix-users mailing list one year before it was popularized.
The file examples/smtpd-policy/greylist.pl in the Postfix source tree implements a simplified

greylist policy server. This server stores a time stamp for every (client, sender, recipient) triple.
By default, mail is not accepted until a time stamp is more than 60 seconds old. This stops junk
mail with randomly selected sender addresses, and mail that is sent through randomly selected
open proxies. It also stops junk mail from spammers that change their IP address frequently.
Copy examples/smtpd-policy/greylist.pl to /usr/libexec/postfix or whatever location is

appropriate for your system.
In the greylist.pl Perl script you need to specify the location of the greylist database file, and
how long mail will be delayed before it is accepted. The default settings are:
$database_name="/var/mta/greylist.db";
$greylist_delay=60;
The /var/mta directory (or whatever you choose) should be writable by "nobody", or by
whatever username you configure below in master.cf for the policy service.
Example:

# mkdir /var/mta
# chown nobody /var/mta
Note: DO NOT create the greylist database in a world-writable directory such as /tmp or /var/
tmp, and DO NOT create the greylist database in a file system that may run out of space.
Postfix can survive "out of space" conditions with the mail queue and with the mailbox store,
but it cannot survive a corrupted greylist database. If the file becomes corrupted you may not
be able to receive mail at all until you delete the file by hand.
The greylist.pl Perl script can be run under control by the Postfix master daemon. For example,
to run the script as user "nobody", using a UNIX-domain socket that is accessible by Postfix
processes only:
2 policy unix - n n -
- spawn
3 user=nobody argv=/usr/bin/perl /usr/libexec/
postfix/greylist.pl
4
6 policy_time_limit = 3600
Notes:
● Line 3: Specify "greylist.pl -v" for verbose logging of each request and reply.
● Lines 2, 6: the Postfix spawn(8) daemon by default kills its child process after 1000
seconds. This is too short for a policy daemon that may run for as long as an SMTP
client is connected to an SMTP server process. The default time limit is overruled in
main.cf with an explicit "policy_time_limit" setting. The name of the parameter is the
name of the master.cf entry ("policy") concatenated with the "_time_limit" suffix.
On Solaris you must use inet: style sockets instead of unix: style, as detailed in the "Policy
client/server configuration" section above.
2 127.0.0.1:9998 inet n n n
- - spawn
3 user=nobody argv=/usr/bin/perl /usr/libexec/
postfix/greylist.pl
4

6 127.0.0.1:9998_time_limit = 3600
To invoke this service you would specify "check_policy_service inet:127.0.0.1:9998".
Greylisting mail from frequently forged domains

It is relatively safe to turn on greylisting for specific domains that often appear in forged email.
A list of frequently forged MAIL FROM domains can be found at http://www.monkeys.com/
anti-spam/filtering/sender-domain-validate.in.
3 reject_unlisted_recipient
4 ...
6 check_sender_access hash:/etc/postfix/
sender_access
7 ...
8 restriction_classes = greylist
9 greylist = check_policy_service unix:private/
policy
10
11 /etc/postfix/sender_access:
12 aol.com greylist
13 hotmail.com greylist
14 bigfoot.com greylist
15 ... etcetera ...
NOTES:
● Line 9: On Solaris you must use inet: style sockets instead of unix: style, as detailed in
the "Example: greylist policy server" section above.
● Line 6: Be sure to specify "check_sender_access" AFTER "reject_unauth_destination"

or else your system could become an open mail relay.
● Line 3: With Postfix 2.0 snapshot releases, "reject_unlisted_recipient" is called

"check_recipient_maps". Postfix 2.1 understands both forms.

● Line 3: The greylist database gets polluted quickly with bogus addresses. It helps if you
protect greylist lookups with other restrictions that reject unknown senders and/or
recipients.
Greylisting all your mail

If you turn on greylisting for all mail you will almost certainly want to make exceptions for
mailing lists that use one-time sender addresses, because such mailing lists can pollute your
greylist database relatively quickly.
3 reject_unlisted_recipient
4 ...
6 check_sender_access hash:/etc/postfix/
sender_access
7 check_policy_service unix:private/policy
8 ...
9
10 /etc/postfix/sender_access:
11 securityfocus.com OK
12 ...
NOTES:
● Line 7: On Solaris you must use inet: style sockets instead of unix: style, as detailed in
the "Example: greylist policy server" section above.
● Lines 6-7: Be sure to specify check_sender_access and check_policy_service AFTER

reject_unauth_destination or else your system could become an open mail relay.
● Line 3: The greylist database gets polluted quickly with bogus addresses. It helps if you
precede greylist lookups with restrictions that reject unknown senders and/or recipients.
Routine greylist maintenance

The greylist database grows over time, because the greylist server never removes database
entries. If left unattended, the greylist database will eventually run your file system out of
space.

When the status file size exceeds some threshold you can simply rename or remove the file
without adverse effects; Postfix automatically creates a new file. In the worst case, new mail
will be delayed by an hour or so. To lessen the impact, rename or remove the file in the middle
of the night at the beginning of a weekend.
Example Perl greylist server

This is the Perl subroutine that implements the example greylist policy. It is part of a general
purpose sample policy server that is distributed with the Postfix source as examples/smtpd-
policy/greylist.pl.
#
# greylist status database and greylist time interval. DO NOT
create the
# greylist status database in a world-writable directory such
as /tmp
# or /var/tmp. DO NOT create the greylist database in a file
system
# that can run out of space.
#
$database_name="/var/mta/greylist.db";
$greylist_delay=60;
#
# Demo SMTPD access policy routine. The result is an action
just like
# it would be specified on the right-hand side of a Postfix
access
# table. Request attributes are available via the %attr hash.
#
sub smtpd_access_policy {
my($key, $time_stamp, $now);
# Open the database on the fly.

open_database() unless $database_obj;
# Lookup the time stamp for this client/sender/recipient.

$key =
lc $attr{"client_address"}."/".$attr{"sender"}."/".$attr
{"recipient"};
$time_stamp = read_database($key);

$now = time();
# If new request, add this client/sender/recipient to the

database.
if ($time_stamp == 0) {
$time_stamp = $now;
update_database($key, $time_stamp);
}
# The result can be any action that is allowed in a Postfix

access(5) map.
#
# To label the mail, return ``PREPEND headername:
headertext''
#
# In case of success, return ``DUNNO'' instead of `ÒK'',
so that the
# check_policy_service restriction can be followed by other
restrictions.
#
# In case of failure, return ``DEFER_IF_PERMIT optional
text...'',
# so that mail can still be blocked by other access
restrictions.
#
syslog $syslog_priority, "request age %d", $now -
$time_stamp if $verbose;
if ($now - $time_stamp > $greylist_delay) {
return "dunno";
} else {
return "defer_if_permit Service temporarily
unavailable";
}
}

Postfix After-Queue Content Filter
Postfix After-Queue Content

Filter
Introduction
This document requires Postfix version 2.1 or later.
Normally, Postfix receives mail, stores it in the mail queue and then delivers it. With the external content
filter described here, mail is filtered AFTER it is queued. This approach decouples mail receiving
processes from mail filtering processes, and gives you maximal control over how many filtering processes
you are willing to run in parallel.
The after-queue content filter is meant to be used as follows:
Network or
Network or - Postfix - Content - Postfix -
local
local users > queue > filter > queue >
mailbox
This document describes implementations that use a single Postfix instance for everything: receiving,
filtering and delivering mail. Applications that use two separate Postfix instances will be covered by a
later version of this document.
The after-queue content filter is not to be confused with the approach that is described in the
SMTPD_PROXY_README document, where incoming SMTP mail is filtered BEFORE it is stored into
the Postfix queue.
This document describes two approaches to content filter all email, as well as several options to filter mail
selectively:
● Principles of operation
● Simple content filter
❍ Simple content filter example
❍ Simple content filter performance
❍ Simple content filter limitations
❍ Turning off the simple content filter
http://www.subneural.net/postfix-master/FILTER_README.html (1 of 12)01/16/2005 15:46:30

● Advanced content filter

❍ Advanced content filter example
❍ Advanced content filter performance
❍ Turning off the advanced content filter
● Selective content filtering

❍ Filtering mail from outside users only
❍ Different filters for different domains
❍ FILTER actions in access or header/body tables
Principles of operation
An external content filter receives unfiltered mail from Postfix (as described further below) and does one
of the following:
1. Re-inject the mail back into Postfix, perhaps after changing content and/or destination.
2. Reject the mail (by sending a suitable status code back to Postfix). Postfix will return the mail to
the sender.
NOTE: in this time of mail worms and forged spam, it is a VERY BAD IDEA to send viruses back to the
sender address, because the sender address is almost certainly not the originator. It is better to discard
known viruses, and to quarantine material that is suspect so that a human can decide what to do with it.
Simple content filter example

The first example is simple to set up. Postfix receives unfiltered mail from the network with the smtpd(8)
server, and delivers unfiltered mail to a content filter with the Postfix pipe(8) delivery agent. The content
filter injects filtered mail back into Postfix with the Postfix sendmail(1) command, so that Postfix can
deliver it to the final destination.
This means that mail submitted via the Postfix sendmail(1) command cannot be content filtered.
In the figure below, names followed by a number represent Postfix commands or daemon programs. See
the OVERVIEW document for an introduction to the Postfix architecture.
Unfiltered -> smtpd(8)

qmgr(8) local(8) -> Filtered
-> Filtered
pickup >- cleanup(8) -> Postfix -< smtp(8)
(8) queue pipe(8)
^ |
| v

Postfix Postfix
maildrop Content
<- postdrop <- sendmail <-
queue filter
(1) (1)
The content filter can be a simple shell script like this:
1 #!/bin/sh
2
3 # Simple shell-based filter. It is meant to be invoked as
follows:
4 # /path/to/script -f sender recipients...
5
6 # Localize these.
7 INSPECT_DIR=/var/spool/filter
8 SENDMAIL="/usr/sbin/sendmail -i"
9
10 # Exit codes from <sysexits.h>
11 EX_TEMPFAIL=75
12 EX_UNAVAILABLE=69
13
14 # Clean up when done or when aborting.
15 trap "rm -f in.$$" 0 1 2 3 15
16
17 # Start processing.
18 cd $INSPECT_DIR || {
19 echo $INSPECT_DIR does not exist; exit $EX_TEMPFAIL; }
20
21 cat >in.$$ || {
22 echo Cannot save mail to file; exit $EX_TEMPFAIL; }
23
24 # Specify your content filter here.
25 # filter <in.$$ || {
26 # echo Message content rejected; exit $EX_UNAVAILABLE; }
27
28 $SENDMAIL "$@" <in.$$
29
30 exit $?
Notes:
● Line 21: The idea is to first capture the message to file and then run the content through a third-
party content filter program.
● Line 22: If the mail cannot be captured to file, mail delivery is deferred by terminating with exit
status 75 (EX_TEMPFAIL). Postfix places the message in the deferred mail queue and tries again
later.

● Line 25: You will need to specify a real content filter program here that receives the content on
standard input.
● Line 26: If the content filter program finds a problem, the mail is bounced by terminating with exit
status 69 (EX_UNAVAILABLE). Postfix will return the message to the sender as undeliverable.
● Note: in this time of mail worms and spam, it is a BAD IDEA to send known viruses or spam back
to the sender, because that address is likely to be forged. It is safer to discard known to be bad
content and to quarantine suspicious content so that it can be inspected by a human being.
● Line 28: If the content is OK, it is given as input to the Postfix sendmail command, and the exit
status of the filter command is whatever exit status the Postfix sendmail command produces.
Postfix will deliver the message as usual.
● Line 30: Postfix returns the exit status of the Postfix sendmail command.
I suggest that you first run this script by hand until you are satisfied with the results. Run it with a real
message (headers+body) as input:
% /path/to/script -f sender recipient... <message-file
Once you're satisfied with the content filtering script:
● Create a dedicated local user account called "filter". This user handles all potentially dangerous
mail content - that is why it should be a separate account. Do not use "nobody", and most certainly
do not use "root" or "postfix".
● Create a directory /var/spool/filter that is accessible only to the "filter" user. This is where the
content filtering script is supposed to store its temporary files.
● Configure Postfix to deliver mail to the content filter with the pipe(8) delivery agent.
# =============================================================
# service type private unpriv chroot wakeup maxproc command
# (yes) (yes) (yes) (never) (100)
# =============================================================
filter unix - n n - 10 pipe
flags=Rq user=filter argv=/path/to/script -f ${sender} --
${recipient}
This runs up to 10 content filters in parallel. Instead of a limit of 10 concurrent processes, use
whatever process limit is feasible for your machine. Content inspection software can gobble up a
lot of system resources, so you don't want to have too much of it running at the same time.

● To turn on content filtering for mail arriving via SMTP only, append "-o content_filter=filter:
dummy" to the master.cf entry that defines the Postfix SMTP server:
# =============================================================
# service type private unpriv chroot wakeup maxproc command
# =============================================================
smtp inet ...other stuff here, do not change... smtpd
-o content_filter=filter:dummy
The "content_filter" line causes Postfix to add one content filter request record to each incoming
mail message, with content "filter:dummy". This record overrides the normal mail routing and
causes mail to be given to the content filter instead.
The content_filter configuration parameter accepts the same syntax as the right-hand side in a
Postfix transport table.
● Execute "postfix reload" to complete the change.
Simple content filter performance

With the shell script as shown above you will lose a factor of four in Postfix performance for transit mail
that arrives and leaves via SMTP. You will lose another factor in transit performance for each additional
temporary file that is created and deleted in the process of content filtering. The performance impact is
less for mail that is submitted or delivered locally, because such deliveries are already slower than SMTP
transit mail.
Simple content filter limitations

The problem with content filters like the one above is that they are not very robust. The reason is that the
software does not talk a well-defined protocol with Postfix. If the filter shell script aborts because the shell
runs into some memory allocation problem, the script will not produce a nice exit status as defined in the
file /usr/include/sysexits.h. Instead of going to the deferred queue, mail will bounce. The same lack of
robustness can happen when the content filtering software itself runs into a resource problem.
The simple content filter method is not suitable for content filter actions that are invoked via
header_checks or body_checks patterns. These patterns will be applied again after mail is re-injected with
the Postfix sendmail command, resulting in a mail filtering loop. The advanced content filtering method
(see below) makes it possible to turn off header_checks or body_checks patterns for filtered mail.
Turning off the simple content filter

To turn off "simple" content filtering:
● Edit the master.cf file, remove the "-o content_filter=filter:dummy" text from the entry that defines
the Postfix SMTP server.
● Execute "postsuper -r ALL" to remove content filter information from existing queue files.
● Execute another "postfix reload".
Advanced content filter example

The second example is more complex, but can give better performance, and is less likely to bounce mail
when the machine runs into some resource problem. This content filter receives unfiltered mail with
SMTP on localhost port 10025, and sends filtered mail back into Postfix with SMTP on localhost port
10026.
For non-SMTP capable content filtering software, Bennett Todd's SMTP proxy implements a nice PERL/
SMTP content filtering framework. See: http://bent.latency.net/smtpprox/.
In the figure below, names followed by a number represent Postfix commands or daemon programs. See
the OVERVIEW document for an introduction to the Postfix architecture.
-> smtpd(8) qmgr(8)

smtp(8) ->
Unfiltered cleanup Filtered
- -
pickup >- Postfix local
- (8) > < -
Unfiltered queue Filtered
> (8) (8) >
^ |
| v
smtpd(8)
smtp(8)
10026
^ |
| v
content filter 10025
The example given here filters all mail, including mail that arrives via SMTP and mail that is locally
submitted via the Postfix sendmail command. See examples near the end of this document for how to
exclude local users from filtering, or how to configure a destination dependent content filter.
You can expect to lose about a factor of two in Postfix performance for mail that arrives and leaves via
SMTP, provided that the content filter creates no temporary files. Each temporary file created by the
content filter adds another factor to the performance loss.
Advanced content filter: requesting that all mail is filtered

To enable the advanced content filter method for all mail, specify in main.cf:
content_filter = scan:localhost:10025
● The "content_filter" line causes Postfix to add one content filter request record to each incoming
mail message, with content "scan:localhost:10025". The content filter request records are added by
the smtpd(8) and pickup(8) servers (and qmqpd(8) if you decide to enable this service).
● Content filter requests are stored in queue files; this is how Postfix keeps track of what mail needs
filtering. When a queue file contains a content filter request, the queue manager will deliver the
mail to the specified content filter regardless of its final destination.
● The "receive_override_options" line disables address manipulation before the content filter, so that
the content filter sees the original mail addresses instead of the result of virtual alias expansion,
canonical mapping, automatic bcc, address masquerading, etc.
Advanced content filter: sending unfiltered mail to the content filter
In this example, "scan" is an instance of the Postfix SMTP client with slightly different configuration
parameters. This is how one would set up the service in the Postfix master.cf file:
#
=============================================================
# service type private unpriv chroot wakeup maxproc
command
#
=============================================================
scan unix - - n - 10
smtp
-o smtp_send_xforward_command=yes
● This runs up to 10 content filters in parallel. Instead of a limit of 10 concurrent processes, use
whatever process limit is feasible for your machine. Content inspection software can gobble up a
lot of system resources, so you don't want to have too much of it running at the same time.
● With "-o smtp_send_xforward_command=yes", the scan transport will try to forward the original
client name and IP address to the after-filter smtpd process, so that filtered mail is logged with the
real client name IP address. See smtp(8) and XFORWARD_README for more information.
Advanced content filter: running the content filter

The content filter can be set up with the Postfix spawn service, which is the Postfix equivalent of inetd.
For example, to instantiate up to 10 content filtering processes on localhost port 10025:
#
===================================================================
maxproc command
(100)
#
===================================================================
localhost:10025 inet n n n -
10 spawn
user=filter argv=/path/to/filter localhost 10026
● "filter" is a dedicated local user account. The user will never log in, and can be given a "*"
password and non-existent shell and home directory. This user handles all potentially dangerous
mail content - that is why it should be a separate account.
If you want to have your filter listening on port localhost:10025 instead of Postfix, then you must run your
filter as a stand-alone program, and must not use the Postfix spawn service.
Advanced filter: injecting mail back into Postfix
The job of the content filter is to either bounce mail with a suitable diagnostic, or to feed the mail back
into Postfix through a dedicated listener on port localhost 10026.
The simplest content filter just copies SMTP commands and data between its inputs and outputs. If it has a
problem, all it has to do is to reply to an input of `.' from Postfix with `550 content rejected', and to
disconnect without sending `.' on the connection that injects mail back into Postfix.
#
===================================================================
maxproc command
(100)
#
===================================================================
localhost:10026 inet n - n -
10 smtpd
-o content_filter=
-o

receive_override_options=no_unknown_recipient_checks,
no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,
reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
● Note: do not use spaces around the "=" or "," characters.
● Note: the SMTP server must not have a smaller process limit than the "filter" master.cf entry.
● The "-o content_filter=" overrides main.cf settings, and requests no content filtering for mail from
the content filter. This is required or else mail will stay in the content filtering loop.
● The "-o receive_override_options" overrides main.cf settings. It is complementary to the options

that are specified in main.cf:
❍ Disable attempts to find out if a recipient is unknown, and disable header/body checks. This
work was already done before the content filter and repeating it would be wasteful.
❍ Enable virtual alias expansion, canonical mappings, address masquerading, and other
address mappings.
These receive override options are either implemented by the SMTP server itself, or they are
passed on to the cleanup server.
● The "-o smtpd_xxx_restrictions" and "-o mynetworks=127.0.0.0/8" override main.cf settings. They
turn off junk mail controls that would only waste time here.
● With "-o smtpd_authorized_xforward_hosts=127.0.0.0/8", the scan transport will try to forward the
original client name and IP address to the after-filter smtpd process, so that filtered mail is logged
with the real client name and IP address. See XFORWARD_README and smtpd(8).
Advanced content filter performance

With the "sandwich" approach to content filtering described here, it is important to match the filter
concurrency to the available CPU, memory and I/O resources. Too few content filter processes and mail
accumulates in the active queue even with low traffic volume; too much concurrency and Postfix ends up
deferring mail destined for the content filter because processes fail due to insufficient resources.
Currently, content filter performance tuning is a process of trial and error; analysis is handicapped because
filtered and unfiltered messages share the same queue. As mentioned in the introduction of this document,

content filtering with multiple Postfix instances will be covered in a future version.
Turning off the advanced content filter

To turn off "advanced" content filtering:
● Delete or comment out the two following main.cf lines. The other changes made for advanced
content filtering have no effect when content filtering is turned off.
content_filter = scan:localhost:10025
● Execute "postsuper -r ALL" to remove content filter information from existing queue files.
● Execute another "postfix reload".
Filtering mail from outside users only

The easiest approach is to configure ONE Postfix instance with multiple SMTP server IP addresses in
master.cf:
● Two SMTP server IP addresses for mail from inside users only, with content filtering turned off.
/etc/postfix.master.cf:
#
==================================================================
command
#
==================================================================
1.2.3.4:smtp inet n - n - -
smtpd
-o smtpd_client_restrictions=permit_mynetworks,reject
127.0.0.1:smtp inet n - n - -
smtpd
-o smtpd_client_restrictions=permit_mynetworks,reject
● One SMTP server address for mail from outside users with content filtering turned on.
#
=================================================================


command
#
=================================================================
1.2.3.5:smtp inet n - n - -
smtpd
-o content_filter=foo:bar
-o receive_override_options=no_address_mappings
After this, you can follow the same procedure as outlined in the "advanced" or "simple" content filtering
examples above, except that you must not specify "content_filter" or "receive_override_options" in the
main.cf file.
Different filters for different domains

If you are an MX service provider and want to apply different content filters for different domains, you
can configure ONE Postfix instance with multiple SMTP server IP addresses in master.cf. Each address
provides a different content filter service.
#
=================================================================
maxproc command
#
=================================================================
# SMTP service for domains that are content filtered with
foo:bar
1.2.3.4:smtp inet n - n -
- smtpd
-o content_filter=foo:bar
# SMTP service for domains that are content filtered with

xxx:yyy
- smtpd
-o content_filter=xxx:yyy
After this, you can follow the same procedure as outlined in the "advanced" or "simple" content filtering
examples above, except that you must not specify "content_filter" or "receive_override_options" in the
main.cf file.

Set up MX records in the DNS that route each domain to the proper SMTP server instance.
FILTER actions in access or header/body tables

The above filtering configurations are static. Mail that follows a given path is either always filtered or it is
never filtered. As of Postfix 2.0 you can also turn on content filtering on the fly.
To turn on content filtering with an access(5) table rule:
whatever FILTER foo:bar
To turn on content filtering with a header_checks(5) or body_checks(5) table pattern:
/etc/postfix/header_checks:
/whatever/ FILTER foo:bar
You can do this in smtpd access maps as well as the cleanup server's header/body_checks. This feature
must be used with great care: you must disable all the UCE features in the after-filter smtpd and cleanup
daemons or else you will have a content filtering loop.
Limitations:
● FILTER actions from smtpd access maps and header/body_checks take precedence over filters
specified with the main.cf content_filter parameter.
● If a message triggers more than one filter action, only the last one takes effect.
● The same content filter is applied to all the recipients of a given message.

Postfix manual - postcat(1)
POSTCAT(1) POSTCAT
(1)
NAME
postcat - show Postfix queue file contents
SYNOPSIS
postcat [-oqv] [-c config_dir] [files...]
DESCRIPTION
The postcat command prints the contents of the named
files
in human-readable form. The files are expected to be
in
Postfix queue file format. If no files are specified
on
the command line, the program reads from standard input.
Options:
-c config_dir
named
configuration
directory.
-o Print the queue file offset of each record.
-q Search the Postfix queue for the named

files
instead of taking the names literally.
Available in Postfix version 2.0 and later.

Mul-
increasingly
verbose.
http://www.subneural.net/postfix-master/postcat.1.html (1 of 3)01/16/2005 15:46:30

DIAGNOSTICS
Problems are reported to the standard error stream.
ENVIRONMENT
MAIL_CONFIG
relevant
to this program.

See

and

direc-
tory.
FILES
/var/spool/postfix, Postfix queue directory
SEE ALSO
postconf(5), Postfix configuration
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704

POSTCAT
(1)

Postfix manual - tcp_table(5)
TCP_TABLE(5) TCP_TABLE
(5)
NAME
tcp_table - Postfix client/server table lookup protocol
SYNOPSIS
postmap -q "string" tcp:host:port
postmap -q - tcp:host:port <inputfile
DESCRIPTION
address
dbm
or db format. Alternatively, table lookups can be
directed
to a TCP server.

sys-
To test lookup tables, use the postmap command

as
PROTOCOL DESCRIPTION
The TCP map class implements a very simple protocol:
the
client sends a request, and the server sends one
reply.
Requests and replies are sent as one line of ASCII
text,
terminated by the ASCII newline character. Request
and
reply parameters (see below) are separated by
whitespace.
Send and receive operations must complete in 100
http://www.subneural.net/postfix-master/tcp_table.5.html (1 of 4)01/16/2005 15:46:31

seconds.
REQUEST FORMAT
Each request specifies a command, a lookup key, and
possi-
bly a lookup result.
get SPACE key NEWLINE

Look up data under the specified key.
put SPACE key SPACE value NEWLINE

This request is currently not implemented.
REPLY FORMAT
Each reply specifies a status code and text. Replies
must
be no longer than 4096 characters including the
newline
terminator.
500 SPACE text NEWLINE

In case of a lookup request, the requested
data
does not exist. In case of an update request,
the
request was rejected. The text describes
the
nature of the problem.

This indicates an error condition. The
text
describes the nature of the problem. The
client
should retry the request later.

The request was successful. In the case of a
lookup
request, the text contains an encoded version
of
the requested data.

ENCODING
In request and reply parameters, the character %,
each
non-printing character, and each whitespace character
must
be replaced by %XX, where XX is the corresponding
ASCII
hexadecimal character value. The hexadecimal codes can
be
specified in any case (upper, lower, mixed).
The Postfix client always encodes a request. The

server
may omit the encoding as long as the reply is
guaranteed
to not contain the % or NEWLINE character.
SECURITY
Do not use TCP lookup tables for security critical
pur-
poses. The client-server connection is not protected
and
the server is not authenticated.
BUGS
Only the lookup method is currently implemented.
The client does not hang up when the connection is

idle
for a long time.
SEE ALSO
regexp_table(5) format of regular expression tables
pcre_table(5) format of PCRE tables
cidr_table(5) format of CIDR tables
README FILES
LICENSE

this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
TCP_TABLE
(5)

Postfix manual - spawn(8)
SPAWN(8) SPAWN
(8)
NAME
spawn - Postfix external command spawner
SYNOPSIS
spawn [generic Postfix daemon options]
command_attributes...
DESCRIPTION
The spawn daemon provides the Postfix equivalent of
inetd.
It listens on a port as specified in the Postfix master.
cf
file and spawns an external command whenever a
connection
is established. The connection can be made over local
IPC
(such as UNIX-domain sockets) or over non-local IPC
(such
as TCP sockets). The command's standard input, output
and
error streams are connected directly to the
communication
endpoint.
This daemon expects to be run from the master(8)

process
manager.
COMMAND ATTRIBUTE SYNTAX

The external command attributes are given in the master.
cf
file at the end of a service definition. The syntax is
as
follows:
user=username (required)
user=username:groupname
http://www.subneural.net/postfix-master/spawn.8.html (1 of 5)01/16/2005 15:46:31

The external command is executed with the rights

of
the specified username. The software refuses
to
execute commands with root privileges, or with
the
privileges of the mail system owner. If
groupname
is specified, the corresponding group ID is
used
instead of the group ID of of username.
argv=command... (required)
The command to be executed. This must be
specified
as the last command attribute. The command is
exe-
cuted directly, i.e. without interpretation
of
shell meta characters by a shell command
inter-
preter.
BUGS
In order to enforce standard Postfix process resource
con-
trols, the spawn daemon runs only one external command
at
a time. As such, it presents a noticeable overhead
by
wasting precious process resources. The spawn daemon
is
expected to be replaced by a more structural solution.
DIAGNOSTICS
The spawn daemon reports abnormal child exits.
Problems
are logged to syslogd(8).
SECURITY
This program needs root privilege in order to
execute
external commands as the specified user. It is

therefore
security sensitive. However the spawn daemon does
not
talk to the external command and thus is not vulnerable
to
data-driven attacks.
Changes to main.cf are picked up automatically as spawn
(8)
the

See
In the text below, transport is the first field of

the
entry in the master.cf file.
RESOURCE AND RATE CONTROL

transport_time_limit ($command_time_limit)
The amount of time the command is allowed to
run
before it is terminated.
MISCELLANEOUS
and
to
a


Postfix
ipc_timeout (3600s)
information
queue
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a
pro-
cess.
daemon
process.

direc-
tory.

pro-
"smtpd"
SEE ALSO
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
SPAWN
(8)

Postfix manual - error(8)
ERROR(8) ERROR
(8)
NAME
error - Postfix error mail delivery agent
SYNOPSIS
error [generic Postfix daemon options]
DESCRIPTION
The Postfix error delivery agent processes
delivery
requests from the queue manager. Each request specifies
a
queue file, a sender address, a domain or host name
that
is treated as the reason for non-delivery, and
recipient
information. This program expects to be run from the
mas-
The error delivery agent bounces all recipients in

the
delivery request using the "next-hop" domain or
host
information as the reason for non-delivery, updates
the
queue file and marks recipients as finished or informs
the
queue manager that delivery should be tried again at
a
later time.
Delivery status reports are sent to the bounce

(8),
defer(8) or trace(8) daemon as appropriate.
SECURITY
The error mailer is not security-sensitive. It does
not
http://www.subneural.net/postfix-master/error.8.html (1 of 5)01/16/2005 15:46:32

talk to the network, and can be run chrooted at fixed

low
privilege.
STANDARDS
None.
DIAGNOSTICS

parameter,
trou-
ble.
Changes to main.cf are picked up automatically as error
(8)
the

See
2bounce_notice_recipient (postmaster)
The recipient of undeliverable mail that cannot
be
returned to the sender.
bounce_notice_recipient (postmaster)
the
message headers of mail that Postfix did
not
deliver and of SMTP conversation transcripts
of
mail that Postfix did not receive.


and
to
a
that
ipc_timeout (3600s)
information
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a

the
postmaster.
pro-
cess.

daemon
process.

direc-
tory.
pro-
"smtpd"
SEE ALSO
discard(8), Postfix discard delivery agent
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704

ERROR
(8)

Postfix Before-Queue Content Filter
Postfix Before-Queue
Content Filter
WARNING WARNING WARNING

The before-queue content filtering feature described in this document is suitable only for low-
traffic sites. See the "Pros and Cons" section below for details.
The Postfix before-queue content filter feature

As of version 2.1, the Postfix SMTP server can forward all incoming mail to a content filtering
proxy server that inspects all mail BEFORE it is stored in the Postfix mail queue.
The before-queue content filter is meant to be used as follows:
Postfix Before Postfix Postfix smtp

- - - - - Postfix -
Internet SMTP queue SMTP cleanup local
> > > > > queue <
server filter server server virtual
The before-queue content filter is not to be confused with the approach described in the
FILTER_README document, where mail is filtered AFTER it is stored in the Postfix mail
queue.
This document describes the following topics:
● Principles of operation
● Pros and cons of before-queue content filtering
● Configuring the Postfix SMTP pass-through proxy feature
● Configuration parameters
● How Postfix talks to the before-queue content filter
● Transparency
http://www.subneural.net/postfix-master/SMTPD_PROXY_README.html (1 of 6)01/16/2005 15:46:32

Principles of operation
The before-filter Postfix SMTP server receives mail from the Internet and does the usual relay
access control, SASL authentication, RBL lookups, rejecting non-existent sender or recipient
addresses, etc. The before-queue filter receives unfiltered mail content from Postfix and does one
of the following:
1. Re-inject the mail back into Postfix via SMTP, perhaps after changing its content and/or
destination.
2. Reject the mail by sending a suitable SMTP status code back to Postfix. Postfix passes the
status back to the remote SMTP client. This way, Postfix does not have to send a bounce
message.
The after-filter Postfix SMTP server receives mail from the content filter. From then on Postfix
processes the mail as usual.
The before-queue content filter described here works just like the after-queue content filter
described in the FILTER_README document. In many cases you can use the same software,
within the limitations as discussed in the "Pros and Cons" section below.
Pros and cons of before-queue content filtering

● Pro: Postfix can reject mail before the incoming SMTP mail transfer completes, so that
Postfix does not have to send rejected mail back to the sender (which is usually forged
anyway). Mail that is not accepted remains the responsibility of the remote SMTP client.
● Con: The remote SMTP client expects an SMTP reply within a deadline. As the system
load increases, fewer and fewer CPU cycles remain available to answer within the
deadline, and eventually you either have to stop accepting mail or you have to stop
filtering mail. It is for this reason that the before-queue content filter can be used only on
low-traffic sites.
● Con: Content filtering software can use lots of memory resources. In order to not run out
of memory you have to reduce the number of before-filter SMTP server processes so that
a burst of mail will not drive your system into the ground with too many content filter
processes. This, in turn, means that SMTP clients have to wait for a long time before they
receive service.
Configuring the Postfix SMTP pass-through proxy feature

In the following example, the before-filter Postfix SMTP server gives mail to a content filter that
listens on localhost port 10025. The after-filter Postfix SMTP server receives mail from the
content filter via localhost port 10026. From then on mail is processed as usual.
The content filter itself is not described here. You can use any filter that is SMTP enabled. For
non-SMTP capable content filtering software, Bennett Todd's SMTP proxy implements a nice
PERL/SMTP content filtering framework. See: http://bent.latency.net/smtpprox/.
Postfix
Postfix
SMTP
SMTP filter on server Postfix Postfix
- server - localhost - - - incoming
Internet on cleanup
> on > port > > >
localhost server queue
port 10025
port
25
10026
This is configured by editing the master.cf file:
#
=============================================================
maxproc command
(100)
#
=============================================================
#
# Before-filter SMTP server. Receive mail from the
network and
# pass it to the content filter on localhost port
10025.
#
smtp inet n - n -
20 smtpd
-o smtpd_proxy_filter=127.0.0.1:10025
-o smtpd_client_connection_count_limit=10
#
# After-filter SMTP server. Receive mail from the
content filter

# on localhost port 10026.

#
127.0.0.1:10026 inet n - n -
- smtpd
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o
smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=
-o mynetworks=127.0.0.0/8
-o
receive_override_options=no_unknown_recipient_checks
Note: do not specify spaces around the "=" or "," characters.
The before-filter SMTP server entry is a modified version of the default Postfix SMTP server
entry that is normally configured at the top of the master.cf file:
● The number of SMTP sessions is reduced from the default 100 to only 20. This prevents a
burst of mail from running your system into the ground with too many content filter
processes.
● The "-o smtpd_client_connection_count_limit=10" prevents one SMTP client from using

up all 20 SMTP server processes. This limit is not necessary if you receive all mail from a
trusted relay host.
Note: this setting is ignored by the stable Postfix 2.1 release. The feature will be available
only in the experimental release until Postfix 2.2.
● The "-o smtpd_proxy_filter=127.0.0.1:10025" tells the before filter SMTP server that it
should give incoming mail to the content filter that listens on localhost port 10025.
The after-filter SMTP server is a new master.cf entry:
● The "127.0.0.1:10026" makes the after-filter SMTP server listen on the localhost address
only, without exposing it to the network. NEVER expose the after-filter SMTP server to
the Internet :-)
● The "-o smtpd_authorized_xforward_hosts=127.0.0.0/8" allows the after-filter SMTP

server to receive remote SMTP client information from the before filter SMTP server, so
that the after-filter Postfix daemons log the remote SMTP client information instead of
logging localhost[127.0.0.1].
● The other after-filter SMTP server settings avoid duplication of work that is already done
in the "before filter" SMTP server.
By default, the filter has 100 seconds to do its work. If it takes longer then Postfix gives up and
reports an error to the remote SMTP client. You can increase this time limit (see configuration
parameter section below) but doing so is pointless because you can't control when the remote
SMTP client times out.
Configuration parameters
Parameters that control proxying:
● smtpd_proxy_filter (syntax: host:port): The host and TCP port of the before-queue content
filter. When no host or host: is specified in client context, localhost is assumed.
● smtpd_proxy_timeout (default: 100s): Timeout for connecting to the before-queue content

filter and for sending and receiving commands and data. All proxy errors are logged to the
maillog file. For privacy reasons, all the remote SMTP client sees is "451 Error: queue file
write error". It would not be right to disclose internal details to strangers.
● smtpd_proxy_ehlo (default: $myhostname): The hostname to use when sending an EHLO

command to the before-queue content filter.
How Postfix talks to the before-queue content filter

The before-filter Postfix SMTP server connects to the content filter, delivers one message, and
disconnects. While sending mail into the content filter, Postfix speaks ESMTP but uses no
command pipelining. Postfix generates its own EHLO, XFORWARD (for logging the remote
client IP address instead of localhost[127.0.0.1]), DATA and QUIT commands, and forwards
unmodified copies of all the MAIL FROM and RCPT TO commands that the before-filter Postfix
SMTP server didn't reject itself. The SMTP proxy server should accept the same MAIL FROM
and RCPT TO command syntax as the Postfix SMTP server. Postfix sends no other SMTP
commands.
The content filter is expected to pass on unmodified SMTP commands from a before-filter
Postfix SMTP server to an after-filter Postfix SMTP server that usually listens on a non-standard
port. When the filter rejects content, it should send a negative SMTP response back to the before-

filter Postfix SMTP server, and it should abort the connection with the after-filter Postfix SMTP
server without completing the SMTP conversation with the after-filter Postfix SMTP server.
More detail on the postfix-to-proxy interaction is in the section titled "Transparency".
Transparency
The before-filter Postfix SMTP server forwards the MAIL FROM, RCPT TO and DATA
commands that it has approved, but it does not forward other commands such as TLS or SASL
commands. It can therefore not be transparent.
The real-time content filter, on the other hand, has to be transparent. In order to support non-
transparent real-time content filters, Postfix would have to reconcile the before-filter Postfix
ESMTP feature set with the feature set that Postfix receives from the real-time content filter.
● When a future Postfix version supports DSN, but the content filter does not announce
DSN support in the EHLO reply, then the before-filter SMTP server would have to either
1) suppress the DSN feature in its EHLO announcement, or 2) duplicate all the work that
needs to be done when delivering DSN-aware mail to a non-DSN destination.
● When the content filter does not announce 8BITMIME support in the EHLO reply, then
the before-filter SMTP server would have to either 1) suppress the 8BITMIME feature in
its EHLO announcement, or 2) convert the content to quoted-printable before giving it to
the content filter.
● Performance: when Postfix has to suppress elements from the before-filter EHLO reply
because they are incompatible with the real-time content filter, then Postfix has to connect
to the content filter as soon as the client sends a valid EHLO command. This wastes a lot
of resources when all the MAIL FROM or RCPT TO commands are rejected.
Therefore, the Postfix SMTP server cannot be transparent with respect to the before-queue
content filter.

Postfix manual - pipe(8)
PIPE(8) PIPE
(8)
NAME
pipe - Postfix delivery to external command
SYNOPSIS
pipe [generic Postfix daemon options]
command_attributes...
DESCRIPTION
The pipe daemon processes requests from the Postfix
queue
manager to deliver messages to external commands.
This
program expects to be run from the master(8) process
man-
ager.
Message attributes such as sender address,

recipient
address and next-hop host name can be specified as
com-
mand-line macros that are expanded before the
external
command is executed.
The pipe daemon updates queue files and marks

recipients
as finished, or it informs the queue manager that
delivery
should be tried again at a later time. Delivery
status
reports are sent to the bounce(8), defer(8) or trace
(8)
daemon as appropriate.
SINGLE-RECIPIENT DELIVERY
Some external commands cannot handle more than one
recipi-
ent per delivery request. Examples of such transports
http://www.subneural.net/postfix-master/pipe.8.html (1 of 13)01/16/2005 15:46:33

are
pagers, fax machines, and so on.
To prevent Postfix from sending multiple recipients

per
delivery request, specify
transport_destination_recipient_limit = 1
in the Postfix main.cf file, where transport is the

name
in the first column of the Postfix master.cf entry for
the
pipe-based delivery transport.
COMMAND ATTRIBUTE SYNTAX

The external command attributes are given in the master.
cf
file at the end of a service definition. The syntax is
as
follows:
directory=pathname (optional, default: $queue_directory)

Change to the named directory before executing
the
external command. Delivery is deferred in case
of
failure.
This feature is available as of Postfix 2.2.
eol=string (optional, default: \n)

The output record delimiter. Typically one
would
use either \r\n or \n. The usual C-style
backslash
escape sequences are recognized: \a \b \f \n \r
\t
\v \ddd (up to three octal digits) and \\.
flags=BDFORhqu.> (optional)
Optional message processing flags. By default,

a
message is copied unchanged.
B Append a blank line at the end of each

mes-
sage. This is required by some mail
user
agents that recognize "From " lines
only
when preceded by a blank line.
D Prepend a "Delivered-To: recipient"

message
header with the envelope recipient
address.
Note: for this to work, the
transport_desti-
nation_recipient_limit must be 1.
This feature is available as of Postfix

2.0.
F Prepend a "From sender time_stamp"

envelope
header to the message content. This
is
expected by, for example, UUCP software.
O Prepend an "X-Original-To: recipient"

mes-
sage header with the recipient address
as
given to Postfix. Note: for this to
work,
the
must be 1.
This feature is available as of Postfix

2.0.
R Prepend a Return-Path: message header

with

the envelope sender address.
h Fold the command-line $recipient domain

name
and $nexthop host name to lower case.
This
is recommended for delivery via UUCP.
q Quote white space and other special

charac-
ters in the command-line $sender and
$recip-
ient address localparts (text to the left
of
the right-most @ character), according to
an
8-bit transparent version of RFC 822.
This
is recommended for delivery via UUCP
or
BSMTP.
The result is compatible with the

address
parsing of command-line recipients by
the
Postfix sendmail mail submission command.
The q flag affects only entire

addresses,
not the partial address information from
the
$user, $extension or $mailbox command-
line
macros.
u Fold the command-line $recipient

address
localpart (text to the left of the
right-
most @ character) to lower case. This
is

recommended for delivery via UUCP.
. Prepend "." to lines starting with ".".

This
is needed by, for example, BSMTP software.
> Prepend ">" to lines starting with "From

".
This is expected by, for example, UUCP
soft-
ware.
size=size_limit (optional)
Messages greater in size than this limit (in
bytes)
will be bounced back to the sender.
user=username (required)
user=username:groupname
The external command is executed with the rights
of
the specified username. The software refuses
to
execute commands with root privileges, or with
the
privileges of the mail system owner. If
groupname
is specified, the corresponding group ID is
used
instead of the group ID of username.
argv=command... (required)
The command to be executed. This must be
specified
as the last command attribute. The command is
exe-
cuted directly, i.e. without interpretation
of
shell meta characters by a shell command
inter-
preter.

In the command argument vector, the

following
macros are recognized and replaced with
correspond-
ing information from the Postfix queue
manager
delivery request.
In addition to the form ${name}, the forms

$name
and $(name) are also recognized. Specify $$
where
a single $ is wanted.
${client_address}
This macro expands to the remote client
net-
work address.
This is available in Postfix 2.2 and

later.
${client_helo}
HELO
command parameter.

later.
${client_hostname}
This macro expands to the remote
client
hostname.

later.
${client_protocol}
pro-
tocol.


later.
${extension}
This macro expands to the extension part
of
a recipient address. For example, with
an
address user+foo@domain the extension
is
foo.
A command-line argument that

contains
${extension} expands into as many
command-
line arguments as there are recipients.
This information is modified by the u

flag
for case folding.
${mailbox}
This macro expands to the complete
local
part of a recipient address. For
example,
with an address user+foo@domain the
mailbox
is user+foo.

contains
${mailbox} expands into as many command-
line
arguments as there are recipients.

flag
for case folding.
${nexthop}

This macro expands to the next-hop

hostname.
This information is modified by the h

flag
for case folding.
${recipient}
This macro expands to the complete
recipient
address.

contains
${recipient} expands into as many
command-
line arguments as there are recipients.
This information is modified by the

hqu
flags for quoting and case folding.
${sasl_method}
This macro expands to the SASL
authentica-
tion mechanism used during the reception
of
the message. An empty string is passed
if
the message has been received without
SASL
authentication.

later.
${sasl_sender}
This macro expands to the SASL sender
name
(i.e. the original submitter as per
RFC
2554) used during the reception of the

mes-
sage.

later.
${sasl_username}
This macro expands to the SASL user
name
used during the reception of the message.
An
empty string is passed if the message
has
been received without SASL authentication.

later.
${sender}
This macro expands to the envelope
sender
address.
This information is modified by the q

flag
for quoting.
${size}
This macro expands to Postfix's idea of
the
message size, which is an approximation
of
the size of the message as delivered.
${user}
This macro expands to the username part of
a
recipient address. For example, with
an
address user+foo@domain the username part
is
user.


contains
${user} expands into as many command-
line
arguments as there are recipients.

flag
for case folding.
DIAGNOSTICS
Command exit status codes are expected to follow the
con-
ventions defined in <sysexits.h>.

Cor-
manager
inspection.
SECURITY
This program needs a dual personality 1) to access
the
private Postfix queue and IPC mechanisms, and 2) to
exe-
cute external commands as the specified user. It is
there-
fore security sensitive.
Changes to main.cf are picked up automatically as pipe
(8)
the

See


In the text below, transport is the first field in a
mas-
ter.cf entry.
($default_destina-
Limit the number of parallel deliveries to the
same
destination, for delivery via the named
transport.
The limit is enforced by the Postfix queue
manager.
($default_destina-
Limit the number of recipients per message
deliv-
ery, for delivery via the named transport.
The
limit is enforced by the Postfix queue manager.
transport_time_limit ($command_time_limit)
Limit the time for delivery to external
command,
for delivery via the named transport. The limit
is
enforced by the pipe delivery agent.
and
to
a


Postfix
ipc_timeout (3600s)
information
queue
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a
pro-
cess.
daemon
process.

direc-

tory.
exten-
sions (user+foo).
pro-
"smtpd"
SEE ALSO
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
PIPE
(8)

Postfix XFORWARD Howto
Purpose of the XFORWARD extension to SMTP

The XFORWARD command targets the following problem:
● Logging after SMTP-based content filter. With the deployment of Internet->MTA1-

>filter->MTA2 style content filter applications, the logging of client and message
identifying information changes when MTA1 gives the mail to the content filter. To
simplify the interpretation of MTA2 logging, it would help if MTA1 could forward
remote client and/or message identifying information through the content filter to
MTA2, so that the information could be logged as part of mail handling transactions.
This extension is implemented as a separate command, and can be used to transmit client or
message attributes incrementally. It is not implemented by passing additional parameters via
the MAIL FROM command, because doing so would require extending the MAIL FROM
command length limit by another 600 or more characters beyond the space that is already
needed in order to support other extensions such as AUTH.
XFORWARD Command syntax

An example of a client-server conversation is given at the end of this document.
In SMTP server EHLO replies, the keyword associated with this extension is XFORWARD.
The keyword is followed by the names of the attributes that the XFORWARD implementation
supports.
The client may send the XFORWARD request at any time except in the middle of a mail
delivery transaction (i.e. between MAIL and DOT). The command may be pipelined when the
server supports ESMTP command pipelining.
The syntax of XFORWARD requests is described below. Upper case and quoted strings
http://www.subneural.net/postfix-master/XFORWARD_README.html (1 of 4)01/16/2005 15:46:33

specify terminals, lowercase strings specify meta terminals, and SP is whitespace. Although
command and attribute names are shown in upper case, they are in fact case insensitive.
xforward-command = XFORWARD 1*( SP attribute-name"="attribute-value )
attribute-name = ( NAME | ADDR | PROTO | HELO | SOURCE )
● The NAME attribute specifies the up-stream hostname, or [UNAVAILABLE] when the
information is unavailable. The hostname may be a non-DNS hostname.
● The ADDR attribute specifies the up-stream network address, or [UNAVAILABLE]

when the information is unavailable. Address information is not enclosed with []. The
address may be a non-IP address.
● The PROTO attribute specifies the mail protocol for receiving mail from the up-stream
host. This may be an SMTP non-SMTP protocol name of up to 64 characters, or
[UNAVAILABLE] when the information is unavailable.
● The HELO attribute specifies the hostname that the up-stream host announced itself
with (not necessarily via the SMTP HELO command), or [UNAVAILABLE] when the
information is unavailable. The hostname may be a non-DNS hostname.
● The SOURCE attribute specifies LOCAL when the message was received from a source
that is local with respect to the up-stream host, REMOTE for mail from a remote
source, or [UNAVAILABLE] when the information is unavailable. The down-stream
MTA may decide to enable header munging and address qualification with mail from
local sources.
Note 1: Attribute values must not be longer than 255 characters (specific attributes may impose
shorter lengths), must not contain control characters, non-ASCII characters, whitespace, or
other characters that are special in message headers. Future attributes that may violate this
should use xtext encoding as described in RFC 1891.
Note 2: DNS hostnames can be up to 255 characters long. The XFORWARD client
implementation must not send XFORWARD commands that exceed the 512 character limit for
SMTP commands.
Note 3: [UNAVAILABLE] may be specified in upper case, lower case or mixed case.
Note 4: the XFORWARD server implementation must not mix information from the current
SMTP session with forwarded information from an up-stream session.

The XFORWARD server reply codes are as follows:
Code Meaning
250 success
501 bad command parameter syntax
503 mail transaction in progress
unable to proceed,
421
disconnecting
XFORWARD Example
In the following example, information sent by the client is shown in bold font.
220 server.example.com ESMTP Postfix

EHLO client.example.com
250-server.example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-XFORWARD NAME ADDR PROTO HELO
250 8BITMIME
XFORWARD NAME=spike.porcupine.org ADDR=168.100.189.2
PROTO=ESMTP
250 Ok
XFORWARD HELO=spike.porcupine.org
250 Ok
MAIL FROM:<wietse@porcupine.org>
250 Ok
RCPT TO:<user@example.com>
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
. . .message content. . .
.
250 Ok: queued as 3CF6B2AAE8
QUIT
221 Bye

Security
The XFORWARD command changes audit trails. Use of this command must be restricted to
authorized clients.
SMTP connection caching

SMTP connection caching makes it possible to deliver multiple messages within the same
SMTP session. The XFORWARD attributes are reset after the MAIL FROM command
completes, so there is no risk of information leakage.

Postfix manual - header_checks(5)
HEADER_CHECKS(5) HEADER_CHECKS
(5)
NAME
header_checks - Postfix built-in header/body inspection
SYNOPSIS
header_checks = pcre:/etc/postfix/header_checks
mime_header_checks = pcre:/etc/postfix/mime_header_checks
nested_header_checks = pcre:/etc/postfix/
nested_header_checks
body_checks = pcre:/etc/postfix/body_checks
postmap -fq "string" pcre:/etc/postfix/filename

postmap -fq - pcre:/etc/postfix/filename <inputfile
DESCRIPTION
Postfix provides a simple built-in content
inspection
mechanism that examines incoming mail one message
header
or one message body line at a time. Each input is
compared
against a list of patterns, and when a match is found
the
corresponding action is executed. This feature is
imple-
mented by the Postfix cleanup(8) server.
For examples, see the EXAMPLES section at the end of

this
manual page.
Postfix header or body_checks are designed to stop a

flood
of mail from worms or viruses; they do not decode
attach-
ments, and they do not unzip archives. See the
documents
referenced below in the README FILES section if you
http://www.subneural.net/postfix-master/header_checks.5.html (1 of 12)01/16/2005 15:46:34

need
more sophisticated content analysis.
Postfix supports four built-in content inspection

classes:
header_checks
These are applied to initial message
headers
(except for the headers that are processed
with
mime_header_checks).

These are applied to MIME related message
headers
only.

later.

These are applied to message headers of
attached
email messages (except for the headers that
are
processed with mime_header_checks).

later.
body_checks
These are applied to all other content,
including
multi-part message boundaries.
With Postfix versions before 2.0, all content

after
the initial message headers is treated as body
con-
tent.

Note: message headers are examined one logical header at

a
time, even when a message header spans multiple
lines.
Body lines are always examined one line at a time.
TABLE FORMAT
This document assumes that header and body_checks
rules
are specified in the form of Postfix regular
expression
lookup tables. Usually the best performance is
obtained
with pcre (Perl Compatible Regular Expression) tables,
but
the slower regexp (POSIX regular expressions) support
is
more widely available. Use the command postconf -m
to
find out what lookup table types your Postfix system
sup-
ports.
The general format of Postfix regular expression tables

is
given below. For a discussion of specific pattern
or
flags syntax, see pcre_table(5) or regexp_table
(5),
respectively.
/pattern/flags action
When pattern matches the input string, execute
the
corresponding action. See below for a list of
pos-
sible actions.
!/pattern/flags action
exe-
cute the corresponding action.

if /pattern/flags

between
also
matches pattern. The if..endif can nest.

inside
if..endif.
if !/pattern/flags

between
does
not match pattern. The if..endif can nest.

ignored,
character
is a `#'.
multi-line text
A pattern/action line starts with non-
whitespace
text. A line that starts with whitespace
continues
a logical line.
TABLE SEARCH ORDER

For each line of message input, the patterns are
applied
in the order as specified in the table. When a pattern
is
found that matches the input line, the
corresponding
action is executed and then the next input line

is
inspected.
TEXT SUBSTITUTION
expression
into the action string is possible using the
conventional
Perl syntax ($1, $2, etc.). The macros in the
result
string may need to be written as ${n} or $(n) if
they
aren't followed by whitespace.

return
substitutions
ACTIONS
Action names are case insensitive. They are shown in
upper
case for consistency with other Postfix documentation.
DISCARD optional text...

Claim successful delivery and silently discard
the
message. Log the optional text if specified,
oth-
erwise log a generic message.
Note: this action disables further header

or
body_checks inspection of the current message
and
affects all recipients.

later.
DUNNO Pretend that the input line did not match any

pat-
tern, and inspect the next input line. This
action
can be used to shorten the table search.
For backwards compatibility reasons, Postfix

also
accepts OK but it is (and always has been)
treated
as DUNNO.

later.
FILTER transport:destination
Write a content filter request to the queue
file
and inspect the next input line. After the
com-
plete message is received it will be sent
through
the specified external content filter. More
infor-
mation about external content filters is in
the
Postfix FILTER_README file.
Note: this action overrides the main.cf

con-
tent_filter setting, and affects all recipients
of
the message. In the case that multiple
FILTER
actions fire, only the last one is executed.

later.
HOLD optional text...

Arrange for the message to be placed on the
hold
queue, and inspect the next input line. The

mes-
sage remains on hold until someone either
deletes
it or releases it for delivery. Log the
optional
text if specified, otherwise log a generic
message.
Mail that is placed on hold can be examined

with
the postcat(1) command, and can be destroyed
or
released with the postsuper(1) command.

was
$maxi-
or
longer.
Note: this action affects all recipients of

the
message.

later.
IGNORE Delete the current line from the input and

inspect
the next input line.
PREPEND text...
Prepend one line with the specified text
and
inspect the next input line.
Note: the prepended text is output

immediately
before the input that triggered the PREPEND
action.

A body action cannot prepend a message header.
Note: this action cannot be used to prepend

multi-
line text.

later.
REDIRECT user@domain
Write a message redirection request to the
queue
file and inspect the next input line. After
the
message is queued, it will be sent to the
specified
address instead of the intended recipient(s).
Note: this action overrides the FILTER action,

and
affects all recipients of the message. If
multiple
REDIRECT actions fire, only the last one is
exe-
cuted.

later.
REJECT optional text...

Reject the entire message. Reply with
optional
text... when the optional text is specified,
other-
wise reply with a generic error message.
Note: this action disables further header

or
body_checks inspection of the current message
and
affects all recipients.

WARN optional text...

Log a warning with the optional text... (or log
a
generic message) and inspect the next input
line.
This action is useful for debugging and for
testing
a pattern before applying more drastic actions.
BUGS
Many people overlook the main limitations of header
and
body_checks rules. These rules operate on one
logical
message header or one body line at a time, and a
decision
made for one line is not carried over to the next
line.
If text in the message body is encoded (RFC 2045) then
the
rules have to specified for the encoded form.
Likewise,
when message headers are encoded (RFC 2047) then the
rules
need to be specified for the encoded form.
Message headers added by the cleanup(8) daemon itself

are
excluded from inspection. Examples of such message
headers
are From:, To:, Message-ID:, Date:.
Message headers deleted by the cleanup(8) daemon will

be
examined before they are deleted. Examples are: Bcc:,
Con-
tent-Length:, Return-Path:.
body_checks
Lookup tables with content filter rules for
message

body lines. These filters see one physical line

at
a time, in chunks of at most
$line_length_limit
bytes.
body_checks_size_limit
The amount of content per message body
segment
(attachment) that is subjected to $body_checks
fil-
tering.
header_checks

Lookup tables with content filter rules for
message
header lines: respectively, these are applied
to
the initial message headers (not including
MIME
headers), to the MIME headers anywhere in the
mes-
sage, and to the initial headers of attached
mes-
sages.
Note: these filters see one logical message

header
at a time, even when a message header spans
multi-
ple lines. Message headers that are longer
than
$header_size_limit characters are truncated.
disable_mime_input_processing
While receiving mail, give no special treatment
to
MIME related message headers; all text after

the
initial message headers is considered to be part
of
the message body. This means that header_checks
is
applied to all the initial message headers,
and
that body_checks is applied to the remainder of
the
message.
Note: when used in this manner, body_checks

will
process a multi-line message header one line at
a
time.
EXAMPLES
Header pattern to block attachments with bad file
name
extensions.
/^content-(type|disposition):.*name[[:space:]]*=.*\.
(exe|vbs)/
REJECT Bad attachment file name extension: $2
Body pattern to stop a specific HTML browser

vulnerability
exploit.
body_checks = regexp:/etc/postfix/body_checks
/etc/postfix/body_checks:
/^<iframe src=(3D)?cid:.* height=(3D)?0 width=(3D)?0>
$/
REJECT IFRAME vulnerability exploit

SEE ALSO
cleanup(8), canonicalize and enqueue Postfix message
pcre_table(5), format of PCRE lookup tables
regexp_table(5), format of POSIX regular expression
tables
postconf(1), Postfix configuration utility
postmap(1), Postfix lookup table management
postsuper(1), Postfix janitor
postcat(1), show Postfix queue file contents
RFC 2045, base64 and quoted-printable encoding rules
RFC 2047, message header encoding for non-ASCII text
README FILES
CONTENT_INSPECTION_README, Postfix content inspection
overview
BUILTIN_FILTER_README, Postfix built-in content
inspection
BACKSCATTER_README, blocking returned forged mail
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
HEADER_CHECKS
(5)

Postfix Address Verification
Postfix Address
Verification Howto

The sender/recipient address verification feature described in this document is suitable only for
low-traffic sites. It performs poorly under high load and may cause your site to be blacklisted
by some providers. See the "Limitations" section below for details.
What Postfix address verification can do for you

Address verification is a feature that allows the Postfix SMTP server to block a sender (MAIL
FROM) or recipient (RCPT TO) address until the address has been verified to be deliverable.
The technique has obvious uses in order to reject junk mail with an unreplyable sender address.
The technique may also be useful to block mail for undeliverable recipients, for example on a
mail relay host that does not have a list of all the valid recipient addresses. This prevents
undeliverable junk mail from entering the queue, so that Postfix doesn't have to waste resources
trying to send MAILER-DAEMON messages back.
● How address verification works

● Limitations of address verification
● Recipient address verification
● Sender address verification for mail from frequently forged domains
● Sender address verification for all email
http://www.subneural.net/postfix-master/ADDRESS_VERIFICATION_README.html (1 of 8)01/16/2005 15:46:35

● Address verification database

● Managing the address verification database
● Controlling the routing of address verification probes
● Forced probe routing examples
● Limitations of forced probe routing
How address verification works

A sender or recipient address is verified by probing the nearest MTA for that address, without
actually delivering mail. The nearest MTA could be Postfix itself, or it could be a remote MTA
(SMTP interruptus). Probe messages are like normal mail, except that they are never delivered,
deferred or bounced; probe messages are always discarded.
Postfix Postfix Address

- <- <-
Internet SMTP verify verification
> > >
server server database
| ^
probe delivery
messages status
v |
Postfix
Postfix
-> delivery
queue
agents
With Postfix address verification turned on, normal mail will suffer only a short delay of up to
6 seconds while an address is being verified for the first time. Once an address status is known,
the status is cached and Postfix replies immediately.
When verification takes too long the Postfix SMTP server defers the sender or recipient
address with a 450 reply. Normal mail clients will connect again after some delay. The address
verification delay is configurable with the main.cf address_verify_poll_count and
address_verify_poll_delay parameters. See postconf(5) for details.
Limitations of address verification

● Postfix probes the nearest MTA for the address that is being verified, without actually
sending mail to that address. If the nearest MTA accepts the address, then Postfix
assumes that the address is deliverable, even when the address will bounce AFTER that
MTA accepts it.

● Sites like AOL may blacklist you when you are probing them too often (a probe is an
SMTP session that does not deliver mail), or when you are probing them too often for a
non-existent address.
● Normally, address verification probe messages follow the same path as regular mail.
However, some sites send mail to the Internet via an intermediate relayhost; this breaks
address verification. See below, section "Controlling the routing of address verification
probes", for how to override mail routing and for possible limitations when you have to
do this.
● Postfix assumes that an address is undeliverable when the nearest MTA for the address
rejects the probe, regardless of the reason for rejection (client rejected, HELO rejected,
MAIL FROM rejected, etc.). Thus, Postfix rejects mail when the sender's MTA rejects
mail from your machine. This is a good thing.
● Unfortunately, some major sites such as YAHOO do not reject unknown addresses in
reply to the RCPT TO command, but report a delivery failure in response to end of
DATA after a message is transferred. Postfix address verification does not work with
such sites.
● By default, Postfix probe messages have "postmaster@$myorigin" as the sender

address. This is SAFE because the Postfix SMTP server does not reject mail for this
address.
You can change this into the null address ("address_verify_sender ="). This is UNSAFE
because address probes will fail with mis-configured sites that reject MAIL FROM: <>,
while probes from "postmaster@$myorigin" would succeed.
Recipient address verification

As mentioned earlier, recipient address verification may be useful to block mail for
undeliverable recipients on a mail relay host that does not have a list of all valid recipient
addresses. This can help to prevent the mail queue from filling up with MAILER-DAEMON
messages.
Recipient address verification is relatively straightforward and there are no surprises. If a

recipient probe fails, then Postfix rejects mail for the recipient address. If a recipient probe
succeeds, then Postfix accepts mail for the recipient address.

permit_mynetworks
...
reject_unknown_recipient_domain
reject_unverified_recipient
...
The "reject_unknown_recipient_domain" restriction blocks mail for non-existent domains.

Putting this before "reject_unverified_recipient" avoids the overhead of generating unnecessary
probe messages.
The unverified_recipient_reject_code parameter (default 450) specifies how Postfix replies

when a recipient address is known to bounce. Change this setting into 550 when you trust
Postfix's judgments.
Sender address verification for mail from frequently

forged domains
It is relatively safe to turn on sender address verification for specific domains that often appear
in forged email.
smtpd_sender_restrictions = hash:/etc/postfix/
sender_access
unverified_sender_reject_code = 550
# Note 1: Be sure to read the "Caching" section
below!
# Note 2: Avoid hash files here. Use btree
instead.
address_verify_map = btree:/var/mta/verify
/etc/postfix/sender_access:
aol.com reject_unverified_sender
hotmail.com reject_unverified_sender
bigfoot.com reject_unverified_sender
... etcetera ...

A list of frequently forged MAIL FROM domains can be found at http://www.monkeys.com/

anti-spam/filtering/sender-domain-validate.in.
NOTE: One of the first things you might want to do is to turn on sender address verification for
all your own domains.
Sender address verification for all email

Unfortunately, sender address verification cannot simply be turned on for all email - you are
likely to lose legitimate mail from mis-configured systems. You almost certainly will have to
set up white lists for specific addresses, or even for entire domains.
To find out how sender address verification would affect your mail, specify "warn_if_reject
reject_unverified_sender" so that you can see what mail would be blocked:
smtpd_sender_restrictions =
permit_mynetworks
...
check_sender_access hash:/etc/postfix/
sender_access
reject_unknown_sender_domain
warn_if_reject reject_unverified_sender
...
# Note 1: Be sure to read the "Caching" section
below!
# Note 2: Avoid hash files here. Use btree
instead.
This is also a good way to populate your cache with address verification results before you start
to actually reject mail.
The sender_access restriction is needed to whitelist domains or addresses that are known to be
OK. Although Postfix will not mark a known-to-be-good address as bad after a probe fails, it is
better to be safe than sorry.
NOTE: You will have to whitelist sites such as securityfocus.com and other sites that operate
mailing lists that use a different sender address for each posting (VERP). Such addresses
pollute the address verification cache quickly, and generate unnecessary sender verification

probes.
/etc/postfix/sender_access
securityfocus.com OK
...
The "reject_unknown_sender_domain" restriction blocks mail from non-existent domains.

Putting this before "reject_unverified_sender" avoids the overhead of generating unnecessary
probe messages.
The unverified_sender_reject_code parameter (default 450) specifies how Postfix replies when
a sender address is known to bounce. Change this setting into 550 when you trust Postfix's
judgments.
Address verification database

NOTE: By default, address verification information is not stored in a persistent file. You have
to specify one in main.cf (see below). Persistent storage is off by default because it may need
more disk space than is available in your file system.
Address verification information is cached by the Postfix verify daemon. Postfix has a bunch of
parameters that control the caching of positive and negative results. Refer to the verify(8)
manual page for details.
The address_verify_map (NOTE: singular) configuration parameter specifies an optional

persistent database for sender address verification results. If you don't specify a file, all address
verification information is lost after "postfix reload" or "postfix stop".
If your /var file system has sufficient space, try:
# Note: avoid hash files here. Use btree instead.
NOTE: Do not put this file in a file system that may run out of space. When the address
verification table gets corrupted the world comes to an end and YOU will have to
MANUALLY fix things as described in the next section. Meanwhile, you will not receive mail
via SMTP.
The verify(8) daemon process will create a new database when none exists, and will open/

create the file before it enters the chroot jail and before it drops root privileges.
Managing the address verification database

The verify(8) manual page describes parameters that control how long information remains
cached before it needs to be refreshed, and how long information can remain "unrefreshed"
before it expires. Postfix uses different controls for positive results (address was accepted) and
for negative results (address was rejected).
Right now, no tools are provided to manage the address verification database. If the file gets
too big, or if it gets corrupted, you can manually rename or delete the file and run "postfix
reload". The new verify daemon process will then create a new database.
Controlling the routing of address verification probes

By default, Postfix sends address verification probe messages via the same route as regular
mail, because that normally produces the most accurate result. It's no good to verify a local
address by connecting to your own SMTP port; that just triggers all kinds of mailer loop
alarms. The same is true for any destination that your machine is best MX host for: hidden
domains, virtual domains, etc.
However, some sites have a complex infrastructure where mail is not sent directly to the
Internet, but is instead given to an intermediate relayhost. This is a problem for address
verification, because remote Internet addresses can be verified only when Postfix can access
remote destinations directly.
For this reason, Postfix allows you to override the routing parameters when it delivers an
address verification probe message.
First, the address_verify_relayhost parameter allows you to override the relayhost setting, and
the address_verify_transport_maps parameter allows you to override the transport_maps
setting.
Second, each address class is given its own address verification version of the message delivery
transport, as shown in the table below. Address classes are defined in the
Regular
Domain list Verify transport
transport

mydestination local_transport address_verify_local_transport

virtual_alias_domains (not applicable) (not applicable)
virtual_mailbox_domains virtual_transport address_verify_virtual_transport
relay_domains relay_transport address_verify_relay_transport
(not applicable) default_transport address_verify_default_transport
By default, the parameters that control delivery of address probes have the same value as the
parameters that control normal mail delivery.
Forced probe routing examples

In a typical scenario one would override the relayhost setting for address verification probes
and leave everything else alone:
address_verify_relayhost =
...
Sites behind a network address translation box might have to use a different SMTP client that
sends the correct hostname information:
address_verify_relayhost =
address_verify_default_transport = direct_smtp
direct_smtp .. .. .. .. .. .. .. .. .. smtp
-o smtp_helo_name=nat.box.tld
Limitations of forced probe routing

Inconsistencies can happen when probe messages don't follow the same path as regular mail.
For example, a message can be accepted when it follows the regular route while an otherwise
identical probe message is rejected when it follows the forced route. The opposite can happen,
too, but is less likely.

Postfix manual - verify(8)
VERIFY(8) VERIFY
(8)
NAME
verify - Postfix address verification server
SYNOPSIS
verify [generic Postfix daemon options]
DESCRIPTION
The Postfix address verification server maintains a
record
of what recipient addresses are known to be deliverable
or
undeliverable.
Addresses are verified by injecting probe messages

into
the Postfix queue. Probe messages are run through all
the
routing and rewriting machinery except for final
delivery,
and are discarded rather than being deferred or bounced.
Address verification relies on the answer from the

nearest
MTA for the specified address, and will therefore
not
detect all undeliverable addresses.
This server is designed to run under control by the

Post-
fix master server. It maintains an optional
persistent
database. To avoid being interrupted by "postfix stop"
in
the middle of a database update, the process runs in
a
separate process group.
http://www.subneural.net/postfix-master/verify.8.html (1 of 6)01/16/2005 15:46:35

update address status text

Update the status and text of the
specified
address.
query address
Look up the status and text for the
specified
address. If the status is unknown, a probe is
sent
and an "in progress" status is returned.
SECURITY
The address verification server is not security-
sensitive.
It does not talk to the network, and it does not talk
to
local users. The verify server can run chrooted at
fixed
low privilege.
The address verification server can be coerced to

store
unlimited amounts of garbage. Limiting the cache
size
trades one problem (disk space exhaustion) for another
one
(poor response time to client requests).
DIAGNOSTICS
BUGS
The address verification service is suitable only
for
sites that handle a low mail volume. Verification
probes
add additional traffic to the mail queue and
perform
poorly under high load. Servers may blacklist sites
that
probe excessively, or that probe excessively for non-

exis-
tent recipient addresses.
If the persistent database ever gets corrupted then

the
world comes to an end and human intervention is
needed.
This violates a basic Postfix principle.
Changes to main.cf are not picked up automatically,
as
verify(8) processes are persistent. Use the command
"post-
fix reload" after a configuration change.

See
CACHE CONTROLS
address_verify_map (empty)
Optional lookup table for persistent address
veri-
fication status storage.
address_verify_sender (postmaster)
The sender address to use in address
verification
probes.
address_verify_positive_expire_time (31d)
The time after which a successful probe
expires
from the address verification cache.
address_verify_positive_refresh_time (7d)
The time after which a successful address
verifica-
tion probe needs to be refreshed.
address_verify_negative_cache (yes)

Enable caching of failed address verification

probe
results.
address_verify_negative_expire_time (3d)
The time after which a failed probe expires
from
the address verification cache.
address_verify_negative_refresh_time (3h)
The time after which a failed address
verification
probe needs to be refreshed.
PROBE MESSAGE ROUTING CONTROLS

By default, probe messages are delivered via the
same
route as regular messages. The following parameters
can
be used to override specific message routing mechanisms.
address_verify_relayhost ($relayhost)
Overrides the relayhost parameter setting
for
address_verify_transport_maps ($transport_maps)
Overrides the transport_maps parameter setting
for
address_verify_local_transport ($local_transport)
Overrides the local_transport parameter setting
for
address_verify_virtual_transport ($virtual_transport)
Overrides the virtual_transport parameter
setting

address_verify_relay_transport ($relay_transport)
Overrides the relay_transport parameter setting
for
address_verify_default_transport ($default_transport)
Overrides the default_transport parameter
setting
and
to
a
ipc_timeout (3600s)
information
pro-
cess.
daemon
process.

direc-

tory.
pro-
"smtpd"
SEE ALSO
smtpd(8), Postfix SMTP server
cleanup(8), enqueue Postfix message
README FILES
ADDRESS_VERIFICATION_README, address verification howto
LICENSE
this
software.
HISTORY
AUTHOR(S)
Wietse Venema
P.O. Box 704
VERIFY
(8)

Postfix Per-Client/User/etc. Access Control
Postfix Per-Client/User/etc.
Access Control
Postfix restriction classes

The Postfix SMTP server supports access restrictions such as reject_rbl_client or
reject_unknown_client on the right-hand side of SMTP server access(5) tables. This allows you
to implement different junk mail restrictions for different clients or users.
Having to specify lists of access restrictions for every recipient becomes tedious quickly.
Postfix restriction classes allow you to give easy-to-remember names to groups of UCE
restrictions (such as "permissive", "restrictive", and so on).
The real reason for the existence of Postfix restriction classes is more mundane: you can't
specify a lookup table on the right-hand side of a Postfix access table. This is because Postfix
needs to open lookup tables ahead of time, but the reader probably does not care about these
low-level details.
Example:
smtpd_restriction_classes = restrictive,
permissive
restrictive = reject_unknown_sender_domain
reject_unknown_client ...
permissive = permit
permit_mynetworks
hash:/etc/postfix/recipient_access
http://www.subneural.net/postfix-master/RESTRICTION_CLASS_README.html (1 of 5)01/16/2005 15:46:36

/etc/postfix/recipient_access:
joe@my.domain permissive
jane@my.domain restrictive
With this in place, you can use "restrictive" or "permissive" on the right-hand side of your per-
client, helo, sender, or recipient SMTPD access tables.
The remainder of this document gives examples of how Postfix access restriction classes can
be used to:
● Shield an internal mailing list from outside posters,

● Prevent external access by internal senders.
These questions come up frequently, and the examples hopefully make clear that Postfix
restriction classes aren't really the right solution. They should be used for what they were
designed to do, different junk mail restrictions for different clients or users.
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.
hash:/etc/postfix/access
...the usual stuff...
all@my.domain permit_mynetworks,reject
all@my.hostname 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 the 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.
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 matches my.domain and
subdomains
another.domain OK matches another.domain and
subdomains
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.
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:
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.
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
what map types Postfix supports, use the command postconf -m.
Note: this scheme does not authenticate the user, and therefore it can be bypassed in several

ways:
● By sending mail via a less restrictive mail relay host.
● By sending mail as someone else who does have permission to send mail to off-site
destinations.

Postfix Built-in Content Inspection
Postfix Built-in Content

Inspection
Built-in content inspection introduction

Postfix supports a built-in filter mechanism that examines message header and message body content,
one line at a time, before it is stored in the Postfix queue. The filter is usually implemented with POSIX
or PCRE regular expressions, as described in the header_checks(5) manual page.
The original purpose of the built-in filter is to stop an outbreak of specific email worms or viruses, and it
does this job well. The filter has also helped to block bounced junk email, bounced email from worms or
viruses, and notifications from virus detection systems. Information about this secondary application is
given in the BACKSCATTER_README document.
Because the built-in filter is optimized for stopping specific worms and virus outbreaks, it has limitations
that make it NOT suitable for general junk email and virus detection. For that, you should use one of the
external content inspection methods that are described in the FILTER_README and
SMTPD_PROXY_README documents.
The following diagram gives an over-all picture of how Postfix built-in content inspection works:
Postmaster
notifications
|
v
Network or
Network or - Built-in - Postfix - Delivery -
local
local users > filter > queue > agents >
mailbox
^ |
| v
Undeliverable mail
Forwarded mail
The picture makes clear that the filter works while Postfix is receiving new mail. This means that Postfix
http://www.subneural.net/postfix-master/BUILTIN_FILTER_README.html (1 of 7)01/16/2005 15:46:37

can reject mail from the network without having to return undeliverable mail to the originator address
(which is often spoofed anyway). However, this ability comes at a price: if mail inspection takes too
much time, then the remote client will time out, and the client may send the same message repeatedly.
Topics covered by this document:
● What mail is subjected to header/body checks

● Limitations of Postfix header/body checks
● Preventing daily mail status reports from being blocked
● Configuring header/body checks for mail from outside users only
● Configuring header/body checks for mail to some domains only
What mail is subjected to header/body checks

Postfix header/body checks are implemented by the cleanup(8) server before it injects mail into the
incoming queue. The diagram below zooms in on the cleanup(8) server, and shows that this server
handles mail from many different sources. In order to keep the diagram readable, the sources of
postmaster notifications are not shown, because they can be produced by many Postfix daemon
processes.
bounce(8)
(undeliverable)
smtpd(8) |
(network) \ v
qmqpd(8) -\ - incoming
cleanup(8)
(network) -/ > queue
pickup(8) / ^
(local) |
local(8)
(forwarded)
For efficiency reasons, only mail that enters from outside of Postfix is inspected with header/body
checks. It would be inefficient to filter already filtered mail again, and it would be undesirable to block
postmaster notifications. The table below summarizes what mail is and is not subject to header/body
checks.
Header/body
Message type Source
checks?
Undeliverable bounce
No
mail (8)
Network mail smtpd(8) Configurable

qmqpd
Network mail Configurable
(8)
pickup
Local submission Configurable
(8)
Local forwarding local(8) No
Postmaster notice many No
How does Postfix decide what mail needs to be filtered? It would be clumsy to make the decision in the
cleanup(8) server, as this program receives mail from so many different sources. Instead, header/body
checks are requested by the source. Examples of how to turn off header/body checks for mail received
with smtpd(8), qmqpd(8) or pickup(8) are given below under "Configuring header/body checks for mail
from outside users only" and "Configuring header/body checks for mail to some domains only".
Limitations of Postfix header/body checks

● Header/body checks do not decode message headers or message body content. For example, if
text in the message body is BASE64 encoded (RFC 2045) then your regular expressions will have
to match the BASE64 encoded form. Likewise, message headers with encoded non-ASCII
characters (RFC 2047) need to be matched in their encoded form.
● Header/body checks cannot filter on a combination of message headers or body lines. Header/
body checks examine content one message header at a time, or one message body line at a time,
and cannot carry a decision over to the next message header or body line.
● Header/body checks cannot depend on the recipient of a message.
❍ One message can have multiple recipients, and all recipients of a message receive the same
treatment. Workarounds have been proposed that involve selectively deferring some
recipients of multi-recipient mail, but that results in poor SMTP performance and does not
work for non-SMTP mail.
❍ Some sources of mail send the headers and content ahead of the recipient information. It
would be inefficient to buffer up an entire message before deciding if it needs to be
filtered, and it would be clumsy to filter mail and to buffer up all the actions until it is
known whether those actions need to be executed.
● Despite warnings, some people try to use the built-in filter feature for general junk email and/or
virus blocking, using hundreds or even thousands of regular expressions. This can result in
catastrophic performance failure. The symptoms are as follows:
❍ The cleanup(8) processes use up all available CPU time in order to process the regular
expressions, and/or they use up all available memory so that the system begins to swap.

This slows down all incoming mail deliveries.
❍ As Postfix needs more and more time to receive an email message, the number of
simultaneous SMTP sessions increases to the point that the SMTP server process limit is
reached.
❍ While all SMTP server processes are waiting for the cleanup(8) servers to finish, new
SMTP clients have to wait until an SMTP server process becomes available. This causes
mail deliveries to time out before they have even begun.
The remedy for this type of performance problem is simple: don't use header/body checks for
general junk email and/or virus blocking, and don't filter mail before it is queued. When
performance is a concern, use an external content filter that runs after mail is queued, as described
in the FILTER_README document.
Preventing daily mail status reports from being blocked

The following is quoted from Jim Seymour's Pflogsumm FAQ at http://jimsun.linxnet.com/downloads/
pflogsumm-faq.txt. Pflogsumm is a program that analyzes Postfix logs, including the logging from
rejected mail. If these logs contain text that was rejected by Postfix body_checks patterns, then the
logging is also likely to be rejected by those same body_checks patterns. This problem does not exist
with header_checks patterns, because those are not applied to the text that is part of the mail status
report.
You configure Postfix to do body checks, Postfix does its thing, Pflogsumm reports it and
Postfix catches the same string in the Pflogsumm report. There are several solutions to
this.
Wolfgang Zeikat contributed this:
#!/usr/bin/perl
use MIME::Lite;
### Create a new message:

$msg = MIME::Lite->new(
From => 'your@send.er',
To => 'your@recipie.nt',
# Cc => 'some@other.com, some@more.com',
Subject => 'pflogsumm',
Date => `date`,
Type => 'text/plain',
Encoding => 'base64',
Path => '/tmp/pflogg',
);

$msg->send;
Where "/tmp/pflogg" is the output of Pflogsumm. This puts Pflogsumm's output in a

base64 MIME attachment.
Note by Wietse: if you run this on a machine that is accessible by untrusted users, it is safer to store the
Pflogsumm report in a directory that is not world writable.
In a follow-up to a thread in the postfix-users mailing list, Ralf Hildebrandt noted:
"mpack does the same thing."
And it does. Which tool one should use is a matter of preference.
Other solutions involve additional body_checks rules that make exceptions for daily mail status reports,
but this is not recommended. Such rules slow down all mail and complicate Postfix maintenance.
Configuring header/body checks for mail from outside users

only
The following information applies to Postfix 2.1. Earlier Postfix versions do not support the
receive_override_options feature.
The easiest approach is to configure ONE Postfix instance with multiple SMTP server IP addresses in
master.cf:
● Two SMTP server IP addresses for mail from inside users only, with header/body filtering turned
off, and a local mail pickup service with header/body filtering turned off.
#
==================================================================
command
#
==================================================================
1.2.3.4:smtp inet n - n - -
smtpd
-o receive_override_options=no_header_body_checks
127.0.0.1:smtp inet n - n - -
smtpd

pickup fifo n - n 60 1
pickup
● One SMTP server address for mail from outside users with header/body filtering turned on via
main.cf.
#
=================================================================
command
#
=================================================================
1.2.3.5:smtp inet n - n - -
smtpd
Configuring header/body checks for mail to some domains only

The following information applies to Postfix 2.1. Earlier Postfix versions do not support the
receive_override_options feature.
If you are MX service provider and want to apply disable head/body checks for some domains, you can
configure ONE Postfix instance with multiple SMTP server IP addresses in master.cf. Each address
provides a different service.
#
=================================================================
maxproc command
#
=================================================================
# SMTP service for domains with header/body checks
turned on.
- smtpd
# SMTP service for domains with header/body checks

turned off.
- smtpd

Once this is set up you can configure MX records in the DNS that route each domain to the proper
SMTP server instance.

Postfix manual - mysql_table(5)
MYSQL_TABLE(5) MYSQL_TABLE
(5)
NAME
mysql_table - Postfix MySQL client configuration
SYNOPSIS
postmap -q "string" mysql:/etc/postfix/filename
postmap -q - mysql:/etc/postfix/filename <inputfile
DESCRIPTION
address
dbm
or db format.

MySQL
databases. In order to use MySQL lookups, define a
MySQL
source as a lookup table in main.cf, for example:
alias_maps = mysql:/etc/mysql-aliases.cf
The file /etc/postfix/mysql-aliases.cf has the same

format
parame-
ters described below.
ALTERNATIVE CONFIGURATION
For compatibility with other Postfix lookup tables,
MySQL
parameters can also be defined in main.cf. In order to
do
that, specify as MySQL source a name that doesn't
begin
with a slash or a dot. The MySQL parameters will then
be
accessible as the name you've given the source in its
http://www.subneural.net/postfix-master/mysql_table.5.html (1 of 5)01/16/2005 15:46:37

def-
inition, an underscore, and the name of the
parameter.
For example, if the map is specified as "mysql:
mysqlname",
the parameter "hosts" below would be defined in main.cf
as
"mysqlname_hosts".
Note: with this form, the passwords for the MySQL

sources
are written in main.cf, which is normally world-
readable.
Support for this form will be removed in a future
Postfix
version.
LIST MEMBERSHIP
When using SQL to store lists such as $mynetworks,
$mydes-
tination, $relay_domains, $local_recipient_maps, etc.,
it
is important to understand that the table must store
each
list member as a separate key. The table lookup
verifies
the *existence* of the key. See "Postfix lists
versus
tables" in the DATABASE_README document for a
discussion.

domains
addresses
in $mynetworks.

with
an arbitrary value. With SQL databases it is not
uncommon
to return the key itself or a constant value.

MYSQL PARAMETERS
hosts The hosts that Postfix will try to connect to
and
query from. Specify unix: for UNIX domain
sockets,
inet: for TCP connections (default). Example:
hosts = host1.some.domain host2.some.domain
hosts = unix:/file/name
The hosts are tried in random order, with all

con-
nections over UNIX domain sockets being
tried
before those over TCP. The connections are
auto-
matically closed after being idle for about
1
minute, and are re-opened as necessary.
Postfix
versions 2.0 and earlier do not randomize the
host
order.
NOTE: if you specify localhost as a hostname

(even
if you prefix it with inet:), MySQL will connect
to
the default UNIX domain socket. In order
to
instruct MySQL to connect to localhost over TCP
you
have to specify
hosts = 127.0.0.1
user, password
The user name and password to log into the
mysql
server. Example:
user = someone
password = some_password
dbname The database name on the servers. Example:

dbname = customer_database
The following parameters are used to fill in a

SELECT
query template of the form:
select [select_field] from [table] where
[where_field] = '$lookup' [additional_conditions]
$lookup contains the search string, and is escaped so

if
it contains single quotes or other odd characters, it
will
not cause a parse error, or worse, a security problem.
select_field
The SQL "select" parameter. Example:
select_field = forw_addr
table The SQL "select .. from" table name. Example:

table = mxaliases
where_field
The SQL "select .. where" parameter. Example:
where_field = alias
additional_conditions
Additional conditions to the SQL query. Example:
additional_conditions = and status = 'paid'
SEE ALSO
postmap(1), Postfix lookup table maintenance
ldap_table(5), LDAP lookup tables
pgsql_table(5), PostgreSQL lookup tables
README FILES
MYSQL_README, Postfix MYSQL client guide
LICENSE
this

software.
HISTORY
MySQL support was introduced with Postfix version 1.0.
AUTHOR(S)
Original implementation by:
Scott Cotton, Joshua Marcus
IC Group, Inc.
Further enhancements by:

Liviu Daia
Institute of Mathematics of the Romanian Academy
P.O. BOX 1-764
RO-014700 Bucharest, ROMANIA
MYSQL_TABLE
(5)

Postfix manual - pgsql_table(5)
PGSQL_TABLE(5) PGSQL_TABLE
(5)
NAME
pgsql_table - Postfix PostgreSQL client configuration
SYNOPSIS
postmap -q "string" pgsql:/etc/postfix/filename
postmap -q - pgsql:/etc/postfix/filename <inputfile
DESCRIPTION
address
dbm
or db format.

Post-
greSQL databases. In order to use PostgreSQL
lookups,
define a PostgreSQL source as a lookup table in main.
cf,
for example:
alias_maps = pgsql:/etc/pgsql-aliases.cf
The file /etc/postfix/pgsql-aliases.cf has the same

format
parame-
ters described below.
ALTERNATIVE CONFIGURATION
For compatibility with other Postfix lookup tables,
Post-
greSQL parameters can also be defined in main.cf.
In
order to do that, specify as PostgreSQL source a name
that
doesn't begin with a slash or a dot. The
http://www.subneural.net/postfix-master/pgsql_table.5.html (1 of 7)01/16/2005 15:46:38

PostgreSQL
parameters will then be accessible as the name
you've
given the source in its definition, an underscore, and
the
name of the parameter. For example, if the map is
speci-
fied as "pgsql:pgsqlname", the parameter "hosts"
below
would be defined in main.cf as "pgsqlname_hosts".
Note: with this form, the passwords for the

PostgreSQL
sources are written in main.cf, which is normally
world-
readable. Support for this form will be removed in
a
future Postfix version.
LIST MEMBERSHIP
When using SQL to store lists such as $mynetworks,
$mydes-
tination, $relay_domains, $local_recipient_maps, etc.,
it
is important to understand that the table must store
each
list member as a separate key. The table lookup
verifies
the *existence* of the key. See "Postfix lists
versus
tables" in the DATABASE_README document for a
discussion.

domains
addresses
in $mynetworks.

with
an arbitrary value. With SQL databases it is not

uncommon
to return the key itself or a constant value.
PGSQL PARAMETERS
hosts The hosts that Postfix will try to connect to
and
query from. Specify unix: for UNIX-domain
sockets,
inet: for TCP connections (default). Example:
hosts = unix:/file/name
The hosts are tried in random order, with all

con-
nections over UNIX domain sockets being
tried
before those over TCP. The connections are
auto-
matically closed after being idle for about
1
minute, and are re-opened as necessary.
NOTE: the unix: and inet: prefixes are accepted

for
backwards compatibility reasons, but are
actually
ignored. The PostgreSQL client library will
always
try to connect to an UNIX socket if the name
starts
with a slash, and will try a TCP connection
other-
wise.
user, password
The user name and password to log into the
pgsql
server. Example:
user = someone
dbname The database name on the servers. Example:


The following parameters can be used to fill in a

SELECT
template statement of the form:
select [select_field] from [table] where
[where_field] = '$lookup' [additional_conditions]
$lookup contains the search string, and is escaped so

if
it contains single quotes or other odd characters, it
will
not cause a parse error, or worse, a security problem.
select_field
The SQL "select" parameter. Example:
table The SQL "select .. from" table name. Example:

table = mxaliases
where_field
The SQL "select .. where" parameter. Example:
where_field = alias
additional_conditions
Additional conditions to the SQL query. Example:
The following parameters provide ways to override

the
default SELECT statement. Setting them will
instruct
Postfix to ignore the above table,
select_field,
where_field and additional_conditions parameters:
query This parameter specifies a complete SQL

query.
Example:
query = select forw_addr from mxaliases where
alias = '%s' and status = 'paid'


expan-
sions:
%s This is replaced by the input key.

Quoting
is used to make sure that the input key
does
not add unexpected metacharacters.
%u When the input key is an address of the

form
user@domain, %u is replaced by the
quoted
local part of the address. If no domain
is
specified, %u is replaced by the
entire
search string.
%d When the input key is an address of the

form
user@domain, %d is replaced by the
quoted
domain part of the address. When the
input
key has no domain qualifier, %d is
replaced
by the entire search string.
select_function
This parameter specifies a database function
name.
Example:
select_function = my_lookup_user_alias
This is equivalent to:

query = select my_lookup_user_alias('%s')
and overrides both the query parameter and

the
table-related fields above.

As of June 2002, if the function returns a

single
row and a single column AND that value is
NULL,
then the result will be treated as if the key
was
not in the dictionary.
Future versions will allow functions to

return
result sets.
SEE ALSO
ldap_table(5), LDAP lookup tables
mysql_table(5), MySQL lookup tables
README FILES
PGSQL_README, Postfix PostgreSQL client guide
LICENSE
this
software.
HISTORY
PgSQL support was introduced with Postfix version 2.1.
AUTHOR(S)
Based on the MySQL client by:
Scott Cotton, Joshua Marcus
IC Group, Inc.
Ported to PostgreSQL by:

Aaron Sethman
Further enhanced by:

Liviu Daia
Institute of Mathematics of the Romanian Academy
P.O. BOX 1-764

RO-014700 Bucharest, ROMANIA
PGSQL_TABLE
(5)

Postfix manual - proxymap(8)
PROXYMAP(8) PROXYMAP
(8)
NAME
proxymap - Postfix lookup table proxy server
SYNOPSIS
proxymap [generic Postfix daemon options]
DESCRIPTION
The proxymap server provides read-only table lookup
ser-
vice to Postfix processes. The purpose of the service is:
o To overcome chroot restrictions. For example,

a
chrooted SMTP server needs access to the
system
passwd file in order to reject mail for non-
exis-
tent local addresses, but it is not practical
to
maintain a copy of the passwd file in the
chroot
jail. The solution:
proxy:unix:passwd.byname $alias_maps
o To consolidate the number of open lookup tables

by
sharing one open table among multiple
processes.
For example, making mysql connections from
every
Postfix daemon process results in "too many
connec-
tions" errors. The solution:
virtual_alias_maps =
proxy:mysql:/etc/postfix/virtual_alias.cf
http://www.subneural.net/postfix-master/proxymap.8.html (1 of 5)01/16/2005 15:46:38

The total number of connections is limited by

the
number of proxymap server processes.
The proxymap server implements the following requests:
open maptype:mapname flags

Open the table with type maptype and name
mapname,
as controlled by flags. The reply includes the
map-
type dependent flags (to distinguish a fixed
string
table from a regular expression table).
lookup maptype:mapname flags key

Look up the data stored under the requested
key.
The reply is the request completion status
code
(below) and the lookup result value. The
map-
type:mapname and flags are the same as with
the
open request.
There is no close command, nor are tables

implicitly
closed when a client disconnects. The purpose is to
share
tables among multiple client processes.
SERVER PROCESS MANAGEMENT

proxymap servers run under control by the Postfix
master
server. Each server can handle multiple simultaneous
con-
nections. When all servers are busy while a client
con-
nects, the master creates a new proxymap server
process,
provided that the process limit is not exceeded.

Each
server terminates after serving at least $max_use
clients
or after $max_idle seconds of idle time.
SECURITY
The proxymap server opens only tables that are
approved
via the proxy_read_maps configuration parameter, does
not
talk to users, and can run at fixed low
privilege,
chrooted or not. However, running the proxymap
server
chrooted severely limits usability, because it can
open
only chrooted tables.
The proxymap server is not a trusted daemon process,

and
must not be used to look up sensitive information such
as
user or group IDs, mailbox file/directory names or
exter-
nal commands.
DIAGNOSTICS
BUGS
The proxymap server provides service to multiple
clients,
and must therefore not be used for tables that have
high-
latency lookups.
On busy mail systems a long time may pass before
prox-
ymap(8) relevant changes to main.cf are picked up. Use
the


See

and
to
a
ipc_timeout (3600s)
information
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a
pro-
cess.
daemon

process.
proxy_read_maps (see 'postconf -d' output)

The lookup tables that the proxymap(8) server
is
allowed to access.
SEE ALSO
README FILES
LICENSE
this
software.
HISTORY
The proxymap service was introduced with Postfix 2.0.
AUTHOR(S)
Wietse Venema
P.O. Box 704
PROXYMAP
(8)

Postfix Content Inspection
Postfix supports three content inspection methods, ranging from light-weight one-line-at-a-time
scanning before mail is queued, to heavy duty machinery that does sophisticated content
analysis after mail is queued. Each approach serves a different purpose.
built-in, light-weight, real-time
This method inspects mail BEFORE it is stored in the queue, and uses Postfix's built-in
message header and message body inspection. Although the main purpose is to stop a
specific flood of mail from worms or viruses, it is also useful to block a flood of
bounced junk email and email notifications from virus detection systems. The built-in
regular expressions are not meant to implement general SPAM and virus detection. For
that, you should use one of the content inspection methods described below. Details are
described in the BUILTIN_FILTER_README and BACKSCATTER_README
documents.
external, heavy-weight, not real time
This method inspects mail AFTER it is stored in the queue, and uses standard protocols
such as SMTP or "pipe to command and wait for exit status". After-queue inspection
allows you to use content filters of arbitrary complexity without causing timeouts while
receiving mail, and without running out of memory resources under a peak load. Details
of this approach are in the FILTER_README document.
external, medium-weight, real-time
This method inspects mail BEFORE it is stored in the queue, and uses the SMTP
protocol. Although this approach appears to be the more attractive one, it really
combines the worst of the other two. Because mail is inspected before it is queued,
content inspection software must finish in a limited amount of time, and must run in a
limited amount of memory. If content inspection needs too much time then incoming
mail deliveries will time out, and if content inspection needs too much memory then
http://www.subneural.net/postfix-master/CONTENT_INSPECTION_README.html (1 of 2)01/16/2005 15:46:38

software will crash under a peak load. Before-queue inspection limits the peak load that
your system can handle, and limits the sophistication of the content filter that you can
use. Details are in the SMTPD_PROXY_README document. This approach is
available only with Postfix version 2.1 and later.
The more sophisticated content filtering software is not built into Postfix for good reasons:
writing an MTA requires different skills than writing a SPAM or virus killer. Postfix
encourages the use of external filters and standard protocols because this allows you to choose
the best MTA and the best content inspection software for your purpose. Information about
external content inspection software can be found on the Postfix website at http://www.postfix.
org/, and on the postfix-users@postfix.org mailing list.
http://www.subneural.net/postfix-master/CONTENT_INSPECTION_README.html (2 of 2)01/16/2005 15:46:38

Postfix Backscatter Howto
Overview
This document describes features that require Postfix version 2.0 or later.
● What is backscatter mail?

● How do I block backscatter mail to random recipient addresses?
● How do I block backscatter mail to real recipient addresses?
❍ Blocking backscatter mail with forged HELO information
❍ Blocking backscatter mail with forged sender information
❍ Blocking backscatter mail with other forged information
❍ Blocking backscatter mail from virus scanners
What is backscatter mail?

When a spammer or worm sends mail with forged sender addresses, innocent sites are flooded
with undeliverable mail notifications. This is called backscatter mail, and if your system is
flooded then you will find out soon enough.
How do I block backscatter mail to random recipient

addresses?
If your machine receives backscatter mail to random addresses, configure Postfix to reject all
mail for non-existent recipients as described in the LOCAL_RECIPIENT_README and
STANDARD_CONFIGURATION_README documentation.
If your machine runs Postfix 2.0 and earlier, disable the "pause before reject" feature in the
http://www.subneural.net/postfix-master/BACKSCATTER_README.html (1 of 6)01/16/2005 15:46:39

SMTP server. If your system is under stress then it should not waste time.
# Not needed with Postfix 2.1 and later.
smtpd_error_sleep_time = 0
How do I block backscatter mail to real recipient

addresses?
When backscatter mail passes the "unknown recipient" barrier, there still is no need to despair.
Many mail systems are kind enough to attach the message headers of the undeliverable mail in
the non-delivery notification. These message headers contain information that you can use to
recognize and block forged mail.
Blocking backscatter mail with forged HELO information
Although my email address is "wietse@porcupine.org", all my mail systems announce

themselves with the SMTP HELO command as "hostname.porcupine.org". Thus, if returned
mail has a Received: message header like this:
Received: from porcupine.org ...
Then I know that this is almost certainly forged mail (almost; see next section for the fly in the
ointment). Mail that is really sent by my systems looks like this:
Received: from hostname.porcupine.org ...
For the same reason the following message headers are very likely to be the result of forgery:
Received: from host.example.com ([1.2.3.4]

helo=porcupine.org) ...
Received: from [1.2.3.4] (port=12345 helo=porcupine.
org) ...
Received: from host.example.com (HELO porcupine.
org) ...
Received: from host.example.com (EHLO porcupine.
org) ...
Another frequent sign of forgery is the Message-ID: header. My systems produce a Message-
ID: of <stuff@hostname.porcupine.org>. The following are forgeries, especially the first one:

Message-ID: <1cb479435d8eb9.2beb1.qmail@porcupine.org>
Message-ID: <yulszqocfzsficvzzju@porcupine.org>
To block such backscatter I use header_checks and body_checks patterns like this:
/^Received: +from +(porcupine\.org) +/
reject forged client name in Received:
header: $1
/^Received: +from +[^ ]+ +$([^ ]+ +[he]+lo=|[he]
+lo +)(porcupine\.org)$/
header: $2
/^Message-ID:.*@(porcupine\.org)/
reject forged domain name in Message-ID:
header: $1
/^[> ]*Received: +from +(porcupine\.org) /
header: $1
/^[> ]*Received: +from +[^ ]+ +$([^ ]+ +[he]+lo=|
[he]+lo +)(porcupine\.org)$/
header: $2
/^[> ]*Message-ID:.*@(porcupine\.org)/
reject forged domain name in Message-ID:
header: $1
Notes:
● The example is simplified for educational purposes. In reality my patterns list multiple
domain names, as "(domain|domain|...)".
● The "\." matches "." literally. Without the "\", the "." would match any character.
● The "$" and "$" match "(" and ")" literally. Without the "\", the "(" and ")" would

be grouping operators.
Caveats
Netscape Messenger (and reportedly, Mozilla) sends a HELO name that is identical to the
sender address domain part. If you have such clients then the above patterns would block
legitimate email.
My network has only one such machine, and to prevent its mail from being blocked I have
configured it to send mail as user@hostname.porcupine.org. On the Postfix server, a canonical
mapping translates this temporary address into user@porcupine.org.
/etc/postfix/canonical:
@hostname.porcupine.org @porcupine.org
This is of course practical only when you have very few systems that send HELO commands
like this, and when you never have to send mail to a user on such a host.
An alternative would be to remove the hostname from "hostname.porcupine.org" with address

masquerading, as described in the ADDRESS_REWRITING_README document.
Blocking backscatter mail with forged sender information
Like many people I still have a few email addresses in domains that I used in the past. Mail for
those addresses is forwarded to my current address. Most of the backscatter mail that I get
claims to be sent from these addresses. Such mail is obviously forged and is very easy to stop.
/^(From|Return-Path):.*[[:<:]](user@domain\.tld)
[[:>:]]/
reject forged sender address in $1: header: $2
/^[> ]*(From|Return-Path):.*[[:<:]](user@domain\.

tld)[[:>:]]/
reject forged sender address in $1: header: $2
Notes:
● The example is simplified for educational purposes. In reality, my patterns list multiple
email addresses as "(user1@domain1\.tld|user2@domain2\.tld)".
● The "[[:<:]]" and "[[:>:]]" match the beginning and end of a word, respectively.
On some systems you should specify "\<" and "\>" instead. For details see your
system documentation.
● The "\." matches "." literally. Without the "\", the "." would match any character.
Blocking backscatter mail with other forged information
Another sign of forgery can be found in the IP address that is recorded in Received: headers
next to your HELO host or domain name. This information must be used with care, though.
Some mail servers are behind a network address translator and never see the true client IP
address.
Blocking backscatter mail from virus scanners
With all the easily recognizable forgeries eliminated, there is one category of backscatter mail
that remains, and that is notifications from virus scanner software. Unfortunately, some virus
scanning software doesn't know that viruses forge sender addresses. To make matters worse,
the software also doesn't know how to report a mail delivery problem, so that we cannot use the
above techniques to recognize forgeries.
Recognizing virus scanner mail is an error prone process, because there is a lot of variation in
report formats. The following is only a small example of message header patterns. For a large
collection of header and body patterns that recognize virus notification email, see http://www.
dkuug.dk/keld/virus/ or http://www.t29.dk/antiantivirus.txt.
/^Subject: *Your email contains VIRUSES/ DISCARD
virus notification
/^Content-Disposition:.
*VIRUS1_DETECTED_AND_REMOVED/
DISCARD virus notification
/^Content-Disposition:.*VirusWarning.txt/ DISCARD
virus notification

A plea to virus or spam scanner operators: please do not make the problem worse by sending
return mail to forged sender addresses. You're only harassing innocent people. If you must
return mail to the purported sender, please return the full message headers, so that the sender
can defend against forgeries.

Postfix Standard Configuration Examples
Postfix Standard
Configuration Examples

This document presents a number of typical Postfix configurations. This document should be
reviewed after you have followed the basic configuration steps as described in the
BASIC_CONFIGURATION_README document. In particular, do not proceed here if you
don't already have Postfix working for local mail submission and for local mail delivery.
The first part of this document presents standard configurations that each solve one specific
problem.
● Postfix on a stand-alone Internet host

● Postfix on a null client
● Postfix on a local network
● Postfix email firewall/gateway
The second part of this document presents additional configurations for hosts in specific
environments.
● Delivering some but not all accounts locally

● Running Postfix behind a firewall
● Configuring Postfix as MX host for a remote site
● Postfix on a dialup machine
● Postfix on hosts without a real hostname
Postfix on a stand-alone Internet host

Postfix should work out of the box without change on a stand-alone machine that has direct
http://www.subneural.net/postfix-master/STANDARD_CONFIGURATION_README.html (1 of 14)01/16/2005 15:46:40

Internet access. At least, that is how Postfix installs when you download the Postfix source
code via http://www.postfix.org/.
You can use the command "postconf -n" to find out what settings are overruled by your main.
cf. Besides a few pathname settings, few parameters should be set on a stand-alone box,
beyond what is covered in the BASIC_CONFIGURATION_README document:
# Optional: send mail as user@domainname instead
of user@hostname.
#myorigin = $mydomain
# Optional: specify NAT/proxy external address.

#proxy_interfaces = 1.2.3.4
# Don't relay mail from other hosts.

mynetworks_style = host
relay_domains =
See also the section "Postfix on hosts without a real hostname" if this is applicable to your
configuration.
Postfix on a null client

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, IMAP or NFS for mailbox
access.
In this example we assume that the Internet domain name is "example.com" and that the
machine is named "nullclient.example.com". As usual, the examples show only parameters that
are not left at their default settings.
2 myorigin = $mydomain
3 relayhost = $mydomain
4 inet_interfaces = 127.0.0.1
5 local_transport = error:local delivery is
disabled
6

8 Comment out the local delivery agent entry
Translation:
● Line 2: Send mail as "user@example.com" (instead of "user@nullclient.example.com"),

so that nothing ever has a reason to send mail to "user@nullclient.example.com".
● Line 3: Forward all mail to the mail server that is responsible for the "example.com"
domain. This prevents mail from getting stuck on the null client if it is turned off while
some remote destination is unreachable.
● Line 4: Do not accept mail from the network.
● Lines 5-8: Disable local mail delivery. All mail goes to the mail server as specified in
line 3.
Postfix on a local network

This section describes a local area network environment of one main server and multiple other
systems that send and receive email. As usual we assume that the Internet domain name is
"example.com". All systems are configured to send mail as "user@example.com", and all
systems receive mail for "user@hostname.example.com". The main server also receives mail
for "user@example.com". We call this machine by the name of mailhost.example.com.
A drawback of sending mail as "user@example.com" is that mail for "root" and other system
accounts is also sent to the central mailhost. See the section "Delivering some but not all
accounts locally" below for possible solutions.
As usual, the examples show only parameters that are not left at their default settings.
First we present the non-mailhost configuration, because it is the simpler one. This machine
sends mail as "user@example.com" and is final destination for "user@hostname.example.
com".
3 mynetworks = 127.0.0.0/8 10.0.0.0/24
4 relay_domains =
5 # Optional: forward all non-local mail to
mailhost

6 #relayhost = $mydomain
Translation:
● Line 2: Send mail as "user@example.com".
● Line 3: Specify the trusted networks.
● Line 4: This host does not relay mail from untrusted networks.
● Line 6: This is needed if no direct Internet access is available. See also below, "Postfix
behind a firewall".
Next we present the mailhost configuration. This machine sends mail as "user@example.com"
and is final destination for "user@hostname.example.com" as well as "user@example.com".
1 DNS:
2 example.com IN MX 10 mailhost.example.
com.
3
6 mydestination = $myhostname localhost.
$mydomain localhost $mydomain
7 mynetworks = 127.0.0.0/8 10.0.0.0/24
8 relay_domains =
9 # Optional: forward all non-local mail to
firewall
10 #relayhost = [firewall.example.com]
Translation:
● Line 2: Send mail for the domain "example.com" to the machine mailhost.example.com.
Remember to specify the "." at the end of the line.
● Line 5: Send mail as "user@example.com".
● Line 6: This host is the final mail destination for the "example.com" domain, in addition
to the names of the machine itself.

● Line 7: Specify the trusted networks.
● Line 8: This host does not relay mail from untrusted networks.
● Line 10: This is needed only when the mailhost has to forward non-local mail via a mail
server on a firewall. The [] forces Postfix to do no MX record lookups.
In an environment like this, users access their mailbox in one or more of the following ways:
● Mailbox access via NFS or equivalent.
● Mailbox access via POP or IMAP.
● Mailbox on the user's preferred machine.
In the latter case, each user has an alias on the mailhost that forwards mail to her preferred
machine:
/etc/aliases:
joe: joe@joes.preferred.machine
jane: jane@janes.preferred.machine
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".
Execute the command "newaliases" whenever you change the aliases file.
Postfix email firewall/gateway

The idea is to set up a Postfix email firewall/gateway that forwards mail for "example.com" to
an inside gateway machine but rejects mail for "anything.example.com". There is only one
problem: with "relay_domains = example.com", the firewall normally also accepts mail for
"anything.example.com". That would not be right.
Note: this example requires Postfix version 2.0 and later. To find out what Postfix version you
have, execute the command "postconf mail_version".
The solution is presented in multiple parts. This first part gets rid of local mail delivery on the
firewall, making the firewall harder to break.

2 myorigin = example.com
3 mydestination =
4 local_recipient_maps =
5 local_transport = error:local mail delivery is
disabled
6
8 Comment out the local delivery agent
Translation:
● Line 2: Send mail from this machine as "user@example.com", so that no reason exists
to send mail to "user@firewall.example.com".
● Lines 3-8: Disable local mail delivery on the firewall machine.
For the sake of technical correctness the firewall must be able to receive mail for postmaster@
[firewall ip address]. Reportedly, some things actually expect this ability to exist. The second
part of the solution therefore adds support for postmaster@[firewall ip address], and as a bonus
we do abuse@[firewall ip address] as well. All the mail to these two accounts is forwarded to
an inside address.
3
5 postmaster postmaster@example.com
6 abuse abuse@example.com
Translation:
● Because mydestination is empty (see the previous example), only address literals
matching $inet_interfaces or $proxy_interfaces are deemed local. So "localpart@[a.d.d.
r]" can be matched as simply "localpart" in canonical(5) and virtual(5). This avoids the
need to specify firewall IP addresses into Postfix configuration files.
The last part of the solution does the email forwarding, which is the real purpose of the firewall
email function.

2 mynetworks = 127.0.0.0/8 12.34.56.0/24
3 relay_domains = example.com
4 parent_domain_matches_subdomains =
5 debug_peer_list smtpd_access_maps
7 permit_mynetworks reject_unauth_destination
8
9 relay_recipient_maps = hash:/etc/postfix/
relay_recipients
10 transport_maps = hash:/etc/postfix/transport
11
12 /etc/postfix/relay_recipients:
13 user1@example.com x
14 user2@example.com x
15 . . .
16
17 /etc/postfix/transport:
18 example.com smtp:[inside-gateway.example.com]
Translation:
● Lines 1-7: Accept mail from local systems in $mynetworks, and accept mail from
outside for "user@example.com" but not for "user@anything.example.com". The magic
is in lines 4-5.
● Lines 9, 12-14: Define the list of valid addresses in the "example.com" domain that can
receive mail from the Internet. This prevents the mail queue from filling up with
undeliverable MAILER-DAEMON messages. If you can't maintain a list of valid
recipients then you must specify "relay_recipient_maps =" (that is, an empty value), or
you must specify an "@example.com x" wild-card in the relay_recipients table.
● Lines 10, 17-18: Route mail for "example.com" to the inside gateway machine. The []
forces Postfix to do no MX lookup.
what lookup tables Postfix supports, use the command "postconf -m".
Execute the command "postmap /etc/postfix/relay_recipients" whenever you change the

relay_recipients table.

Execute the command "postmap /etc/postfix/transport" whenever you change the transport
table.
Delivering some but not all accounts locally

A drawback of sending mail as "user@example.com" (instead of "user@hostname.example.
com") is that mail for "root" and other system accounts is also sent to the central mailhost. In
order to deliver such accounts locally, you can set up virtual aliases as follows:
3
5 root root@localhost
6 . . .
Translation:
● Line 5: As described in the virtual(5) manual page, the bare name "root" matches
"root@site" when "site" is equal to $myorigin, when "site" is listed in $mydestination,
or when it matches $inet_interfaces or $proxy_interfaces.
In some installations, there may be separate instances of Postfix processing inbound and
outbound mail on a multi-homed firewall. The inbound Postfix instance has an SMTP server
listening on the external firewall interface, and the outbound Postfix instance has an SMTP
server listening on the internal interface. In such a configuration is it is tempting to configure
$inet_interfaces in each instance with just the corresponding interface address.
In most cases using inet_interaces in this way will not work, because as documented in the
$inet_interfaces reference manual, the smtp(8) delivery agent will also use the specified
interface address as the source address for outbound connections and will be unable to reach
hosts on "the other side" of the firewall. The symptoms are that the firewall is unable to
connect to hosts that are in fact up. See the inet_interfaces parameter documentation for
suggested work-arounds.
Running Postfix behind a firewall

The simplest way to set up Postfix on a host behind a firewalled network is to send all mail to a
gateway host, and to let that mail host take care of internal and external forwarding. Examples

of that are shown in the local area network section above. A more sophisticated approach is to
send only external mail to the gateway host, and to send intranet mail directly. That's what
Wietse does at work.
Note: this example requires Postfix version 2.0 and later. To find out what Postfix version you
have, execute the command "postconf mail_version".
The following example presents additional configuration. You need to combine this with basic
configuration information as discussed the first half of this document.
3 relayhost =
4 # Optional for a machine that isn't "always on"
5 #fallback_relay = [gateway.example.com]
6
8 # Internal delivery.
9 example.com :
10 .example.com :
11 # External delivery.
12 * smtp:[gateway.example.com]
Translation:
● Lines 2, 7-12: Request that intranet mail is delivered directly, and that external mail is
given to a gateway. Obviously, this example assumes that the organization uses DNS
MX records internally. The [] forces Postfix to do no MX lookup.
● Line 3: IMPORTANT: do not specify a relayhost in main.cf.
● Line 5: This prevents mail from being stuck in the queue when the machine is turned
off. Postfix tries to deliver mail directly, and gives undeliverable mail to a gateway.
Execute the command "postmap /etc/postfix/transport" whenever you edit the transport table.
Configuring Postfix as MX host for a remote site

This section presents additional configuration. You need to combine this with basic
When your system is SECONDARY MX host for a remote site this is all you need:
1 DNS:
2 the.backed-up.domain.tld IN MX 100
your.machine.tld.
3
5 relay_domains = . . . the.backed-up.domain.tld
7 permit_mynetworks reject_unauth_destination
8
9 # You must specify your NAT/proxy external
address.
10 #proxy_interfaces = 1.2.3.4
11
12 relay_recipient_maps = hash:/etc/postfix/
relay_recipients
13
14 /etc/postfix/relay_recipients:
15 user1@the.backed-up.domain.tld x
16 user2@the.backed-up.domain.tld x
17 . . .
When your system is PRIMARY MX host for a remote site you need the above, plus:
20
22 the.backed-up.domain.tld relay:[their.
mail.host.tld]
Important notes:
● Do not list the.backed-up.domain.tld in mydestination.
● Do not list the.backed-up.domain.tld in virtual_alias_domains.

● Do not list the.backed-up.domain.tld in virtual_mailbox_domains.
● Lines 1-7: Forward mail from the Internet for "the.backed-up.domain.tld" to the primary
MX host for that domain.
● Line 10: This is a must if Postfix receives mail via a NAT relay or proxy that presents a
different IP address to the world than the local machine.
● Lines 12-16: Define the list of valid addresses in the "the.backed-up.domain.tld"

domain. This prevents your mail queue from filling up with undeliverable MAILER-
DAEMON messages. If you can't maintain a list of valid recipients then you must
specify "relay_recipient_maps =" (that is, an empty value), or you must specify an
"@example.com x" wild-card in the relay_recipients table.
● Line 22: The [] forces Postfix to do no MX lookup.
Execute the command "postmap /etc/postfix/transport" whenever you change the transport
table.
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 local area network section above.
This section presents additional configuration. You need to combine this with basic
If you do not have your own hostname (as with dynamic IP addressing) then you should also
study the section on "Postfix on hosts without a real hostname".
● Route all outgoing mail to your network provider.
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 give the mail
to a machine that is connected all the time. In the example below, the [] prevents
Postfix from trying to look up DNS MX records.

relayhost = [smtprelay.someprovider.com]
● Disable spontaneous SMTP mail delivery (if using on-demand dialup IP only).
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.
defer_transports = smtp (Only for on-demand dialup IP
hosts)
● Disable SMTP client DNS lookups (dialup LAN only).
disable_dns_lookups = yes (Only for on-demand dialup
IP hosts)
● Flush the mail queue whenever the Internet link is established.
Put the following command into your PPP or SLIP dialup scripts:
/usr/sbin/sendmail -q (whenever the Internet link is up)
The exact location of the sendmail command is system-specific. Use the command
"postconf sendmail_path" to find out where the Postfix sendmail command is located
on your machine.
In order to find out if the mail queue is flushed, use something like:
#!/bin/sh
# Start mail 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
"sendmail -q" command every now and then while the dialup link is up, so that newly-
posted mail is flushed from the queue.
Postfix on hosts without a real hostname

This section is for hosts that don't have an Internet hostname. Typically these are systems that
get a dynamic IP address via DHCP or via dialup. Postfix will let you send and receive mail
just fine between accounts on a machine with a fantasy name. However, you cannot use a
fantasy hostname in your email address when sending mail into the Internet, because no-one
would be able to reply to your mail. In fact, more and more sites refuse mail from non-existent
domain names.
The perfect solution would be for Postfix to do a mapping from local fantasy email addresses
to valid Internet addresses when mail leaves the machine (similar to Sendmail's generics table).
This is planned for the near future.
In the mean time, the solution with Postfix is to use valid Internet addresses where possible,
and to let Postfix map valid Internet addresses to local fantasy addresses. With this, you can
send mail to the Internet and to local fantasy addresses, including mail to local fantasy
addresses that don't have a valid Internet address of their own.
The following example presents additional configuration. You need to combine this with basic
2 myhostname = hostname.localdomain
3 mydomain = localdomain
4
5 canonical_maps = hash:/etc/postfix/canonical
6
8
9 /etc/postfix/canonical:
10 your-login-name your-account@your-isp.com

11
13 your-account@your-isp.com your-login-name
Translation:
● Lines 2-3: Substitute your fantasy hostname here. Do not use a domain name that is
already in use by real organizations on the Internet. See RFC 2606 for examples of
domain names that are guaranteed not to be owned by anyone.
● Lines 5, 9, 10: This provides the mapping from "your-login-name@hostname.

localdomain" to "your-account@your-isp.com". This part is required.
● Lines 7, 12, 13: Deliver mail for "your-account@your-isp.com" locally, instead of

sending it to the ISP. This part is not required but is convenient.

Postfix XCLIENT Howto
Purpose of the XCLIENT extension to SMTP

The XCLIENT command targets the following problems:
1. Access control tests. SMTP server access rules are difficult to verify when decisions can
be triggered only by remote clients. In order to facilitate access rule testing, an
authorized SMTP client test program needs the ability to override the SMTP server's
idea of the SMTP client hostname, network address, and other client information, for
the entire duration of an SMTP session.
2. Client software that downloads mail from an up-stream mail server and injects it into a
local MTA via SMTP. In order to take advantage of the local MTA's SMTP server
access rules, the client software needs the ability to override the SMTP server's idea of
the remote client name, client address and other information. Such information can
typically be extracted from the up-stream mail server's Received: message header.
3. Post-filter access control and logging. With Internet->filter->MTA style content filter
applications, the filter can be simplified if it can delegate decisions concerning mail
relay and other access control to the MTA. This is especially useful when the filter acts
as a transparent proxy for SMTP commands. This requires that the filter can override
the MTA's idea of the SMTP client hostname, network address, and other information.
XCLIENT Command syntax

Examples of client-server conversations are given at the end of this document.
In SMTP server EHLO replies, the keyword associated with this extension is XCLIENT. It is
followed by the names of the attributes that the XCLIENT implementation supports.
The XCLIENT command may be sent at any time except in the middle of a mail delivery
http://www.subneural.net/postfix-master/XCLIENT_README.html (1 of 4)01/16/2005 15:46:40

transaction (i.e. between MAIL and DOT). The XCLIENT command may be pipelined when
the server supports ESMTP command pipelining.
The syntax of XCLIENT requests is described below. Upper case and quoted strings specify
terminals, lowercase strings specify meta terminals, and SP is whitespace. Although command
and attribute names are shown in upper case, they are in fact case insensitive.
xclient-command = XCLIENT 1*( SP attribute-name"="attribute-value )
attribute-name = ( NAME | ADDR | PROTO | HELO )
● The NAME attribute specifies an SMTP client hostname (not an SMTP client address),
[UNAVAILABLE] when client hostname lookup failed due to a permanent error, or
[TEMPUNAVAIL] when the lookup error condition was transient.
● The ADDR attribute specifies an SMTP client numerical IPv4 network address, an IPv6
address prefixed with IPV6:, or [UNAVAILABLE] when the address information is
unavailable. Address information is not enclosed with [].
● The PROTO attribute specifies either SMTP or ESMTP.
● The HELO attribute specifies an SMTP HELO parameter value, or the value
[UNAVAILABLE] when the information is unavailable.
Note 1: syntactically valid NAME and HELO attributes can be up to 255 characters long. The
client must not send XCLIENT commands that exceed the 512 character limit for SMTP
commands. To avoid exceeding the limit the client should send the information in multiple
XCLIENT commands.
Note 2: [UNAVAILABLE], [TEMPUNAVAIL] and IPV6: may be specified in upper case,

lower case or mixed case.
The XCLIENT server reply codes are as follows:
Code Meaning
250 success
501 bad command parameter syntax
503 mail transaction in progress

unable to proceed,
421
disconnecting
XCLIENT Examples
In the first example, the client impersonates a mail originating system by passing all SMTP
session information via XCLIENT commands. Information sent by the client is shown in bold
font.

EHLO client.example.com
250-server.example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-XCLIENT NAME ADDR PROTO HELO
250 8BITMIME
XCLIENT NAME=spike.porcupine.org ADDR=168.100.189.2
PROTO=ESMTP
250 Ok
XCLIENT HELO=spike.porcupine.org
250 Ok
250 Ok
250 Ok
DATA
.
250 Ok: queued as 763402AAE6
QUIT
221 Bye
In the second example, the client impersonates a mail originating system by sending the
XCLIENT command before the EHLO or HELO command. This increases the realism of
impersonation, but requires that the client knows ahead of time what XCLIENT options the
server supports.

XCLIENT NAME=spike.porcupine.org ADDR=168.100.189.2

250 Ok
HELO spike.porcupine.org
250 server.example.com
250 Ok
250 Ok
DATA
.
250 Ok: queued as CF1E52AAE7
QUIT
221 Bye
Security
The XCLIENT command changes audit trails and/or SMTP client access permissions. Use of
this command must be restricted to authorized SMTP clients. However, the XCLIENT
command should not override its own access control mechanism.
SMTP connection caching

XCLIENT attributes persist until the end of an SMTP session. If one session is used to deliver
mail on behalf of different SMTP clients, the XCLIENT attributes need to be reset as
appropriate before each MAIL FROM command.

Postfix manual - discard(8)
DISCARD(8) DISCARD
(8)
NAME
discard - Postfix discard mail delivery agent
SYNOPSIS
discard [generic Postfix daemon options]
DESCRIPTION
The Postfix discard delivery agent processes
delivery
requests from the queue manager. Each request specifies
a
queue file, a sender address, a domain or host name
that
is treated as the reason for discarding the mail,
and
recipient information. This program expects to be
run
from the master(8) process manager.
The discard delivery agent pretends to deliver all

recipi-
ents in the delivery request, logs the "next-hop"
domain
or host information as the reason for discarding the
mail,
updates the queue file and marks recipients as finished
or
informs the queue manager that delivery should be
tried
again at a later time.
Delivery status reports are sent to the trace(8) daemon

as
appropriate.
SECURITY
The discard mailer is not security-sensitive. It does
not
http://www.subneural.net/postfix-master/discard.8.html (1 of 4)01/16/2005 15:46:41

talk to the network, and can be run chrooted at fixed

low
privilege.
STANDARDS
None.
DIAGNOSTICS

parameter,
trou-
ble.
Changes to main.cf are picked up automatically as
dis-
card(8) processes run for only a limited amount of
time.

See

and
to
a
that

ipc_timeout (3600s)
information
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a
pro-
cess.
daemon
process.

direc-
tory.
pro-
"smtpd"

SEE ALSO
error(8), Postfix error delivery agent
LICENSE
this
software.
HISTORY
AUTHOR(S)
Victor Duchovni
Morgan Stanley
Based on code by:

Wietse Venema
P.O. Box 704
DISCARD
(8)

Postfix MySQL Howto
Postfix MySQL Howto
Introduction
The Postfix mysql map type allows you to hook up Postfix to a MySQL database. This
implementation allows for multiple mysql databases: you can use one for a virtual(5) table, one
for an access(5) table, and one for an aliases(5) table if you want. You can specify multiple
servers for the same database, so that Postfix can switch to a good database server if one goes
bad.
Busy mail servers using mysql maps will generate lots of concurrent mysql clients, so the
mysql server(s) should be run with this fact in mind. You can reduce the number of concurrent
mysql clients by using the Postfix proxymap(8) service.
Building Postfix with MySQL support

Note: to use mysql with Debian GNU/Linux's Postfix, all you need is to install the postfix-
mysql package and you're done. There is no need to recompile Postfix.
The Postfix MySQL client utilizes the mysql client library, which can be obtained from:
http://www.mysql.com/downloads/
http://sourceforge.net/projects/mysql/
In order to build Postfix with mysql map support, you will need to add -DHAS_MYSQL and -I
for the directory containing the mysql headers, and the mysqlclient library (and libm) to
AUXLIBS, for example:
make -f Makefile.init makefiles \

'CCARGS=-DHAS_MYSQL -I/usr/local/mysql/include' \
'AUXLIBS=-L/usr/local/mysql/lib -lmysqlclient -lz
http://www.subneural.net/postfix-master/MYSQL_README.html (1 of 3)01/16/2005 15:46:41

Postfix MySQL Howto
-lm'
Then, just run 'make'. This requires libz, the compression library. Older mysql implementations
build without libz.
Using MySQL tables

Once Postfix is built with mysql support, you can specify a map type in main.cf like this:
alias_maps = mysql:/etc/postfix/mysql-aliases.cf
The file /etc/postfix/mysql-aliases.cf specifies lots of information telling Postfix how to

reference the mysql database. For a complete description, see the mysql_table(5) manual page.
Example: local aliases

#
# mysql config file for local(8) aliases(5) lookups
#
# The user name and password to log into the mysql server.
user = someone
# The database name on the servers.

# The table name.

table = mxaliases
# Query components, see below.

where_field = alias
# You may specify additional_conditions or leave this empty.

# The above variables will result in a query of the form:

#
# select forw_addr from mxaliases where alias = '$lookup' and

Postfix MySQL Howto
status = 'paid'
#
# ($lookup is escaped so if it contains single quotes or other
odd
# characters, it will not cause trouble).
Additional notes
The MySQL configuration interface setup allows for multiple mysql databases: you can use
one for a virtual table, one for an access table, and one for an aliases table if you want.
Since sites that have a need for multiple mail exchangers may enjoy the convenience of using a
networked mailer database, but do not want to introduce a single point of failure to their
system, we've included the ability to have Postfix reference multiple hosts for access to a single
mysql map. This will work if sites set up mirrored mysql databases on two or more hosts.
Whenever queries fail with an error at one host, the rest of the hosts will be tried in random
order. If no mysql server hosts are reachable, then mail will be deferred until at least one of
those hosts is reachable.
Credits
● The initial version was contributed by Scott Cotton and Joshua Marcus, IC Group, Inc.
● Liviu Daia revised the configuration interface and added the main.cf configuration
feature.

Postfix PostgreSQL Howto
Introduction
The Postfix pgsql map type allows you to hook up Postfix to a PostgreSQL database. This
implementation allows for multiple pgsql databases: you can use one for a virtual(5) table, one
for an access(5) table, and one for an aliases(5) table if you want. You can specify multiple
servers for the same database, so that Postfix can switch to a good database server if one goes
bad.
Busy mail servers using pgsql maps will generate lots of concurrent pgsql clients, so the pgsql
server(s) should be run with this fact in mind. You can reduce the number of concurrent pgsql
clients by using the Postfix proxymap(8) service.
Building Postfix with PostgreSQL support

Note: to use pgsql with Debian GNU/Linux's Postfix, all you need to do is to install the postfix-
pgsql package and you're done. There is no need to recompile Postfix.
In order to build Postfix with pgsql map support, you specify -DHAS_PGSQL, the directory
with the PostgreSQL header files, and the location of the libpq library file.
For example:
% make tidy
% make -f Makefile.init makefiles \
'CCARGS=-DHAS_PGSQL -I/usr/local/include/
pgsql' \
'AUXLIBS=-L/usr/local/lib -lpq'
Then just run 'make'.
http://www.subneural.net/postfix-master/PGSQL_README.html (1 of 3)01/16/2005 15:46:42

Configuring PostgreSQL lookup tables

Once Postfix is built with pgsql support, you can specify a map type in main.cf like this:
alias_maps = pgsql:/etc/postfix/pgsql-aliases.cf
The file /etc/postfix/pgsql-aliases.cf specifies lots of information telling postfix how to

reference the pgsql database. For a complete description, see the pgsql_table(5) manual page.
Example: local aliases

#
# pgsql config file for local(8) aliases(5) lookups
#
#
# The hosts that Postfix will try to connect to
# The user name and password to log into the pgsql server.
user = someone
# The database name on the servers.

# The table name.

table = mxaliases
# Query components, see below.

where_field = alias
# You may specify additional_conditions or leave this empty.

# The above variables will result in a query of the form:

#
# select forw_addr from mxaliases where alias = '$lookup' and
status = 'paid'

#
# ($lookup is escaped so if it contains single quotes or other
odd
# characters, it will not cause problems).
#
# You may also override the built-in SELECT template. See
pgsql_table(5)
# for details.
Using mirrored databases

Sites that have a need for multiple mail exchangers may enjoy the convenience of using a
networked mailer database, but do not want to introduce a single point of failure to their
system.
For this reason we've included the ability to have Postfix reference multiple hosts for access to
a single pgsql map. This will work if sites set up mirrored pgsql databases on two or more
hosts.
Whenever queries fail with an error at one host, the rest of the hosts will be tried in random
order. If no pgsql server hosts are reachable, then mail will be deferred until at least one of
those hosts is reachable.
Credits
● This code is based upon the Postfix mysql map by Scott Cotton and Joshua Marcus, IC
Group, Inc.
● The PostgreSQL changes were done by Aaron Sethman.
● Updates for Postfix 1.1.x and PostgreSQL 7.1+ and support for calling stored
procedures were added by Philip Warner.
● LaMont Jones was the initial Postfix pgsql maintainer.
● Liviu Daia revised the configuration interface and added the main.cf configuration
feature.

Postfix manual - lmtp(8)
LMTP(8) LMTP
(8)
NAME
lmtp - Postfix local delivery via LMTP
SYNOPSIS
lmtp [generic Postfix daemon options]
DESCRIPTION
The LMTP client processes message delivery requests
from
the queue manager. Each request specifies a queue file,
a
sender address, a domain or host to deliver to, and
recip-
ient information. This program expects to be run from
the
master(8) process manager.
The LMTP client updates the queue file and marks

recipi-
ents as finished, or it informs the queue manager
that
delivery should be tried again at a later time.
Delivery
status reports are sent to the bounce(8), defer(8)
or
trace(8) daemon as appropriate.
The LMTP client connects to the destination specified

in
the message delivery request. The destination,
usually
specified in the Postfix transport(5) table, has the
form:
unix:pathname
Connect to the local UNIX-domain server that
is
bound to the specified pathname. If the
http://www.subneural.net/postfix-master/lmtp.8.html (1 of 10)01/16/2005 15:46:42

process
runs chrooted, an absolute pathname is
interpreted
relative to the changed root directory.
inet:host, inet:host:port (symbolic host)
inet:[addr], inet:[addr]:port (numeric host)

Connect to the specified IPV4 TCP port on the
spec-
ified local or remote host. If no port is
speci-
fied, connect to the port defined as lmtp in
ser-
vices(4). If no such service is found,
the
lmtp_tcp_port configuration parameter
(default
value of 24) will be used.
The LMTP client does not perform MX

(mail
exchanger) lookups since those are defined only
for
mail delivery via SMTP.
If neither unix: nor inet: are specified, inet:

is
assumed.
SECURITY
The LMTP client is moderately security-sensitive. It
talks
to LMTP servers and to DNS servers on the network.
The
LMTP client can be run chrooted at fixed low privilege.
STANDARDS

RFC 2033 (LMTP protocol)

DIAGNOSTICS
Cor-
manager
inspection.

parameter,
problems,
and of other trouble.
Changes to main.cf are picked up automatically, as lmtp
(8)
the

See
lmtp_skip_quit_response (no)
Wait for the response to the LMTP QUIT command.

a
the

hostname
verbose
specified
about
policy,

the
postmaster.

lmtp_send_xforward_command (no)
Send an XFORWARD command to the LMTP server
when
the LMTP LHLO server response announces
XFORWARD
support.

lmtp_sasl_auth_enable (no)
LMTP
client.
lmtp_sasl_password_maps (empty)
Optional LMTP client lookup tables with one
user-
name:password entry per host or domain.

lmtp_sasl_security_options (noplaintext, noanonymous)

What authentication mechanisms the Postfix
LMTP
client is allowed to use.

In the text below, transport is the name of the service
as
specified in the master.cf file.
lmtp_cache_connection (yes)
Keep Postfix LMTP client connections open for up
to
$max_idle seconds.
($default_destina-
Limit the number of parallel deliveries to the
same
destination via this mail delivery transport.
($default_destina-
Limit the number of recipients per message
delivery
via this mail delivery transport.
This parameter becomes significant if the

LMTP
client is used for local delivery. Some
LMTP
servers can optimize delivery of the same
message
to multiple recipients. The default limit for
local
mail delivery is 1.
Setting this parameter to 0 will lead to

an

unbounded number of recipients per delivery.

How-
ever, this could be risky since it may make
the
machine vulnerable to running out of resources
if
messages are encountered with an inordinate
number
of recipients. Exercise care when setting
this
parameter.
lmtp_connect_timeout (0s)
The LMTP client time limit for completing a
TCP
connection, or zero (use the operating
system
built-in time limit).
lmtp_lhlo_timeout (300s)
The LMTP client time limit for receiving the
LMTP
greeting banner.
lmtp_xforward_timeout (300s)
The LMTP client time limit for sending the
XFORWARD
lmtp_mail_timeout (300s)
MAIL
FROM command, and for receiving the
server
response.
lmtp_rcpt_timeout (300s)
The LMTP client time limit for sending the RCPT
TO
lmtp_data_init_timeout (120s)


LMTP
DATA command, and for receiving the
server
response.
lmtp_data_xfer_timeout (180s)
LMTP
message content.
lmtp_data_done_timeout (600s)
LMTP
".", and for receiving the server response.
lmtp_rset_timeout (20s)
RSET
lmtp_quit_timeout (300s)
QUIT
and
to
a
disable_dns_lookups (no)
Disable DNS lookups in the Postfix SMTP and
LMTP

clients.
ipc_timeout (3600s)
information
lmtp_tcp_port (24)
The default TCP port that the Postfix LMTP
client
connects to.
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a
pro-
cess.
daemon
process.

direc-
tory.

pro-
"smtpd"
SEE ALSO
services(4), Internet services and aliases
README FILES
LMTP_README, Postfix LMTP client howto
VIRTUAL_README, virtual delivery agent howto
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
Alterations for LMTP by:

Philip A. Prindeville
Mirapoint, Inc.
USA.
Additional work on LMTP by:

Amos Gouaux
University of Texas at Dallas
P.O. Box 830688, MC34
Richardson, TX 75083, USA

LMTP
(8)

Postfix LMTP Howto
Postfix LMTP Howto
http://www.subneural.net/postfix-master/LMTP_README.html01/16/2005 15:46:43
Postfix Performance Tuning
Purpose of Postfix performance tuning

The hints and tips in this document help you improve the performance of Postfix systems that already work.
If your Postfix system is unable to receive or deliver mail, then you need to solve those problems first, using
the DEBUG_README document as guidance.
For tuning external content filter performance, first read the respective information in the
FILTER_README and SMTPD_PROXY_README documents. Then make sure to avoid latency in the
content filter code. As much as possible avoid performing queries against external data sources with a high
or highly variable delay. Your content filter will run with a small concurrency to avoid CPU/memory
starvation, and if any latency creeps in, content filter throughput will suffer. High volume environments
should avoid RBL lookups, complex database queries and so on.
Topics on mail receiving performance:
● General mail receiving performance tips

● Doing more work with your SMTP server processes
● Slowing down SMTP clients that make many errors
● Measures against clients that make too many connections
Topics on mail delivery performance:
● General mail delivery performance tips

● Tuning the frequency of deferred mail delivery attempts
● Tuning the number of simultaneous deliveries
● Tuning the number of recipients per delivery
Other Postfix performance tuning topics:
● Tuning the number of Postfix processes

● Tuning the number of open files or sockets
The following tools can be used to measure mail system performance under artificial loads. They are
normally not installed with Postfix.
http://www.subneural.net/postfix-master/TUNING_README.html (1 of 9)01/16/2005 15:46:43

● smtp-source, SMTP/LMTP message generator

● smtp-sink, SMTP/LMTP message dump
● qmqp-source, QMQP message generator
● qmqp-sink, QMQP message dump
General mail receiving performance tips

● Read and understand the maildrop queue, incoming queue, and active queue discussions in the
QSHAPE_README document.
● Run a local name server to reduce slow-down due to DNS lookups. If you run multiple Postfix
systems, point each local name server to a shared forwarding server to reduce the number of lookups
across the upstream network link.
● Eliminate unnecessary LDAP lookups, by specifying a domain filter. This eliminates lookups for
addresses in remote domains, and eliminates lookups of partial addresses. See ldap_table(5) for
details.
When Postfix responds slowly to SMTP clients:
● Look for obvious signs of trouble as described in the DEBUG_README document, and eliminate
those problems first.
● Turn off your header_checks and body_checks patterns and see if the problem goes away.
● Turn off chroot operation as described in the DEBUG_README document and see if the problem
goes away.
● If Postfix logs the SMTP client as "unknown" then you have a name service problem: the name
server is bad, or the resolv.conf file contains bad information, or some packet filter is blocking the
DNS requests or replies.
● If the number of smtpd(8) processes has reached the process limit as specified in master.cf, new
SMTP clients must wait until a process becomes available. Increase the number of processes if
memory permits. See the instructions given under "Tuning the number of Postfix processes".
Doing more work with your SMTP server processes

With Postfix versions 2.0 and earlier, the smtpd(8) server pauses before reporting an error to an SMTP
client. The idea is called tar pitting. However, these delays also slow down Postfix. When the smtpd(8)
server replies slowly, sessions take more time, so that more smtpd(8) server processes are needed to handle
the load. When your Postfix smtpd(8) server process limit is reached, new clients must wait until a server
process becomes available. This means that all clients experience poor performance.

You can speed up the handling of smtpd(8) server error replies by turning off the delay:
# Not needed with Postfix 2.1
smtpd_error_sleep_time = 0
With the above setting, Postfix 2.0 and earlier can serve more SMTP clients with the same number SMTP
server processes. The next section describes how Postfix deals with clients that make a large number of
errors.
Slowing down SMTP clients that make many errors

The Postfix smtpd(8) server maintains a per-session error count. The error count is reset when a message is
transferred successfully, and is incremented when a client request is unrecognized or unimplemented, when
a client request violates access restrictions, or when some other error happens.
As the per-session error count increases, the smtpd(8) server changes behavior and begins to insert delays
into the responses. The idea is to slow down a run-away client in order to limit resource usage. The
behavior is Postfix version dependent.
IMPORTANT: These delays slow down Postfix, too. When too much delay is configured, the number of
simultaneous SMTP sessions will increase until it reaches the smtpd(8) server process limit, and new SMTP
clients must wait until an smtpd(8) server process becomes available.
Postfix version 2.1 and later:
● When the error count reaches $smtpd_soft_error_limit (default: 10), the Postfix smtpd(8) server
delays all non-error and error responses by $smtpd_error_sleep_time seconds (default: 1 second).
● When the error count reaches $smtpd_hard_error_limit (default: 20) the Postfix smtpd(8) server
breaks the connection.
Postfix version 2.0 and earlier:
● When the error count is less than $smtpd_soft_error_limit (default: 10) the Postfix smtpd(8) server
delays all error replies by $smtpd_error_sleep_time (1 second with Postfix 2.0, 5 seconds with
Postfix 1.1 and earlier).
● When the error count reaches $smtpd_soft_error_limit, the Postfix smtpd(8) server delays all
responses by "error count" seconds or $smtpd_error_sleep_time, whichever is more.
● When the error count reaches $smtpd_hard_error_limit (default: 20) the Postfix smtpd(8) server
breaks the connection.

Measures against clients that make too many connections

Note: this feature is not included with Postfix version 2.1.
The Postfix smtpd(8) server can limit the number of simultaneous connections from the same SMTP client,
as well as the number of connections that a client is allowed to make per unit time. These statistics are
maintained by the anvil(8) server (translation: if anvil(8) breaks, then connection limits stop working).
IMPORTANT: These limits are designed to protect the smtpd(8) server against flagrant abuse. Do not use
these limits to regulate legitimate traffic: mail will suffer grotesque delays if you do so.
● An SMTP client may make up to $smtpd_client_connection_count_limit simultaneous connections

(default: 50). This is half the default process limit.
● An SMTP client may make up to $smtpd_client_connection_rate_limit connections per unit time

(default: no limit).
● These limits are not applied to SMTP clients in the networks specified with
$smtpd_client_connection_limit_exceptions (default: clients in $mynetworks may make an
unlimited number of connections).
● The anvil_rate_time_unit parameter specifies the time unit over which client connection rates are
computed (default: 60s).
General mail delivery performance tips

● Read and understand the maildrop queue, incoming queue, active queue and deferred queue
discussions in the QSHAPE_README document.
● In case of slow delivery, run the qshape tool as described in the QSHAPE_README document.
● Submit multiple recipients per message instead of submitting messages with only a few recipients.
● Submit mail via SMTP instead of /usr/sbin/sendmail. You may have to adjust the
smtpd_recipient_limit parameter setting.
● Don't overwhelm the disk with mail submissions. Optimize the mail submission rate by tuning the
number of parallel submissions and/or by tuning the Postfix in_flow_delay parameter setting.
● Run a local name server to reduce slow-down due to DNS lookups. If you run multiple Postfix
systems, point each local name server to a shared forwarding server to reduce the number of lookups
across the upstream network link.
● Reduce the smtp_connect_timeout and smtp_helo_timeout values so that Postfix does not waste lots

of time connecting to non-responding smtpd(8) servers.
● Use a dedicated mail delivery transport for problematic destinations, with reduced timeouts and with
adjusted concurrency. See "Tuning the number of simultaneous deliveries" below.
● Use a fallback_relay host for mail that cannot be delivered upon the first attempt. This "graveyard"
machine can use shorter retry times for difficult to reach destinations. See "Tuning the frequency of
deferred mail delivery attempts" below.
● Speed up disk updates with a large (64MB) persistent write cache. This allows disk updates to be
sorted for optimal access speed without compromising file system integrity when the system crashes.
● Use a solid-state disk (a persistent RAM disk). This is an expensive solution that should be used in
combination with short SMTP timeouts and a fallback_relay "graveyard" machine that delivers mail
for problem destinations.
Tuning the number of simultaneous deliveries

Although Postfix can be configured to run 1000 SMTP client processes at the same time, it is rarely
desirable that it makes 1000 simultaneous connections to the same remote system. For this reason, Postfix
has safety mechanisms in place to avoid this so-called "thundering herd" problem.
The Postfix queue manager implements the analog of the TCP slow start flow control strategy: when
delivering to a site, send a small number of messages first, then increase the concurrency as long as all goes
well; reduce concurrency in the face of congestion.
● The initial_destination_concurrency parameter (default: 5) controls how many messages are initially
sent to the same destination before adapting delivery concurrency. Of course, this setting is effective
only as long as it does not exceed the process limit and the destination concurrency limit for the
specific mail transport channel.
● The default_destination_concurrency_limit parameter (default: 20) controls how many messages

may be sent to the same destination simultaneously. You can override this setting for specific
message delivery transports by taking the name of the master.cf entry and appending
"_destination_concurrency_limit".
Examples of transport specific concurrency limits are:
● The local_destination_concurrency_limit parameter (default: 2) controls how many messages are

delivered simultaneously to the same local recipient. The recommended limit is low because delivery
to the same mailbox must happen sequentially, so massive parallelism is not useful. Another good
reason to limit delivery concurrency to the same recipient: if the recipient has an expensive shell
command in her .forward file, or if the recipient is a mailing list manager, you don't want to run too
many instances of those processes the same time.

● The default smtp_destination_concurrency_limit of 20 seems enough to noticeably load a system

without bringing it to its knees. Be careful when changing this to a much larger number.
The above default values of the concurrency limits work well in a broad range of situations. Knee-jerk
changes to these parameters in the face of congestion can actually make problems worse. Specifically, large
destination concurrencies should never be the default. They should be used only for transports that deliver
mail to a small number of high volume domains.
A common situation where high concurrency is called for is on gateways relaying a high volume of mail
from between the Internet and an intranet mail environment. Approximately half the mail (assuming equal
volumes inbound and outbound) will be destined for the internal mail hubs. Since the internal mail hubs will
be receiving all external mail exclusively from the gateway, it is reasonable to configure the gateway to
make greater demands on the capacity of the internal SMTP servers.
The tuning of the inbound concurrency limits need not be trial and error. A high volume capable mailhub
should be able to easily handle 50 or 100 (rather than the default 20) simultaneous connections, especially if
the gateway forwards to multiple MX hosts. When all MX hosts are up and accepting connections in a
timely fashion, throughput will be high. If any MX host is down and completely unresponsive, the average
connection latency rises to at least 1/N * $smtp_connection_timeout, if there are N MX hosts. This limits
throughput to at most the destination concurrency * N / $smtp_connection_timeout.
For example, with a destination concurrency of 100 and 2 MX hosts, each host will handle up to 50
simultaneous connections. If one MX host is down and the default SMTP connection timeout is 30s, the
throughput limit is 100 * 2 / 30 ~= 6 messages per second. This suggests that high volume destinations with
good connectivity and multiple MX hosts need a lower connection timeout, values as low as 5s or even 1s
can be used to prevent congestion when one or more, but not all MX hosts are down.
If necessary, set a higher transport_destination_concurrency_limit (in main.cf since this is a queue manager
parameter) and a lower smtp_connection_timeout (with a "-o" override in master.cf since this parameter has
no per-transport name) for the relay transport and any transports dedicated for specific high volume
destinations.
Tuning the number of recipients per delivery

The default_destination_recipient_limit parameter (default: 50) controls how many recipients a Postfix
delivery agent will send with each copy of an email message. You can override this setting for specific
Postfix delivery agents. For example, "uucp_destination_recipient_limit = 100" would limit the number of
recipients per UUCP delivery to 100.
If an email message exceeds the recipient limit for some destination, the Postfix queue manager breaks up
the list of recipients into smaller lists. Postfix will attempt to send multiple copies of the message in parallel.
IMPORTANT: Be careful when increasing the recipient limit per message delivery; some smtpd(8) servers
abort the connection when they run out of memory or when a hard recipient limit is reached, so that the
message will never be delivered.

The smtpd_recipient_limit parameter (default: 1000) controls how many recipients the Postfix smtpd(8)
server will take per delivery. The default limit is more than any reasonable SMTP client would send. The
limit exists to protect the local mail system against a run-away client.
Tuning the frequency of deferred mail delivery attempts

When a Postfix delivery agent (smtp(8), local(8), etc.) is unable to deliver a message it may blame the
message itself, or it may blame the receiving party.
● When the delivery agent blames the message, the queue manager gives the queue file a time stamp
into the future, so it won't be looked at for a while. By default, the amount of time to cool down is
the amount of time that has passed since the message arrived. This results in so-called exponential
backoff behavior.
● When the delivery agent blames the receiving party (for example a local recipient user, or a remote
host), the queue manager not only advances the queue file time stamp, but also puts the receiving
party on a "dead" list so that it will be skipped for some amount of time.
This process is governed by a bunch of little parameters.
queue_run_delay (default: 1000 seconds)

How often the queue manager scans the queue for deferred mail.
minimal_backoff_time (default: 1000 seconds)
The minimal amount of time a message won't be looked at, and the minimal amount of
time to stay away from a "dead" destination.
maximal_backoff_time (default: 4000 seconds)
The maximal amount of time a message won't be looked at after a delivery failure.
maximal_queue_lifetime (default: 5 days)
How long a message stays in the queue before it is sent back as undeliverable. Specify
0 for mail that should be returned immediately after the first unsuccessful delivery
attempt.
bounce_queue_lifetime (default: 5 days, available with Postfix version 2.1 and later)
How long a MAILER-DAEMON message stays in the queue before it is considered
undeliverable. Specify 0 for mail that should be tried only once.
qmgr_message_recipient_limit (default: 20000)
The size of many in-memory queue manager data structures. Among others, this
parameter limits the size of the short-term, in-memory list of "dead" destinations.
Destinations that don't fit the list are not added.
IMPORTANT: If you increase the frequency of deferred mail delivery attempts, or if you flush the deferred
mail queue frequently, then you may find that Postfix mail delivery performance actually becomes worse.
The symptoms are as follows:
● The active queue becomes saturated with mail that has delivery problems. New mail enters the active
queue only when an old message is deferred. This is a slow process that usually requires timing out

one or more SMTP connections.
● All available Postfix delivery agents become occupied trying to connect to unreachable sites etc.
New mail has to wait until a delivery agent becomes available. This is a slow process that usually
requires timing out one or more SMTP connections.
When mail is being deferred frequently, fixing the problem is always better than increasing the frequency of
delivery attempts. However, if you can control only the delivery attempt frequency, consider using a
dedicated fallback_relay "graveyard" machine for bad destinations so that they do not ruin the performance
of normal mail deliveries.
Tuning the number of Postfix processes

The default_process_limit configuration parameter gives direct control over how many daemon processes
Postfix will run. As of Postfix 2.0 the default limit is 100 smtp client processes, 100 smtp server processes,
and so on. This may overwhelm systems with little memory, as well as networks with low bandwidth.
You can change the global process limit by specifying a non-default default_process_limit in the main.cf
file. For example, to run up to 10 smtp client processes, 10 smtp server processes, and so on:
default_process_limit = 10
You need to execute "postfix reload" to make the change effective. The limits are enforced by the Postfix
master(8) daemon which does not automatically read main.cf when it changes.
You can override the process limit for specific Postfix daemons by editing the master.cf file. For example, if
you do not wish to receive 100 SMTP messages at the same time, but do not want to change the process
limits for local mail deliveries, you could specify:
#
====================================================================
command + args
#
====================================================================
. . .
smtp inet n - - - 10
smtpd
. . .
Tuning the number of open files or sockets

When Postfix opens too many files or sockets, processes will abort with fatal errors, and the system may log
"file table full" errors.
● Reduce the number of processes as described under "Tuning the number of Postfix processes" above.
Fewer processes need fewer open files and sockets.
● Configure the kernel for more open files and sockets. The details are extremely system dependent
and change with the operating system version. Be sure to verify the following information with your
system tuning guide:
❍ Some FreeBSD kernel parameters can be specified in /boot/loader.conf, and some can be
changed with sysctl commands. Which is which depends on the version.
kern.ipc.maxsockets="5000"
kern.ipc.nmbclusters="65536"
kern.maxproc="2048"
kern.maxfiles="16384"
kern.maxfilesperproc="16384"
❍ Linux kernel parameters can be specified in /etc/sysctl.conf and can also be changed with
sysctl commands:
fs.file-max=16384
kernel.threads-max=2048
❍ Solaris kernel parameters can be specified in /etc/system, as described in the Solaris FAQ
entry titled "How can I increase the number of file descriptors per process?"
* set hard limit on file descriptors

set rlim_fd_max = 4096
* set soft limit on file descriptors
set rlim_fd_cur = 1024

Postfix Debugging Howto

This document describes how to debug parts of the Postfix mail system when things do not work
according to expectation. The methods vary from making Postfix log a lot of detail, to running
some daemon processes under control of a call tracer or debugger.
The text assumes that the Postfix main.cf and master.cf configuration files are stored in directory /
etc/postfix. You can use the command "postconf config_directory" to find out the actual
location of this directory on your machine.
Listed in order of increasing invasiveness, the debugging techniques are as follows:
● Look for obvious signs of trouble

● Debugging Postfix from inside
● Try turning off chroot operation in master.cf
● Verbose logging for specific SMTP connections
● Record the SMTP session with a network sniffer
● Making Postfix daemon programs more verbose
● Manually tracing a Postfix daemon process
● Automatically tracing a Postfix daemon process
● Running daemon programs with the interactive xxgdb debugger
● Running daemon programs under a non-interactive debugger
● Unreasonable behavior
● Reporting problems to postfix-users@postfix.org
Look for obvious signs of trouble

Postfix logs all failed and successful deliveries to a logfile. The file is usually called /var/log/
maillog or /var/log/mail; the exact pathname is defined in the /etc/syslog.conf file.
http://www.subneural.net/postfix-master/DEBUG_README.html (1 of 9)01/16/2005 15:46:44

When Postfix does not receive or deliver mail, the first order of business is to look for errors that
prevent Postfix from working properly:
% egrep '(warning|error|fatal|panic):' /some/log/file |

more
Note: the most important message is near the BEGINNING of the output. Error messages that
come later are less useful.
The nature of each problem is indicated as follows:
● "panic" indicates a problem in the software itself that only a programmer can fix. Postfix
cannot proceed until this is fixed.
● "fatal" is the result of missing files, incorrect permissions, incorrect configuration file
settings that you can fix. Postfix cannot proceed until this is fixed.
● "error" reports a fatal or non-fatal error condition. Postfix cannot proceed until this is
fixed.
● "warning" indicates a non-fatal error. These are problems that you may not be able to fix
(such as a broken DNS server elsewhere on the network) but may also indicate local
configuration errors that could become a problem later.
Debugging Postfix from inside

With Postfix version 2.1 and later you can ask Postfix to produce mail delivery reports for
debugging purposes. These reports not only show sender/recipient addresses after address
rewriting and alias expansion or forwarding, they also show information about delivery to
mailbox, delivery to non-Postfix command, responses from remote SMTP servers, and so on.
Postfix can produce two types of mail delivery reports for debugging:
● What-if: report what would happen, but do not actually deliver mail. This mode of
operation is requested with:
$ /usr/sbin/sendmail -bv address...

Mail Delivery Status Report will be mailed to <your login
name>.
● What happened: deliver mail and report successes and/or failures, including replies from

remote SMTP servers. This mode of operation is requested with:
$ /usr/sbin/sendmail -v address...
Mail Delivery Status Report will be mailed to <your login
name>.
These reports contain information that is generated by Postfix delivery agents. Since these run as
daemon processes and do not interact with users directly, the result is sent as mail to the sender of
the test message. The format of these reports is practically identical to that of ordinary non-
delivery notifications.
For a detailed example of a mail delivery status report, see the debugging section at the end of the
ADDRESS_REWRITING_README document.
Try turning off chroot operation in master.cf

A common mistake is to turn on chroot operation in the master.cf file without going through all
the necessary steps to set up a chroot environment. This causes Postfix daemon processes to fail
due to all kinds of missing files.
The example below shows an SMTP server that is configured with chroot turned off:
#
=============================================================
maxproc command
(100)
#
=============================================================
smtp inet n - n -
- smtpd
Inspect master.cf for any processes that have chroot operation not turned off. If you find any,
save a copy of the master.cf file, and edit the entries in question. After executing the command
"postfix reload", see if the problem has gone away.
If turning off chrooted operation made the problem go away, then congratulations. Leaving
Postfix running in this way is adequate for most sites. If you prefer chrooted operation, see the
Postfix BASIC_CONFIGURATION_README file for information about how to prepare
Postfix for chrooted operation.

Verbose logging for specific SMTP connections

In /etc/postfix/main.cf, list the remote site name or address in the debug_peer_list parameter. For
example, in order to make the software log a lot of information to the syslog daemon for
connections from or to the loopback interface:
debug_peer_list = 127.0.0.1
You can specify one or more hosts, domains, addresses or net/masks. To make the change
effective immediately, execute the command "postfix reload".
Record the SMTP session with a network sniffer

This example uses tcpdump. In order to record a conversation you need to specify a large
enough buffer with the "-s" option or else you will miss some or all of the packet payload.
# tcpdump -w /file/name -s 2000 host example.com and

port 25
Run this for a while, stop with Ctrl-C when done. To view the data use a binary viewer, or
ethereal, or use my tcpdumpx utility that is available from ftp://ftp.porcupine.org/pub/
debugging/.
Making Postfix daemon programs more verbose

Append one or more "-v" options to selected daemon definitions in /etc/postfix/master.cf and type
"postfix reload". This will cause a lot of activity to be logged to the syslog daemon. Example:
smtp inet n - n -
- smtpd -v
This makes the Postfix SMTP server more verbose. To diagnose problems with address rewriting
one would specify a "-v" option for the cleanup(8) and/or trivial-rewrite(8) daemon, and to
diagnose problems with mail delivery one would specify a "-v" option for the qmgr(8) or oqmgr
(8) queue manager, or for the lmtp(8), local(8), pipe(8), smtp(8), or virtual(8) delivery agent.

Manually tracing a Postfix daemon process

Many systems allow you to inspect a running process with a system call tracer. For example:
# trace -p process-id (SunOS 4)

# strace -p process-id (Linux and many others)
# truss -p process-id (Solaris, FreeBSD)
# ktrace -p process-id (generic 4.4BSD)
Even more informative are traces of system library calls. Examples:
# ltrace -p process-id (Linux, also ported to FreeBSD

and BSD/OS)
# sotruss -p process-id (Solaris)
See your system documentation for details.
Tracing a running process can give valuable information about what a process is attempting to
do. This is as much information as you can get without running an interactive debugger program,
as described in a later section.
Automatically tracing a Postfix daemon process

Postfix can attach a call tracer whenever a daemon process starts. Call tracers come in several
kinds.
1. System call tracers such as trace, truss, strace, or ktrace. These show the communication
between the process and the kernel.
2. Library call tracers such as sotruss and ltrace. These show calls of library routines, and
give a better idea of what is going on within the process.
Append a -D option to the suspect command in /etc/postfix/master.cf, for example:
smtp inet n - n -
- smtpd -D
Edit the debugger_command definition in /etc/postfix/main.cf so that it invokes the call tracer of
your choice, for example:

debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin;
(truss -p $process_id 2>&1 | logger -p mail.
info) & sleep 5
Type "postfix reload" and watch the logfile.
Running daemon programs with the interactive xxgdb

debugger
If you have X Windows installed on the Postfix machine, then an interactive debugger such as
xxgdb can be convenient.
Edit the debugger_command definition in /etc/postfix/main.cf so that it invokes xxgdb:
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/
bin
xxgdb $daemon_directory/$process_name
$process_id & sleep 5
Be sure that gdb is in the command search path, and export XAUTHORITY so that X access
control works, for example:
% setenv XAUTHORITY ~/.Xauthority (csh syntax)

$ export XAUTHORITY=$HOME/.Xauthority (sh syntax)
Append a -D option to the suspect daemon definition in /etc/postfix/master.cf, for example:
smtp inet n - n -
- smtpd -D
Stop and start the Postfix system. This is necessary so that Postfix runs with the proper
XAUTHORITY and DISPLAY settings.
Whenever the suspect daemon process is started, a debugger window pops up and you can watch
in detail what happens.

Running daemon programs under a non-interactive

debugger
If you do not have X Windows installed on the Postfix machine, or if you are not familiar with
interactive debuggers, then you can try to run gdb in non-interactive mode, and have it print a
stack trace when the process crashes.
Edit the debugger_command definition in /etc/postfix/main.cf so that it invokes the gdb

debugger:
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin; export PATH;
(echo cont; echo
where; sleep 8640000) | gdb $daemon_directory/
$process_name
$process_id 2>&1
>$config_directory/$process_name.$process_id.
log & sleep 5
Append a -D option to the suspect daemon in /etc/postfix/master.cf, for example:
smtp inet n - n -
- smtpd -D
Type "postfix reload" to make the configuration changes effective.
Whenever a suspect daemon process is started, an output file is created, named after the daemon
and process ID (for example, smtpd.12345.log). When the process crashes, a stack trace (with
output from the "where" command) is written to its logfile.
Unreasonable behavior
Sometimes the behavior exhibited by Postfix just does not match the source code. Why can a
program deviate from the instructions given by its author? There are two possibilities.
● The compiler has erred. This rarely happens.
● The hardware has erred. Does the machine have ECC memory?

In both cases, the program being executed is not the program that was supposed to be executed,
so anything could happen.
There is a third possibility:
● Bugs in system software (kernel or libraries).
Hardware-related failures usually do not reproduce in exactly the same way after power cycling
and rebooting the system. There's little Postfix can do about bad hardware. Be sure to use
hardware that at the very least can detect memory errors. Otherwise, Postfix will just be waiting
to be hit by a bit error. Critical systems deserve real hardware.
When a compiler makes an error, the problem can be reproduced whenever the resulting program
is run. Compiler errors are most likely to happen in the code optimizer. If a problem is
reproducible across power cycles and system reboots, it can be worthwhile to rebuild Postfix with
optimization disabled, and to see if optimization makes a difference.
In order to compile Postfix with optimizations turned off:
% make tidy
% make makefiles OPT=
This produces a set of Makefiles that do not request compiler optimization.
Once the makefiles are set up, build the software:
% make
% su
# make install
If the problem goes away, then it is time to ask your vendor for help.
Reporting problems to postfix-users@postfix.org

The people who participate on the postfix-users@postfix.org are very helpful, especially if YOU
provide them with sufficient information. Remember, these volunteers are willing to help, but
their time is limited.
When reporting a problem, be sure to include the following information.

● A summary of the problem. Please do not just send some logging without explanation of
what YOU believe is wrong.
● Consider using a test email address so that you don't have to reveal email addresses of
innocent people.
● If you can't use a test email address, please anonymize information consistently. Replace
each letter by "A", each digit by "D" so that the helpers can still recognize syntactical
errors.
● Complete error messages. Please use cut-and-paste, or use attachments, instead of reciting
information from memory.
● Postfix logging. See the text at the top of the DEBUG_README document to find out
where logging is stored. Please do not frustrate the helpers by word wrapping the logging.
● Output from "postconf -n". Please do not send your main.cf file. Or better, provide output
from the "postfinger" tool.
● If the problem is about too much mail in the queue, consider including output from the
qshape tool, as described in the QSHAPE_README file.
● If the problem is protocol related (connections time out or an SMTP server complains
about syntax errors etc.) consider recording a session with tcpdump, as described in the
DEBUG_README document.

Postfix manual - smtp-source(1)
SMTP-SOURCE(1) SMTP-SOURCE
(1)
NAME
smtp-source - multi-threaded SMTP/LMTP test generator
SYNOPSIS
smtp-source [options] [inet:]host[:port]
smtp-source [options] unix:pathname
DESCRIPTION
smtp-source connects to the named host and TCP
port
(default: port 25) and sends one or more messages to
it,
either sequentially or in parallel. The program
speaks
either SMTP (default) or LMTP. Connections can be made
to
UNIX-domain and IPv4 or IPv6 servers. IPv4 and IPv6
are
the default.
Arguments:
-4 Connect to the server with IPv4. This option has

no
effect when Postfix is built without IPv6
support.
-6 Connect to the server with IPv6. This option is

not
available when Postfix is built without IPv6
sup-
port.
-c Display a running counter that is incremented

each
time an SMTP DATA command completes.
http://www.subneural.net/postfix-master/smtp-source.1.html (1 of 4)01/16/2005 15:46:44

-C count
When a host sends RESET instead of SYN|ACK,
try
count times before giving up. The default count
is
1. Specify a larger count in order to work around
a
problem with TCP/IP stacks that send RESET when
the
listen queue is full.
-d Don't disconnect after sending a message; send

the
next message over the same connection.
-f from
Use the specified sender address
(default:
<foo@myhostname>).
-o Old mode: don't send HELO, and don't send

message
headers.
-l length
Send length bytes as message payload. The
length
does not include message headers.
-L Speak LMTP rather than SMTP.
-m message_count
Send the specified number of messages (default:
1).
-N Prepend a non-repeating sequence number to

each
recipient address. This avoids the artificial
100%
hit rate in the resolve and rewrite client
caches
and exercises the trivial-rewrite daemon,

better
approximating Postfix performance under real-
life
work-loads.
-r recipient_count
Send the specified number of recipients per
trans-
action (default: 1). Recipient names are
generated
by prepending a number to the recipient address.
-s session_count
Run the specified number of SMTP sessions in
paral-
lel (default: 1).
-S subject
Send mail with the named subject line
(default:
none).
-t to Use the specified recipient address

(default:
<foo@myhostname>).
-R interval
Wait for a random period of time 0 <= n <=
interval
between messages. Suspending one thread does
not
affect other delivery threads.
-w interval
Wait a fixed time between messages. Suspending
one
thread does not affect other delivery threads.
[inet:]host[:port]
Connect via TCP to host host, port port.
The
default port is smtp.

unix:pathname
Connect to the UNIX-domain socket at pathname.
BUGS
No SMTP command pipelining support.
SEE ALSO
smtp-sink(1), SMTP/LMTP message dump
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
SMTP-SOURCE
(1)

Postfix manual - smtp-sink(1)
SMTP-SINK(1) SMTP-SINK
(1)
NAME
smtp-sink - multi-threaded SMTP/LMTP test server
SYNOPSIS
smtp-sink [options] [inet:][host]:port backlog
smtp-sink [options] unix:pathname backlog
DESCRIPTION
smtp-sink listens on the named host (or address) and
port.
It takes SMTP messages from the network and throws
them
away. The purpose is to measure client performance,
not
protocol compliance.
Connections can be accepted on IPv4 or IPv6 endpoints,

or
on UNIX-domain sockets. IPv4 and IPv6 are the
default.
This program is the complement of the smtp-source(1)
pro-
gram.
Arguments:
-4 Support IPv4 only. This option has no effect

when
Postfix is built without IPv6 support.
-6 Support IPv6 only. This option is not

available
when Postfix is built without IPv6 support.
-a Do not announce SASL authentication support.
-c Display a running counter that is updated
http://www.subneural.net/postfix-master/smtp-sink.1.html (1 of 4)01/16/2005 15:46:45

whenever
an SMTP QUIT command is executed.
-C Disable XCLIENT support.
-e Do not announce ESMTP support.
-f command,command,...
Reject the specified commands with a hard
(5xx)
error code.
-F Disable XFORWARD support.
-h hostname
Use hostname in the SMTP greeting, in the
HELO
response, and in the EHLO response. The
default
hostname is "smtp-sink".
-L Enable LMTP instead of SMTP.
-n count
Terminate after count sessions. This is for
testing
purposes.
-p Do not announce support for ESMTP command

pipelin-
ing.
-P Change the server greeting so that it appears

to
come through a CISCO PIX system. Implies -e.
-q command,command,...
Disconnect (without replying) after receiving
one
of the specified commands.
-r command,command,...
Reject the specified commands with a soft

(4xx)
error code.
-s command,command,...
Log the named commands to syslogd. Examples
of
commands that can be logged are HELO, EHLO,
LHLO,
MAIL, RCPT, VRFY, RSET, NOOP, and QUIT.
Separate
command names by white space or commas, and
use
quotes to protect white space from the shell.
Com-
mand names are case-insensitive.
-v Show the SMTP conversations.
-w delay
Wait delay seconds before responding to a DATA
com-
mand.
-8 Do not announce 8BITMIME support.
[inet:][host]:port
Listen on network interface host (default:
any
interface) TCP port port. Both host and port may
be
specified in numeric or symbolic form.
unix:pathname
Listen on the UNIX-domain socket at pathname.
backlog
The maximum length the queue of pending
connec-
tions, as defined by the listen(2) call.
SEE ALSO
smtp-source(1), SMTP/LMTP message generator

LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
SMTP-SINK
(1)

Postfix manual - qmqp-source(1)
QMQP-SOURCE(1) QMQP-SOURCE
(1)
NAME
qmqp-source - multi-threaded QMQP test generator
SYNOPSIS
qmqp-source [options] [inet:]host[:port]
qmqp-source [options] unix:pathname
DESCRIPTION
qmqp-source connects to the named host and TCP
port
(default 628) and sends one or more messages to it,
either
sequentially or in parallel. The program speaks the
QMQP
protocol. Connections can be made to UNIX-domain and
IPv4
or IPv6 servers. IPv4 and IPv6 are the default.
Options:
-4 Connect to the server with IPv4. This option has

no
effect when Postfix is built without IPv6
support.
-6 Connect to the server with IPv6. This option is

not
available when Postfix is built without IPv6
sup-
port.
-c Display a running counter that is incremented

each
time a delivery completes.
-C count
When a host sends RESET instead of SYN|ACK,
http://www.subneural.net/postfix-master/qmqp-source.1.html (1 of 3)01/16/2005 15:46:45

try
count times before giving up. The default count
is
1. Specify a larger count in order to work around
a
problem with TCP/IP stacks that send RESET when
the
listen queue is full.
-f from
Use the specified sender address
(default:
<foo@myhostname>).
-l length
Send length bytes as message payload. The
length
includes the message headers.
-m message_count
Send the specified number of messages (default:
1).
-r recipient_count
Send the specified number of recipients per
trans-
action (default: 1). Recipient names are
generated
by prepending a number to the recipient address.
-s session_count
Run the specified number of QMQP sessions in
paral-
lel (default: 1).
-t to Use the specified recipient address

(default:
<foo@myhostname>).
-R interval
Wait for a random period of time 0 <= n <=
interval

between messages. Suspending one thread does

not
affect other delivery threads.
-w interval
Wait a fixed time between messages. Suspending
one
thread does not affect other delivery threads.
SEE ALSO
qmqp-sink(1), QMQP message dump
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
QMQP-SOURCE
(1)

Postfix manual - qmqp-sink(1)
QMQP-SINK(1) QMQP-SINK
(1)
NAME
qmqp-sink - multi-threaded QMQP test server
SYNOPSIS
qmqp-sink [-46cv] [-x time] [inet:][host]:port backlog
qmqp-sink [-46cv] [-x time] unix:pathname backlog
DESCRIPTION
qmqp-sink listens on the named host (or address) and
port.
It receives messages from the network and throws
them
away. The purpose is to measure QMQP client
performance,
not protocol compliance. Connections can be accepted
on
IPv4 or IPv6 endpoints, or on UNIX-domain sockets.
IPv4
and IPv6 are the default. This program is the
complement
of the qmqp-source(1) program.
-4 Support IPv4 only. This option has no effect

when
Postfix is built without IPv6 support.
-6 Support IPv6 only. This option is not

available
when Postfix is built without IPv6 support.
-c Display a running counter that is updated

whenever
a delivery is completed.
-v Increase verbosity. Specify -v -v to see some

of
the QMQP conversation.
http://www.subneural.net/postfix-master/qmqp-sink.1.html (1 of 2)01/16/2005 15:46:45

Postfix manual - qmqp-sink(1)
-x time
Terminate after time seconds. This is to
facilitate
memory leak testing.
SEE ALSO
qmqp-source(1), QMQP message generator
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
QMQP-SINK
(1)
http://www.subneural.net/postfix-master/qmqp-sink.1.html (2 of 2)01/16/2005 15:46:45

Postfix manual - anvil(8)
ANVIL(8) ANVIL
(8)
NAME
anvil - Postfix session count and request rate control
SYNOPSIS
anvil [generic Postfix daemon options]
DESCRIPTION
The Postfix anvil server maintains short-term
statistics
to defend against clients that hammer a server with
either
too many simultaneous sessions, or with too many
succes-
sive requests within a configurable time interval.
This
server is designed to run under control by the
Postfix
master server.
The anvil server maintains no persistent database.

Stan-
dard library utilities do not meet Postfix performance
and
robustness requirements.
CONNECTION COUNT/RATE LIMITING

When a remote client connects, a connection count
(or
rate) limited server should send the following request
to
the anvil server:
request=connect
ident=string
This registers a new connection for the (service,

client)
combination specified with ident. The anvil server
http://www.subneural.net/postfix-master/anvil.8.html (1 of 7)01/16/2005 15:46:46

answers
with the number of simultaneous connections and the
number
of connections per unit time for that (service,
client)
combination:
status=0
count=number
rate=number
The rate is computed as the number of connections

that
were registered in the current "time unit" interval.
It
is left up to the server to decide if the remote
client
exceeds the connection count (or rate) limit.
When a remote client disconnects, a connection count

(or
rate) limited server should send the following request
to
the anvil server:
request=disconnect
ident=string
This registers a disconnect event for the

(service,
client) combination specified with ident. The anvil
server
replies with:
status=0
MESSAGE RATE LIMITING

When a remote client sends a message delivery request,
a
message rate limited server should send the
following
request to the anvil server:

request=message
ident=string
This registers a message delivery request for the

(ser-
vice, client) combination specified with ident. The
anvil
server answers with the number of message
delivery
requests per unit time for that (service, client)
combina-
tion:
status=0
rate=number
In order prevent the anvil server from discarding

client
request rates too early or too late, a message rate
lim-
ited service should also register connect/
disconnect
events.
RECIPIENT RATE LIMITING

When a remote client sends a recipient address, a
recipi-
ent rate limited server should send the following
request
to the anvil server:
request=recipient
ident=string
This registers a recipient address for the

(service,
client) combination specified with ident. The anvil
server
answers with the number of recipient addresses per
unit

time for that (service, client) combination:
status=0
rate=number
In order prevent the anvil server from discarding

client
request rates too early or too late, a recipient rate
lim-
ited service should also register connect/
disconnect
events.
SECURITY
The anvil server does not talk to the network or to
local
users, and can run chrooted at fixed low privilege.
The anvil server maintains an in-memory table with

infor-
mation about recent clients of a connection count
(or
rate) limited service. Although state is kept only
tem-
porarily, this may require a lot of memory on systems
that
handle connections from many remote clients. To
reduce
memory usage, reduce the time unit over which state
is
kept.
DIAGNOSTICS
Upon exit, and every anvil_status_update_time seconds,

the
server logs the maximal count and rate values
measured,
together with (service, client) information and the

time
of day associated with those events. In order to
avoid
unnecessary overhead, no measurements are done for
activ-
ity that isn't concurrency limited or rate limited.
BUGS
Systems behind network address translating routers
or
proxies appear to have the same client address and can
run
into connection count and/or rate limits falsely.
In this preliminary implementation, a count (or rate)

lim-
ited server can have only one remote client at a time.
If
a server reports multiple simultaneous clients, all
but
the last reported client are ignored.
Changes to main.cf are picked up automatically as anvil
(8)
the

See
anvil_rate_time_unit (60s)
The time unit over which client connection
rates
and other rates are calculated.
anvil_status_update_time (600s)
How frequently the anvil(8) connection and
rate
limiting server logs peak usage information.


and
to
a
ipc_timeout (3600s)
information
max_idle (100s)
Postfix
request
before exiting.
max_use (100)
a
pro-
cess.
daemon
process.

pro-
"smtpd"
SEE ALSO
README FILES
TUNING_README, performance tuning
LICENSE
this
software.
HISTORY
The anvil service was introduced with Postfix 2.1.
AUTHOR(S)
Wietse Venema
P.O. Box 704
ANVIL
(8)

Postfix manual - relocated(5)
RELOCATED(5) RELOCATED
(5)
NAME
relocated - format of Postfix relocated table
SYNOPSIS
postmap /etc/postfix/relocated
DESCRIPTION
The optional relocated table provides the information
that
is used in "user has moved to new_location" bounce
mes-
sages.
Normally, the relocated table is specified as a text

file
The
for
command
postmap /etc/postfix/relocated in order to rebuild
the
indexed file after changing the relocated table.

NIS,
ordinary
indexed files.

regular-
expres-
In
http://www.subneural.net/postfix-master/relocated.5.html (1 of 6)01/16/2005 15:46:46

different
TABLES"
Table lookups are case insensitive.
TABLE FORMAT
follows:
o An entry has one of the following form:

pattern new_location
Where new_location specifies contact
information
such as an email address, or perhaps a
street
address or telephone number.

ignored,
character
is a `#'.

A
logi-
cal line.

from
are
user@domain
Matches user@domain. This form has precedence
over
all other forms.

user Matches user@site when site is $myorigin, when

site
is listed in $mydestination, or when site is
listed
in $inet_interfaces or $proxy_interfaces.
@domain
Matches every address in domain. This form has
the
lowest precedence.
ADDRESS EXTENSION
recip-
order
and
@domain.

when
the table is given in the form of regular expressions
or
when lookups are directed to a TCP-based server. For
a
description of regular expression lookup table syntax,
see
regexp_table(5) or pcre_table(5). For a description of
the
TCP client/server table lookup protocol, see tcp_table
(5).

to
mail
@domain
and

foo.

the
search
string.

with
from
TCP-BASED TABLES
when
descrip-
see
Postfix
version 2.1.

Thus,
their
broken
BUGS
conventions.
relevant.


See
relocated_maps
List of lookup tables for relocated users or
sites.
inet_interfaces
system
Post-
mydestination
considers
local.
myorigin
The domain that is appended to locally-posted
mail.
proxy_interfaces
on
transla-
tor.
SEE ALSO
trivial-rewrite(8), address resolver
README FILES

LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
RELOCATED
(5)

Postfix + Maildrop Howto
Introduction
This document discusses various options to plug the maildrop delivery agent into Postfix:
● Direct delivery without the local delivery agent

● Indirect delivery via the local delivery agent
● Credits
Direct delivery without the local delivery agent

Postfix can be configured to deliver mail directly to maildrop, without using the local(8)
delivery agent as an intermediate. This means that you do not get local aliases(5) expansion or
$HOME/.forward file processing. You would typically do this for hosted domains with
recipients that don't have UNIX home directories.
The following example shows how to use maildrop for some.domain and for someother.
domain.
2 maildrop_destination_recipient_limit = 1
3 virtual_mailbox_domains = some.domain
someother.domain
4 virtual_transport = maildrop
5 virtual_mailbox_maps = hash:/etc/postfix/
virtual_mailbox
6 virtual_alias_maps = hash:/etc/postfix/
virtual_alias
7
8 /etc/postfix/virtual_mailbox:
http://www.subneural.net/postfix-master/MAILDROP_README.html (1 of 4)01/16/2005 15:46:47

9 user1@some.domain ...text here does not

matter...
10 user2@some.domain ...text here does not
matter...
11 user3@someother.domain ...text here does not
matter...
12
13 /etc/postfix/virtual_alias:
14 postmaster@some.domain postmaster
15 postmaster@someother.domain postmaster
● Line 2 is needed so that Postfix will provide one recipient at a time to the maildrop
delivery agent.
● Line 3 informs Postfix that some.domain and someother.domain are so-called virtual
mailbox domains. Instead of listing the names in main.cf you can also list them in a file;
see the virtual_mailbox_domains documentation for details.
● Line 4 specifies that mail for some.domain and someother.domain should be delivered
by the maildrop delivery agent.
● Lines 5 and 8-11 specify what recipients the Postfix SMTP server should receive mail
for. This prevents the mail queue from becoming clogged with undeliverable messages.
Specify an empty value ("virtual_mailbox_maps =") to disable this feature.
● Lines 6 and 13-15 redirect mail for postmaster to the local postmaster. RFC 821
requires that every domain has a postmaster address.
The vmail userid as used below is the user that maildrop should run as. This would be the
owner of the virtual mailboxes if they all have the same owner. If maildrop is suid (see
maildrop documentation), then maildrop will change to the appropriate owner to deliver the
mail.
Note: Do not use the postfix user as the maildrop user.
maildrop unix - n n -
- pipe
flags=DRhu user=vmail argv=/path/to/maildrop -d
${recipient}

If you want to support user+extension@domain style addresses, use the following instead:
maildrop unix - n n -
- pipe
flags=DRhu user=vmail argv=/path/to/maildrop
-d ${user}@${nexthop} ${extension} ${recipient}
${user} ${nexthop}
The mail is delivered to ${user}@${nexthop} (match key for maildrop userdb lookup). The
${extension} and the other address components are available to maildrop rules as $1, $2, $3, ...
and can be omitted from master.cf or ignored by maildrop when not needed.
Indirect delivery via the local delivery agent

Postfix can be configured to deliver mail to maildrop via the local delivery agent. This is
slightly less efficient than the "direct" approach discussed above, but gives you the
convenience of local aliases(5) expansion and $HOME/.forward file processing. You would
typically use this for domains that are listed in mydestination and that have users with a UNIX
system account.
To configure maildrop delivery for all UNIX system accounts:
mailbox_command = /path/to/maildrop -d ${USER}
Note: ${USER} is spelled in upper case.
To enable maildrop delivery for specific users only, you can use the Postfix local(8) delivery
agent's mailbox_command_maps feature:
mailbox_command_maps = /etc/postfix/
mailbox_commands
/etc/postfix/mailbox_commands:
you /path/to/maildrop -d ${USER}
Maildrop delivery for specific users is also possible by invoking it from the user's $HOME/.
forward file:

/home/you/.forward:
"|/path/to/maildrop -d ${USER}"
Credits
● The original text was kindly provided by Russell Mosemann.
● Victor Duchovni provided tips for supporting user+foo@domain addresses.
● Tonni Earnshaw contributed text about delivery via the local(8) delivery agent.

Postfix and UUCP
Postfix and UUCP
Using UUCP over TCP

Despite a serious lack of sex-appeal, email via UUCP over TCP is a practical option for sites
without permanent Internet connections, and for sites without a fixed IP address. For first-hand
information, see the following guides:
● Jim Seymour's guide for using UUCP over TCP at http://jimsun.LinxNet.com/jdp/

uucp_over_tcp/index.html,
● Craig Sanders's guide for SSL-encrypted UUCP over TCP using stunnel at http://taz.net.
au/postfix/uucp/.
Here's a graphical description of what this document is about:
LAN to Internet
Local network <--- <--- UUCP --- <--->
UUCP to UUCP
> > Internet
Gateway Gateway
And here's the table of contents of this document:
● Setting up a Postfix Internet to UUCP gateway

● Setting up a Postfix LAN to UUCP gateway
Setting up a Postfix Internet to UUCP gateway

Here is how to set up a machine that sits on the Internet and that forwards mail to a LAN that is
connected via UUCP. See the LAN to UUCP gateway section for the other side of the story.
● You need an rmail program that extracts the sender address from mail that arrives via
http://www.subneural.net/postfix-master/UUCP_README.html (1 of 4)01/16/2005 15:46:47

Postfix and UUCP
UUCP, and that feeds the mail into the Postfix sendmail command. Most UNIX
systems come with an rmail utility. If you're in a pinch, try the one bundled with the
Postfix source code in the auxiliary/rmail directory.
● Define a pipe(8) based mail delivery transport for delivery via UUCP:
uucp unix - n n -
- pipe
flags=F user=uucp argv=uux -r -n -z -a$sender -
$nexthop!rmail ($recipient)
This runs the uux command to place outgoing mail into the UUCP queue after replacing
$nexthop by the next-hop hostname (the receiving UUCP host) and after replacing
$recipient by the recipients. The pipe(8) delivery agent executes the uux command
without assistance from the shell, so there are no problems with shell meta characters in
command-line parameters.
● Specify that mail for example.com, should be delivered via UUCP, to a host named
uucp-host:
example.com uucp:uucp-host
.example.com uucp:uucp-host
See the transport(5) manual page for more details.
● Execute the command "postmap /etc/postfix/transport" whenever you change the

transport file.
● Enable transport table lookups:
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".
● Add example.com to the list of domains that your site is willing to relay mail for.

Postfix and UUCP
relay_domains = example.com ...other relay domains...
See the relay_domains configuration parameter description for details.
● Execute the command "postfix reload" to make the changes effective.
Setting up a Postfix LAN to UUCP gateway

Here is how to relay mail from a LAN via UUCP to the Internet. See the Internet to UUCP
gateway section for the other side of the story.
● You need an rmail program that extracts the sender address from mail that arrives via
UUCP, and that feeds the mail into the Postfix sendmail command. Most UNIX
systems come with an rmail utility. If you're in a pinch, try the one bundled with the
Postfix source code in the auxiliary/rmail directory.
● Specify that all remote mail must be sent via the uucp mail transport to your UUCP
gateway host, say, uucp-gateway:
relayhost = uucp-gateway
default_transport = uucp
Postfix 2.0 and later also allows the following more succinct form:
default_transport = uucp:uucp-gateway
● Define a pipe(8) based message delivery transport for mail delivery via UUCP:
uucp unix - n n -
- pipe
flags=F user=uucp argv=uux -r -n -z -a$sender -
$nexthop!rmail ($recipient)
This runs the uux command to place outgoing mail into the UUCP queue. It 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

Postfix and UUCP
the shell, so there are no problems with shell meta characters.
● Execute the command "postfix reload" to make the changes effective.

Postfix manual - postfix(1)
POSTFIX(1) POSTFIX
(1)
NAME
postfix - Postfix control program
SYNOPSIS
postfix [-Dv] [-c config_dir] command
DESCRIPTION
This command is reserved for the superuser. To
submit
mail, use the Postfix sendmail command.
The postfix command controls the operation of the

Postfix
mail system: start or stop the master daemon, do a
health
check, and other maintenance.
The postfix command sets up a standardized environment

and
runs the postfix-script shell script to do the
actual
work.
The following commands are implemented:
check Validate the Postfix mail system

configuration.
Warn about bad directory/file ownership or
permis-
sions, and create missing directories.
start Start the Postfix mail system. This also runs

the
configuration check described above.
stop Stop the Postfix mail system in an orderly

fashion.
Running processes are allowed to terminate at
http://www.subneural.net/postfix-master/postfix.1.html (1 of 9)01/16/2005 15:46:48

their
earliest convenience.
Note: in order to refresh the Postfix mail

system
after a configuration change, do not use the
start
and stop commands in succession. Use the
reload
command instead.
abort Stop the Postfix mail system abruptly. Running

pro-
cesses are signaled to stop immediately.
flush Force delivery: attempt to deliver every message

in
the deferred mail queue. Normally, attempts
to
deliver delayed mail happen at regular
intervals,
the interval doubling after each failed attempt.

frequently
all
other mail.
reload Re-read configuration files. Running processes

ter-
minate at their earliest convenience.
set-permissions [name=value ...]

Set the ownership and permissions of
Postfix
related files and directories, as specified in
the
postfix-files file.
Specify name=value to override and update

specific
main.cf configuration parameters. Use this,

for
example, to change the mail_owner or
setgid_group
setting for an already installed Postfix system.

later.
upgrade-configuration [name=value ...]

Update the main.cf and master.cf files with
infor-
mation that Postfix needs in order to run: add
or
update services, and add or update
configuration
parameter settings.
Specify name=value to override and update

specific
main.cf configuration parameters.

later.
The following options are implemented:
-c config_dir
Read the main.cf and master.cf configuration
files
in the named directory instead of the default
con-
figuration directory. Use this to
distinguish
between multiple Postfix instances on the
same
host.
-D (with postfix start only)

Run each Postfix daemon under control of a
debugger
as specified via the debugger_command
configuration

parameter.

Mul-
increasingly
verbose.
ENVIRONMENT
The postfix command exports the following
environment
variables before executing the postfix-script file:
MAIL_CONFIG
This is set when the -c command-line option is
pre-
sent.
MAIL_VERBOSE
This is set when the -v command-line option is
pre-
sent.
MAIL_DEBUG
This is set when the -D command-line option is
pre-
sent.
The following main.cf configuration parameters
are
exported as environment variables with the same names:

com-
mands.

and
daemon programs.


and

direc-
tory.
queue
setgid_group (postdrop)
The group ownership of set-gid Postfix commands
and
of group-writable Postfix directories.
sendmail_path (see 'postconf -d' output)

A Sendmail compatibility feature that specifies
the
location of the Postfix sendmail(1) command.
newaliases_path (see 'postconf -d' output)

Sendmail compatibility feature that specifies
the
location of the newaliases(1) command.
mailq_path (see 'postconf -d' output)

Sendmail compatibility feature that specifies
where
the Postfix mailq(1) command is installed.
html_directory (see 'postconf -d' output)

The location of Postfix HTML files that
describe
how to build, configure or operate a specific
Post-

fix subsystem or feature.
manpage_directory (see 'postconf -d' output)

Where the Postfix manual pages are installed.
readme_directory (see 'postconf -d' output)

The location of Postfix README files that
describe
how to build, configure or operate a specific
Post-
fix subsystem or feature.
Other configuration parameters:

and

Postfix
pro-
cess.
pro-
"smtpd"
FILES
/etc/postfix/main.cf, Postfix configuration parameters
/etc/postfix/master.cf, Postfix daemon processes
/etc/postfix/postfix-files, file/directory permissions
/etc/postfix/postfix-script, administrative commands
/etc/postfix/post-install, post-installation

configuration
SEE ALSO
Commands:
postcat(1), examine Postfix queue file
postkick(1), trigger Postfix daemon
postlock(1), Postfix-compatible locking
postlog(1), Postfix-compatible logging
postqueue(1), Postfix mail queue control
postsuper(1), Postfix housekeeping
sendmail(1), Sendmail compatibility interface
Postfix configuration:
master(5), Postfix master.cf file syntax
postconf(5), Postfix main.cf file syntax
Table-driven mechanisms:
access(5), Postfix SMTP access control table
aliases(5), Postfix alias database
header_checks(5), body_checks(5), content inspection
canonical(5), Postfix address rewriting
relocated(5), Users that have moved
transport(5), Postfix routing table
virtual(5), Postfix virtual aliasing
Table lookup mechanisms:

cidr_table(5), Associate CIDR pattern with value
ldap_table(5), Postfix LDAP client
mysql_table(5), Postfix MYSQL client
nisplus_table(5), Postfix NIS+ client
pcre_table(5), Associate PCRE pattern with value
pgsql_table(5), Postfix PostgreSQL client
regexp_table(5), Associate POSIX regexp pattern with
value
tcp_table(5), Postfix client-server table lookup
Daemon processes:

anvil(8), Postfix connection/rate limiting

bounce(8), defer(8), trace(8), Delivery status reports
cleanup(8), canonicalize and enqueue message
discard(8), Postfix discard delivery agent
error(8), Postfix error delivery agent
flush(8), Postfix fast ETRN service
lmtp(8), Postfix LMTP client
local(8), Postfix local delivery agent
master(8), Postfix master daemon
oqmgr(8), old Postfix queue manager
pickup(8), Postfix local mail pickup
pipe(8), deliver mail to non-Postfix command
proxymap(8), Postfix lookup table proxy server
qmgr(8), Postfix queue manager
qmqpd(8), Postfix QMQP server
scache(8), Postfix connection cache manager
showq(8), list Postfix mail queue
smtp(8), Postfix SMTP client
spawn(8), run non-Postfix server
tlsmgr(8), Postfix TLS cache and randomness manager
trivial-rewrite(8), Postfix address rewriting
verify(8), Postfix address verification
virtual(8), Postfix virtual delivery agent
Other:
README FILES
OVERVIEW, overview of Postfix commands and processes
BASIC_CONFIGURATION_README, Postfix basic configuration
ADDRESS_REWRITING_README, Postfix address rewriting
SMTPD_ACCESS_README, SMTP relay/access control
CONTENT_INSPECTION_README, Postfix content inspection
QSHAPE_README, Postfix queue analysis
LICENSE
this

software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
POSTFIX
(1)

Postfix manual - postkick(1)
POSTKICK(1) POSTKICK
(1)
NAME
postkick - kick a Postfix service
SYNOPSIS
postkick [-c config_dir] [-v] class service request
DESCRIPTION
The postkick command sends request to the specified
ser-
vice over a local transport channel. This command
makes
Postfix private IPC accessible for use in, for
example,
shell scripts.
Options:
-c config_dir
named
configuration
directory.

Mul-
increasingly
verbose.
Arguments:
class Name of a class of local transport channel

end-
points, either public (accessible by any
local
user) or private (administrative access only).
http://www.subneural.net/postfix-master/postkick.1.html (1 of 3)01/16/2005 15:46:48

service
The name of a local transport endpoint within
the
named class.
request
A string. The list of valid requests is
service-
specific.
DIAGNOSTICS
Problems and transactions are logged to the standard
error
stream.
ENVIRONMENT
MAIL_CONFIG
MAIL_VERBOSE
relevant
parameter
exam-
ples.

and
application_event_drain_time (100s)
How long the postkick(1) command waits for
a
request to enter the server's input buffer
before
giving up.


direc-
tory.
FILES
/var/spool/postfix/private, private class endpoints
/var/spool/postfix/public, public class endpoints
SEE ALSO
qmgr(8), queue manager trigger protocol
pickup(8), local pickup daemon
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
POSTKICK
(1)

Postfix manual - postlock(1)
POSTLOCK(1) POSTLOCK
(1)
NAME
postlock - lock mail folder and execute command
SYNOPSIS
postlock [-c config_dir] [-l lock_style]
[-v] file command...
DESCRIPTION
The postlock command locks file for exclusive access,
and
executes command. The locking method is compatible
with
the Postfix UNIX-style local delivery agent.
Options:
-c config_dir
named
configuration
directory.
-l lock_style
Override the locking method specified via the
mail-
box_delivery_lock configuration parameter
(see
below).

Mul-
increasingly
verbose.
Arguments:
http://www.subneural.net/postfix-master/postlock.1.html (1 of 4)01/16/2005 15:46:48

file A mailbox file. The user should have read/

write
permission.
command...
The command to execute while file is locked
for
exclusive access. The command is
executed
directly, i.e. without interpretation by a
shell
command interpreter.
DIAGNOSTICS
The result status is 75 (EX_TEMPFAIL) when postlock
could
not perform the requested operation. Otherwise, the
exit
status is the exit status from the command.
BUGS
With remote file systems, the ability to acquire a
lock
does not necessarily eliminate access conflicts.
Avoid
file access by processes running on different machines.
ENVIRONMENT
MAIL_CONFIG
MAIL_VERBOSE
relevant
parameter
exam-
ples.

LOCKING CONTROLS
exclu-
exclusive
mailbox
mailbox_delivery_lock (see 'postconf -d' output)

How to lock a UNIX-style local(8) mailbox
before

fork_attempts (5)
The maximal number of attempts to fork() a
child
process.
fork_delay (1s)
The delay between attempts to fork() a child
pro-
cess.
and
SEE ALSO

LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
POSTLOCK
(1)

Postfix manual - postlog(1)
POSTLOG(1) POSTLOG
(1)
NAME
postlog - Postfix-compatible logging utility
SYNOPSIS
postlog [-iv] [-c config_dir]
[-p priority] [-t tag] [text...]
DESCRIPTION
The postlog command implements a Postfix-compatible
log-
ging interface for use in, for example, shell scripts.
By default, postlog logs the text given on the

command
line as one record. If no text is specified on the
command
line, postlog reads from standard input and logs
each
input line as one record.
Logging is sent to syslogd(8); when the standard

error
stream is connected to a terminal, logging is sent
there
as well.
The following options are implemented:
-c config_dir
named
configuration
directory.
-i Include the process ID in the logging tag.
-p priority
http://www.subneural.net/postfix-master/postlog.1.html (1 of 3)01/16/2005 15:46:49

Specifies the logging severity: info

(default),
warn, error, fatal, or panic.
-t tag Specifies the logging tag, that is, the

identifying
name that appears at the beginning of each
logging
record. A default tag is used when none is
speci-
fied.

Mul-
increasingly
verbose.
ENVIRONMENT
MAIL_CONFIG
Directory with the main.cf file.
relevant
to this program.

See

and
pro-


"smtpd"
SEE ALSO
syslogd(8), syslog daemon
LICENSE
this
software.
AUTHOR(S)
Wietse Venema
P.O. Box 704
POSTLOG
(1)

Postfix manual - nisplus_table(5)
NISPLUS_TABLE(5) NISPLUS_TABLE
(5)
NAME
nisplus_table - Postfix NIS+ client
SYNOPSIS
postmap -q "string" "nisplus:[name=%s];name.name."
postmap -q - "nisplus:[name=%s];name.name." <inputfile
DESCRIPTION
The Postfix mail system uses optional lookup
tables.
These tables are usually in dbm or db format.
Alterna-
tively, lookup tables can be specified as NIS+
databases.

sys-
tem supports use the "postconf -m" command.
To test Postfix NIS+ lookup tables, use the postmap

com-
mand as described in the SYNOPSIS above.
QUERY SYNTAX
Most of the NIS+ query is specified via the NIS+ map
name.
The general format of a Postfix NIS+ map name is as
fol-
lows:
nisplus:[name=%s];name.name.name.:column
Postfix NIS+ map names differ from what one normally

would
use with commands such as niscat:
o With each NIS+ table lookup, "%s" is replaced by
http://www.subneural.net/postfix-master/nisplus_table.5.html (1 of 3)01/16/2005 15:46:49

a
version of the lookup string. There can be
only
one "%s" instance in a Postfix NIS+ map name.
o Postfix NIS+ map names use ";" instead of

",",
because the latter character is special in
the
Postfix main.cf file. Postfix replaces ";"
charac-
ters in the map name by "," before making NIS
+
queries.
o The ":column" part in the NIS+ map name is not

part
of the actual NIS+ query. Instead, it specifies
the
number of the table column that provides the
lookup
result. When no ":column" is specified the
first
column (1) is used.
EXAMPLE
A NIS+ aliases map might be queried as follows:
alias_maps = dbm:/etc/mail/aliases,
nisplus:[alias=%s];mail_aliases.org_dir.
$mydomain.:1
This queries the local aliases file before the NIS+

file.
SEE ALSO
README FILES
LICENSE


this
software.
AUTHOR(S)
Geoff Gibbs
UK-HGMP-RC
Hinxton
Cambridge
CB10 1SB, UK
Based on the NIS client code:

Wietse Venema
P.O. Box 704
NISPLUS_TABLE
(5)

Postfix manual - flush(8)
FLUSH(8) FLUSH
(8)
NAME
flush - Postfix fast flush server
SYNOPSIS
flush [generic Postfix daemon options]
DESCRIPTION
The flush server maintains a record of deferred mail
by
destination. This information is used to improve the
per-
formance of the SMTP ETRN request, and of its command-
line
equivalent, "sendmail -qR" or "postqueue -f". This
pro-
gram expects to be run from the master(8) process
manager.
The record is implemented as a per-destination

logfile
with as contents the queue IDs of deferred mail. A
logfile
is append-only, and is truncated when delivery
is
requested for the corresponding destination. A
destination
is the part on the right-hand side of the right-most @
in
an email address.
Per-destination logfiles of deferred mail are

maintained
only for eligible destinations. The list of eligible
des-
tinations is specified with the fast_flush_domains
config-
uration parameter, which defaults to $relay_domains.
http://www.subneural.net/postfix-master/flush.8.html (1 of 6)01/16/2005 15:46:50

add sitename queueid

Inform the fast flush server that the message
with
the specified queue ID is queued for the
specified
destination.
send sitename
Request delivery of mail that is queued for
the
specified destination.
refresh
Refresh non-empty per-destination logfiles
that
were not read in $fast_flush_refresh_time hours,
by
simulating send requests (see above) for the
corre-
sponding destinations.
Delete empty per-destination logfiles that were

not
updated in $fast_flush_purge_time days.
This request completes in the background.
purge Do a refresh for all per-destination logfiles.
SECURITY
The fast flush server is not security-sensitive. It
does
not talk to the network, and it does not talk to
local
users. The fast flush server can run chrooted at
fixed
low privilege.
DIAGNOSTICS

BUGS
Fast flush logfiles are truncated only after a
"send"
request, not when mail is actually delivered, and
there-
fore can accumulate outdated or redundant data. In
order
to maintain sanity, "refresh" must be executed
periodi-
cally. This can be automated with a suitable wakeup
timer
setting in the master.cf configuration file.
Upon receipt of a request to deliver mail for an

eligible
destination, the flush server requests delivery of
all
messages that are listed in that destination's
logfile,
regardless of the recipients of those messages. This
is
not an issue for mail that is sent to a relay_domains
des-
tination because such mail typically only has
recipients
in one domain.
Changes to main.cf are picked up automatically as flush
(8)
the

See

and

to
a
for
queued
fast_flush_refresh_time (12h)
The time after which a non-empty but unread
per-
destination "fast flush" logfile needs to
be
refreshed.
fast_flush_purge_time (7d)
The time after which an empty per-destination
"fast
flush" logfile is deleted.
ipc_timeout (3600s)
information
max_idle (100s)
Postfix
request
before exiting.
max_use (100)

a

out-
put)
of
an
pro-
cess.
daemon
process.

direc-
tory.
pro-
"smtpd"
FILES
/var/spool/postfix/flush, "fast flush" logfiles.
SEE ALSO


README FILES
LICENSE
this
software.
HISTORY
AUTHOR(S)
Wietse Venema
P.O. Box 704
FLUSH
(8)

Postfix ETRN Howto
Postfix ETRN Howto
Purpose of the Postfix fast ETRN service

The SMTP ETRN command was designed for sites that have intermittent Internet connectivity.
With ETRN, a site can tell the mail server of its provider to "Please deliver all my mail now".
The SMTP server searches the queue for mail to the customer, and delivers that mail by
connecting to the customer's SMTP server. The mail is not delivered via the connection that
was used for sending ETRN.
Postfix versions before 1.0 (also known as version 20010228) implemented the ETRN command
in an inefficient manner: they simply attempted to deliver all queued mail. This is slow on mail
servers that queue mail for many customers.
As of version 1.0, Postfix has a fast ETRN implementation that does not require Postfix to
examine every queue file. Instead, Postfix maintains a record of what queue files contain mail for
destinations that are configured for ETRN service. ETRN service is no longer available for
domains that aren't configured for the service.
● Using the Postfix fast ETRN service

● How Postfix fast ETRN works
● Postfix fast ETRN service limitations
● Configuring the Postfix fast ETRN service
● Configuring a domain for ETRN service only
● Testing the Postfix fast ETRN service
Other documents with information on this subject:
● flush(8), flush service implementation
http://www.subneural.net/postfix-master/ETRN_README.html (1 of 6)01/16/2005 15:46:50

Postfix ETRN Howto
Using the Postfix fast ETRN service

The following is an example SMTP session that shows how an SMTP client requests the ETRN
service. Client commands are shown in bold font.
220 my.server.tld ESMTP Postfix

helo my.client.tld
250 Ok
etrn some.customer.domain
250 Queuing started
quit
221 Bye
As mentioned in the introduction, the mail is delivered by connecting to the customer's SMTP
server; it is not sent over the connection that was used to send the ETRN command.
The Postfix operator can request delivery for a specific customer by using the command
"sendmail -qRdestination" and, with Postfix version 1.1 and later, "postqueue -sdestination".
How Postfix fast ETRN works

When a Postfix delivery agent decides that mail must be delivered later, it sends the destination
domain name and the queue file name to the flush(8) daemon which maintains per-destination
logfiles with file names of queued mail. These logfiles are kept below $queue_directory/flush.
Per-destination logfiles are maintained only for destinations that are listed with the
$fast_flush_domains parameter and that have syntactically valid domain names.
One
Postfix Postfix
-(domain, queue ID)- -(queue ID)- logfile
delivery flush
> > per eligible
agent daemon
domain
When Postfix receives a request to "deliver mail for a domain now", the flush(8) daemon moves
all deferred queue files that are listed for that domain to the incoming queue, and requests that the
queue manager deliver them. In order to force delivery, the queue manager temporarily ignores
the lists of undeliverable destinations: the volatile in-memory list of dead domains, and the list of
message delivery transports specified with the defer_transports configuration parameter.
Postfix fast ETRN service limitations

Postfix ETRN Howto
The design of the flush(8) server and of the flush queue introduce a few limitations that should
not be an issue unless you want to turn on fast ETRN service for every possible destination.
● The flush(8) daemon maintains per-destination logfiles with queue file names. When a
request to "deliver mail now" arrives, Postfix will attempt to deliver all recipients in the
queue files that have mail for the destination in question. This does not perform well when
queue files have recipients in many different domains.
● The flush(8) daemon maintains per-destination logfiles only for destinations listed with
$fast_flush_domains. With other destinations it not possible to trigger delivery with
"sendmail -qRdestination" or, with Postfix version 1.1 and later, "postqueue -
sdestination".
● Up to and including early versions of Postfix version 2.1, the "fast flush" service may not
deliver some messages if the request to "deliver mail now" is received while a deferred
queue scan is already in progress. The reason is that the queue manager does not ignore
the volatile in-memory list of dead domains, and the list of message delivery transports
specified with the defer_transports configuration parameter.
Configuring the Postfix fast ETRN service

The behavior of the flush(8) daemon is controlled by parameters in the main.cf configuration file.
By default, Postfix "fast ETRN" service is available only for destinations that Postfix is willing to
relay mail to:
fast_flush_domains = $relay_domains
smtpd_etrn_restrictions = permit_mynetworks, reject
Notes:
● The relay_domains parameter specifies what destinations Postfix will relay to. For
destinations that are not eligible for the "fast ETRN" service, Postfix replies with an error
message.
● The smtpd_etrn_restrictions parameter limits what clients may execute the ETRN
command. By default, any client has permission.
To enable "fast ETRN" for some other destination, specify:

Postfix ETRN Howto
fast_flush_domains = $relay_domains, some.other.
domain
To disable "fast ETRN", so that Postfix rejects all ETRN requests and so that it maintains no per-
destination logfiles, specify:
fast_flush_domains =
Configuring a domain for ETRN service only

While an "ETRN" customer is off-line, Postfix will make spontaneous attempts to deliver mail to
it. These attempts are separated in time by increasing time intervals, ranging from
$minimal_backoff_time to $maximal_backoff_time, and should not be a problem unless a lot of
mail is queued.
To prevent Postfix from making spontaneous delivery attempts you can configure Postfix to
always defer mail for the "ETRN" customer. Mail is delivered only after the ETRN command or
with "sendmail -q", with "sendmail -qRdomain", or with "postqueue -sdomain"(Postfix version
1.1 and later only),
In the example below we configure an "etrn-only" delivery transport which is simply a duplicate
of the "smtp" and "relay" mail delivery transports. The only difference is that mail destined for
this delivery transport is deferred as soon as it arrives.
2 #
=============================================================
3 # service type private unpriv chroot wakeup
maxproc command
4 # (yes) (yes) (yes) (never)
(100)
5 #
=============================================================
6 smtp unix - - n -
- smtp
7 relay unix - - n -
- smtp
8 etrn-only unix - - n -
- smtp

Postfix ETRN Howto
9
11 relay_domains = customer.tld ...other domains...
12 defer_transports = etrn-only
14
16 customer.tld etrn-only:[mailhost.customer.tld]
Translation:
● Line 8: The "etrn-only" mail delivery service is a copy of the "smtp" and "relay" service.
● Line 11: Don't forget to authorize relaying for this customer, either via relay_domains or
with the permit_mx_backup feature.
● Line 12: The "etrn-only" mail delivery service is configured so that spontaneous mail
delivery is disabled.
● Lines 13-16: Mail for the customer is given to the "etrn-only" mail delivery service.
● Line 16: The "[mailhost.customer.tld]" turns off MX record lookups; you must specify
this if your Postfix server is the primary MX host for the customer's domain.
Testing the Postfix fast ETRN service

By default, "fast ETRN" service is enabled for all domains that match $relay_domains. If you run
Postfix with "fast ETRN" service for the very first time, you need to run "sendmail -q" once in
order to populate the per-site deferred mail logfiles. If you omit this step, no harm is done. The
logfiles will eventually become populated as Postfix routinely attempts to deliver delayed mail,
but that will take a couple hours. After the "sendmail -q" command has completed all delivery
attempts (this can take a while), you're ready to test the "fast ETRN" service.
To test the "fast ETRN" service, telnet to the Postfix SMTP server from a client that is allowed to
execute ETRN commands (by default, that's every client), and type the commands shown in
boldface:

helo my.client.tld
250 Ok
etrn some.customer.domain

Postfix ETRN Howto
250 Queuing started
where "some.customer.domain" is the name of a domain that has a non-empty logfile somewhere
under $queue_directory/flush.
In the maillog file, you should immediately see a couple of logfile records, as evidence that the
queue manager has opened queue files:
Oct 2 10:51:19 myhostname postfix/qmgr[51999]:

682E8440A4:
from=<whatever>, size=12345, nrcpt=1 (queue active)
Oct 2 10:51:19 myhostname postfix/qmgr[51999]:
02249440B7:
from=<whatever>, size=4711, nrcpt=1 (queue active)
What happens next depends on whether the destination is reachable. If it's not reachable, the mail
queue IDs will be added back to the some.customer.domain logfile under $queue_directory/flush.
Repeat the exercise with some other destination that your server is willing to relay to (any
domain listed in $relay_domains), but that has no mail queued. The text in bold face stands for
the commands that you type:

helo my.client.tld
250 Ok
etrn some.other.customer.domain
250 Queuing started
This time, the "ETRN"" command should trigger NO mail deliveries at all. If this triggers
delivery of all mail, then you used the wrong domain name, or "fast ETRN" service is turned off.
Finally, repeat the exercise with a destination that your mail server is not willing to relay to. It
does not matter if your server has mail queued for that destination.

helo my.client.tld
250 Ok
etrn not.a.customer.domain
459 <not.a.customer.domain>: service unavailable
In this case, Postfix should reject the request as shown above.

Postfix SASL Howto
Postfix SASL Howto

People who go to the trouble of installing Postfix may have the expectation that Postfix is more
secure than some other mailers. The Cyrus SASL library is a lot of code. With SASL
authentication enabled in the Postfix SMTP client and SMTP server, Postfix becomes as secure
as other mail systems that use the Cyrus SASL library.
How Postfix uses SASL authentication information

Postfix SASL support (RFC 2554) can be used to authenticate remote SMTP clients to the
Postfix SMTP server, and to authenticate the Postfix SMTP client to a remote SMTP server.
When receiving mail, Postfix logs the client-provided username, authentication method, and
sender address to the maillog file, and optionally grants mail access via the
permit_sasl_authenticated UCE restriction.
Postfix does not record the client's SASL authentication information in message headers, and
does not pass it on via SMTP commands when forwarding mail, because it is no-one else's
business to know the client username and authentication method. People who need to know can
find the information in the local Postfix maillog file. Some day, Postfix message headers will
be configurable and then one can record the SASL username without having to edit C code.
● What SASL versions are supported

● Building the SASL library
● Building Postfix with SASL authentication support
● Enabling SASL authentication in the Postfix SMTP server
● Testing SASL authentication in the Postfix SMTP server
http://www.subneural.net/postfix-master/SASL_README.html (1 of 9)01/16/2005 15:46:51

Postfix SASL Howto
● Trouble shooting the SASL internals

● Enabling SASL authentication in the Postfix SMTP client
● Credits
When sending mail, Postfix can look up the server hostname or destination domain (the address
right-hand part) in a table, and if a username/password is found, it will use that username and
password to authenticate to the server.
What SASL versions are supported

Postfix+SASL 1.5.5 was seen working on RedHat 6.1 (pwcheck_method set to shadow or
sasldb), Solaris 2.7 (pwcheck_method set to shadow or sasldb), and FreeBSD 3.4
(pwcheck_method set to sasldb). On RedHat 6.1, SASL 1.5.5 insisted on write access to /etc/
sasldb. Note that this seems to be related to the auto_transition switch in SASL. Note also that
the Cyrus SASL documentation says that it is pointless to enable that if you use "sasldb" for
"pwcheck_method". Later versions of the SASL 1.5.x series should also work.
Postfix+SASL 2.1.1 appears to work on Mandrake Linux 8.1 (pwcheck_method set to

saslauthd or auxprop). Note that the 'auxprop' pwcheck_method replaces the 'sasldb' method
from SASL 1.5.x. Postfix may need write access to /etc/sasldb2 if you use the auto_transition
feature, or if you use an authentication mechanism such as OTP (one-time passwords) that
needs to update secrets in the database.
Building the SASL library

Postfix appears to work with cyrus-sasl-1.5.5 or cyrus-sasl-2.1.1, which are available from:
ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/.
IMPORTANT: if you install the Cyrus SASL libraries as per the default, you will have to
symlink /usr/lib/sasl -> /usr/local/lib/sasl for version 1.5.5 or /usr/lib/sasl2 -> /usr/local/lib/
sasl2 for version 2.1.1.
Reportedly, Microsoft Internet Explorer version 5 requires the non-standard SASL LOGIN
authentication method. To enable this authentication method, specify ``./configure --enable-
login''.
Building Postfix with SASL authentication support

Postfix SASL Howto
To build Postfix with SASL authentication support, the following assumes that the Cyrus
SASL include files are in /usr/local/include, and that the Cyrus SASL libraries are in /usr/local/
lib.
On some systems this generates the necessary Makefile definitions:
(for SASL version 1.5.5):
% make tidy # if you have left-over files from a previous

build
% make makefiles CCARGS="-DUSE_SASL_AUTH -I/usr/local/
include" \
AUXLIBS="-L/usr/local/lib -lsasl"

build
include/sasl" \
AUXLIBS="-L/usr/local/lib -lsasl2"
On Solaris 2.x you need to specify run-time link information, otherwise ld.so will not find the
SASL shared library:

build
include" \
AUXLIBS="-L/usr/local/lib -R/usr/local/lib -lsasl"

build
include/sasl" \
AUXLIBS="-L/usr/local/lib -R/usr/local/lib -lsasl2"

Postfix SASL Howto
Enabling SASL authentication in the Postfix SMTP server

In order to enable SASL support in the SMTP server:
smtpd_sasl_auth_enable = yes
In order to allow mail relaying by authenticated clients:
permit_mynetworks
permit_sasl_authenticated ...
In /usr/local/lib/sasl/smtpd.conf (SASL version 1.5.5) or /usr/local/lib/sasl2/smtpd.conf (SASL

version 2.1.1) you need to specify how the server should validate client passwords.
In order to authenticate against the UNIX password database, try:
(SASL version 1.5.5)
/usr/local/lib/sasl/smtpd.conf:
pwcheck_method: pwcheck
/usr/local/lib/sasl2/smtpd.conf:
pwcheck_method: pwcheck
The name of the file in /usr/local/lib/sasl (SASL version 1.5.5) or /usr/local/lib/sasl2 (SASL
version 2.1.1) used by the SASL library for configuration can be set with:
smtpd_sasl_application_name = smtpd
The pwcheck daemon is contained in the cyrus-sasl source tarball.
IMPORTANT: postfix processes need to have group read+execute permission for the /var/
pwcheck directory, otherwise authentication attempts will fail.

Postfix SASL Howto
Alternately, in SASL 1.5.26 and later (including 2.1.1), try:
pwcheck_method: saslauthd
pwcheck_method: saslauthd
The saslauthd daemon is also contained in the cyrus-sasl source tarball. It is more flexible than
the pwcheck daemon, in that it can authenticate against PAM and various other sources. To use
PAM, start saslauthd with "-a pam".
In order to authenticate against SASL's own password database:
pwcheck_method: sasldb
pwcheck_method: auxprop
This will use the SASL password file (default: /etc/sasldb in version 1.5.5, or /etc/sasldb2 in
version 2.1.1), which is maintained with the saslpasswd or saslpasswd2 command (part of the
Cyrus SASL software). On some poorly-supported systems the saslpasswd command needs to
be run multiple times before it stops complaining. The Postfix SMTP server needs read access
to the sasldb file - you may have to play games with group access permissions. With the OTP
authentication mechanism, the SMTP server also needs write access to /etc/sasldb2 or /etc/
sasldb (or the back end SQL database, if used).
IMPORTANT: all users must be able to authenticate using ALL authentication mechanisms
advertised by Postfix, otherwise the negotiation might end up with an unsupported mechanism,
and authentication would fail. For example if you configure SASL to use saslauthd for
authentication against PAM (pluggable authentication modules), only the PLAIN and LOGIN

Postfix SASL Howto
mechanisms are supported and stand a chance to succeed, yet the SASL library would also
advertise other mechanisms, such as DIGEST-MD5. This happens because those mechanisms
are made available by other plugins, and the SASL library have no way to know that your only
valid authentication source is PAM. Thus you might need to limit the list of mechanisms
advertised by Postfix. This is only possible with SASL version 2.1.1 or later:
mech_list: plain login
For the same reasons you might want to limit the list of plugins used for authentication. With
SASL version 1.5.5 your only choice is to delete the corresponding libraries from /usr/local/lib/
sasl. With SASL version 2.1.1:
pwcheck_method: auxprop
auxprop_plugin: sql
IMPORTANT: To get sasldb running, make sure that you set the SASL domain (realm) to a
fully qualified domain name.
EXAMPLE:
% saslpasswd -c -u `postconf -h myhostname` exampleuser
% saslpasswd2 -c -u `postconf -h myhostname` exampleuser
You can find out SASL's idea about the realms of the users in sasldb with sasldblistusers
(SASL version 1.5.5) or sasldblistusers2 (SASL version 2.1.1).
On the Postfix side, you can have only one realm per smtpd instance, and only the users
belonging to that realm would be able to authenticate. The Postfix variable
smtpd_sasl_local_domain controls the realm used by smtpd:
smtpd_sasl_local_domain = $myhostname

Postfix SASL Howto
To run software chrooted with SASL support is an interesting exercise. It probably is not worth
the trouble.
Older Microsoft SMTP client software implements a non-standard version of the AUTH
protocol syntax, and expects that the SMTP server replies to EHLO with "250 AUTH=stuff"
instead of "250 AUTH stuff". To accommodate such clients in addition to conformant clients,
set "broken_sasl_auth_clients = yes" in the main.cf file.
Testing SASL authentication in the Postfix SMTP server

To test the server side, connect to the SMTP server, and you should be able to have a
conversation as shown below. Information sent by the client is shown in bold font.
220 server.host.tld ESMTP Postfix

EHLO client.host.tld
250-server.host.tld
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
250 8BITMIME
AUTH PLAIN dGVzdAB0ZXN0AHRlc3RwYXNz
235 Authentication successful
Instead of dGVzdAB0ZXN0AHRlc3RwYXNz, specify the base64 encoded form of username

\0username\0password (the \0 is a null byte). The example above is for a user named `test' with
password `testpass'.
In order to generate base64 encoded authentication information you can use one of the
following commands:
% printf 'username\0username\0password' | mmencode
% perl -MMIME::Base64 -e \
'print encode_base64("username\0username
\0password");'
The mmencode command is part of the metamail software. MIME::Base64 is available from
http://www.cpan.org/.
When posting logs of the SASL negotiations to public lists, please keep in mind that username/

Postfix SASL Howto
password information is trivial to recover from the base64-encoded form.
Trouble shooting the SASL internals

In the Cyrus SASL sources you'll find a subdirectory named "sample". Run make there, "su" to
the user postfix (or whatever your mail_owner directive is set to):
% su postfix
then run the resulting sample server and client in separate terminals. Strace / ktrace / truss the
server to see what makes it unhappy, and fix the problem. Repeat the previous step until you
can successfully authenticate with the sample client. Only then get back to Postfix.
Enabling SASL authentication in the Postfix SMTP client

Turn on client-side SASL authentication, and specify a table with per-host or per-destination
username and password information. Postfix first looks up the server hostname; if no entry is
found, then Postfix looks up the destination domain name (usually, the right-hand part of an
email address).
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/
sasl_passwd
/etc/postfix/sasl_passwd:
foo.com username:password
bar.com username
Note: some SMTP servers support PLAIN or LOGIN authentication only. By default, the
Postfix SMTP client does not use authentication methods that send plaintext passwords, and
defers delivery with the following error message: "Authentication failed: cannot SASL
authenticate to server". To enable plaintext authentication specify, for example:
smtp_sasl_security_options =
The SASL client password file is opened before the SMTP server enters the optional chroot
jail, so you can keep the file in /etc/postfix.

Postfix SASL Howto
Note: Some SMTP servers support authentication mechanisms that, although available on the
client system, may not in practice work or possess the appropriate credentials to authenticate to
the server. It is possible via the smtp_sasl_mechanism_filter parameter to further restrict the
list of server mechanisms that the smtp(8) client will take into consideration.
The Postfix SMTP client is backwards compatible with SMTP servers that use the non-
standard "AUTH=method..." syntax in response to the EHLO command; there is no Postfix
client configuration needed to work around it.
Credits
● Postfix SASL support was originally implemented by Till Franke of SuSE Rhein/Main
AG.
● Wietse trimmed down the code to only the bare necessities.
● Support for SASL version 2 was contributed by Jason Hoos.
● Liviu Daia added smtpd_sasl_application_name, split reject_sender_login_mismatch
into reject_authenticated_sender_login_mismatch and
reject_unauthenticated_sender_login_mismatch, and revised the docs.

Postfix VERP Howto
Postfix VERP Howto
Postfix VERP support

Postfix versions 1.1 and later support variable envelope return path addresses on request. When
VERP style delivery is requested, each recipient of a message receives a customized copy of
the message, with his/her own recipient address encoded in the envelope sender address.
For example, when VERP style delivery is requested, Postfix delivers mail from "owner-
listname@origin" for a recipient "user@domain", with a sender address that encodes
the recipient as follows:
owner-listname+user=domain@origin
Thus, undeliverable mail can reveal the undeliverable recipient address without requiring the
list owner to parse bounce messages.
The VERP concept was popularized by the qmail MTA and by the ezmlm mailing list
manager. See http://cr.yp.to/proto/verp.txt for the ideas behind this concept.
● Postfix VERP configuration parameters

● Using VERP with majordomo etc. mailing lists
● VERP support in the Postfix SMTP server
● VERP support in the Postfix sendmail command
● VERP support in the Postfix QMQP server
Postfix VERP configuration parameters

With Postfix, the whole process is controlled by four configuration parameters.
http://www.subneural.net/postfix-master/VERP_README.html (1 of 5)01/16/2005 15:46:51

Postfix VERP Howto
default_verp_delimiters (default value: +=)
What VERP delimiter characters Postfix uses when VERP style delivery is requested
but no explicit delimiters are specified.
verp_delimiter_filter (default: -+=)
What characters Postfix accepts as VERP delimiter characters on the sendmail

command line and in SMTP commands. Many characters must not be used as VERP
delimiter characters, either because they already have a special meaning in email
addresses (such as the @ or the %), because they are used as part of a username or
domain name (such as alphanumerics), or because they are non-ASCII or control
characters. And who knows, some characters may tickle bugs in vulnerable software,
and we would not want that to happen.
smtpd_authorized_verp_clients (default value: none)
What SMTP clients are allowed to request VERP style delivery. The Postfix QMQP
server uses its own access control mechanism, and local submission (via /usr/sbin/
sendmail etc.) is always authorized. To authorize a host, list its name, IP address, subnet
(net/mask) or parent .domain.
With Postfix versions 1.1 and 2.0, this parameter is called authorized_verp_clients
(default: $mynetworks).
disable_verp_bounces (default: no)
if Postfix sends one bounce report for multi-recipient VERP mail, or one bounce report
per recipient. The default, one per recipient, is what ezmlm needs.
Using VERP with majordomo etc. mailing lists

In order to make VERP useful with majordomo etc. mailing lists, you would configure the list
manager to submit mail according to one of the following two forms:
% sendmail -V -f owner-listname other-arguments...
% sendmail -V+= -f owner-listname other-arguments...

Postfix VERP Howto
The first form uses the default main.cf VERP delimiter characters. The second form allows you
to explicitly specify the VERP delimiter characters. The example shows the recommended
values.
This text assumes that you have set up an owner-listname alias that routes undeliverable mail to
a real person:
/etc/aliases:
owner-listname: yourname+listname
In order to process bounces we are going to make extensive use of address extension tricks.
You need to tell Postfix that + is the separator between an address and its optional address
extension, that address extensions are appended to .forward file names, and that address
extensions are to be discarded when doing alias expansions:
recipient_delimiter = +
forward_path = $home/.forward
${recipient_delimiter}${extension},
$home/.forward
propagate_unmatched_extensions = canonical,
virtual
(the last two parameter settings are default settings).
You need to set up a file named .forward+listname with the commands that process all the mail
that is sent to the owner-listname address:
~/.forward+listname:
"|/some/where/command ..."
With this set up, undeliverable mail for user@domain will be returned to the following address:
owner-listname+user=domain@your.domain
which is processed by the command in your .forward+listname file. The message should
contain, among others, a To: header with the encapsulated recipient sender address:
To: owner-listname+user=domain@your.domain

Postfix VERP Howto
It is left as an exercise for the reader to parse the To: header line and to pull out the
user=domain part from the recipient address.
VERP support in the Postfix SMTP server

The Postfix SMTP server implements a command XVERP to enable VERP style delivery. The
syntax allows two forms:
MAIL FROM:<sender@domain> XVERP
MAIL FROM:<sender@domain> XVERP=+=
The first form uses the default main.cf VERP delimiters, the second form overrides them
explicitly. The values shown are the recommended ones.
VERP support in the Postfix sendmail command

The Postfix sendmail command has a -V flag to request VERP style delivery. Specify one of
the following two forms:
% sendmail -V -f owner-listname ....
% sendmail -V+= -f owner-listname ....
The first form uses the default main.cf VERP delimiters, the second form overrides them
explicitly. The values shown are the recommended ones.
VERP support in the Postfix QMQP server

When the Postfix QMQP server receives mail with an envelope sender address of the form:
listname-@your.domain-@[]
Postfix generates sender addresses "listname-user=domain@your.domain", using "-

=" as the VERP delimiters because qmail/ezmlm expect this.
More generally, a sender address of "prefix@origin-@[]" requests VERP style delivery

with sender addresses of the form "prefixuser=domain@origin". However, Postfix
allows only VERP delimiters that are specified with the verp_delimiter_filter parameter. In

Postfix VERP Howto
particular, the "=" delimiter is required for qmail compatibility (see the qmail addresses(5)
manual page for details).

Postfix LDAP Howto
Postfix LDAP Howto
LDAP Support in Postfix

Postfix can use an LDAP directory as a source for any of its lookups: aliases(5), virtual(5),
canonical(5), etc. This allows you to keep information for your mail service in a replicated
network database with fine-grained access controls. By not storing it locally on the mail server,
the administrators can maintain it from anywhere, and the users can control whatever bits of it
you think appropriate. You can have multiple mail servers using the same information, without
the hassle and delay of having to copy it to each.
● Building Postfix with LDAP support

● Configuring LDAP lookups
● Example: aliases
● Example: virtual domains/addresses
● Other uses of LDAP lookups
● Notes and things to think about
● Feedback
● Credits
Building Postfix with LDAP support

Note 1: Postfix no longer supports the LDAP version 1 interface.
Note 2: to use LDAP with Debian GNU/Linux's Postfix, all you need is to install the postfix-
ldap package and you're done. There is no need to recompile Postfix.
You need to have LDAP libraries and include files installed somewhere on your system, and
you need to configure the Postfix Makefiles accordingly.
http://www.subneural.net/postfix-master/LDAP_README.html (1 of 6)01/16/2005 15:46:53

Postfix LDAP Howto
For example, to build the OpenLDAP libraries for use with Postfix (i.e. LDAP client code
only), you could use the following command:
% ./configure --without-kerberos --without-cyrus-

sasl --without-tls \
--without-threads --disable-slapd --disable-
slurpd \
--disable-debug --disable-shared
If you're using the libraries from the UM distribution (http://www.umich.edu/~dirsvcs/ldap/

ldap.html) or OpenLDAP (http://www.openldap.org), something like this in the top level of
your Postfix source tree should work:
% make tidy
% make makefiles CCARGS="-I/usr/local/include -
DHAS_LDAP" \
AUXLIBS="-L/usr/local/lib -lldap -L/usr/local/lib
-llber"
On Solaris 2.x you may have to specify run-time link information, otherwise ld.so will not find
some of the shared libraries:
% make tidy
% make makefiles CCARGS="-I/usr/local/include -
DHAS_LDAP" \
AUXLIBS="-L/usr/local/lib -R/usr/local/lib -lldap
\
-L/usr/local/lib -R/usr/local/lib -llber"
The 'make tidy' command is needed only if you have previously built Postfix without LDAP
support.
Instead of '/usr/local' specify the actual locations of your LDAP include files and libraries. Be
sure to not mix LDAP include files and LDAP libraries of different versions!!
If your LDAP libraries were built with Kerberos support, you'll also need to include your
Kerberos libraries in this line. Note that the KTH Kerberos IV libraries might conflict with
Postfix's lib/libdns.a, which defines dns_lookup. If that happens, you'll probably want to link
with LDAP libraries that lack Kerberos support just to build Postfix, as it doesn't support
Kerberos binds to the LDAP server anyway. Sorry about the bother.

Postfix LDAP Howto
If you're using one of the Netscape LDAP SDKs, you'll need to change the AUXLIBS line to
point to libldap10.so or libldapssl30.so or whatever you have, and you may need to use the
appropriate linker option (e.g. '-R') so the executables can find it at runtime.
Configuring LDAP lookups

In order to use LDAP lookups, define an LDAP source as a table lookup in main.cf, for
example:
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/

ldap-aliases.cf
The file /etc/postfix/ldap-aliases.cf can specify a great number of parameters, including

parameters that enable LDAP SSL and STARTTLS. For a complete description, see the
ldap_table(5) manual page.
Example: local(8) aliases

Here's a basic example for using LDAP to look up local(8) aliases. Assume that in main.cf, you
have:
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/

ldap-aliases.cf
and in ldap:/etc/postfix/ldap-aliases.cf you have:
server_host = ldap.my.com
search_base = dc=my, dc=com
Upon receiving mail for a local address "ldapuser" that isn't found in the /etc/aliases database,
Postfix will search the LDAP server listening at port 389 on ldap.my.com. It will bind
anonymously, search for any directory entries whose mailacceptinggeneralid attribute is
"ldapuser", read the "maildrop" attributes of those found, and build a list of their maildrops,
which will be treated as RFC822 addresses to which the message will be delivered.
Example: virtual domains/addresses

If you want to keep information for virtual lookups in your directory, it's only a little more
complicated. First, you need to make sure Postfix knows about the virtual domain. An easy

Postfix LDAP Howto
way to do that is to add the domain to the mailacceptinggeneralid attribute of some entry in the
directory. Next, you'll want to make sure all of your virtual recipient's mailacceptinggeneralid
attributes are fully qualified with their virtual domains. Finally, if you want to designate a
directory entry as the default user for a virtual domain, just give it an additional
mailacceptinggeneralid (or the equivalent in your directory) of "@virtual.dom". That's right, no
user part. If you don't want a catchall user, omit this step and mail to unknown users in the
domain will simply bounce.
In summary, you might have a catchall user for a virtual domain that looks like this:
dn: cn=defaultrecipient, dc=fake, dc=dom

objectclass: top
objectclass: virtualaccount
cn: defaultrecipient
owner: uid=root, dc=someserver, dc=isp, dc=dom
1 -> mailacceptinggeneralid: fake.dom
2 -> mailacceptinggeneralid: @fake.dom
3 -> maildrop: realuser@real.dom
1: Postfix knows fake.dom is a valid virtual domain when it looks for this and gets
something (the maildrop) back.
2: This causes any mail for unknown users in fake.dom to go to this entry ...
3: ... and then to its maildrop.
Normal users might simply have one mailacceptinggeneralid and maildrop, e.g.
"normaluser@fake.dom" and "normaluser@real.dom".
Other uses of LDAP lookups

Other common uses for LDAP lookups include rewriting senders and recipients with Postfix's
canonical lookups, for example in order to make mail leaving your site appear to be coming
from "First.Last@site.dom" instead of "userid@site.dom".
Notes and things to think about

● The bits of schema and attribute names used in this document are just examples. There's
nothing special about them, other than that some are the defaults in the LDAP
configuration parameters. You can use whatever schema you like, and configure Postfix

Postfix LDAP Howto
accordingly.
● You probably want to make sure that mailacceptinggeneralids are unique, and that not
just anyone can specify theirs as postmaster or root, say.
● An entry can have an arbitrary number of mailacceptinggeneralids or maildrops.

Maildrops can also be comma-separated lists of addresses. They will all be found and
returned by the lookups. For example, you could define an entry intended for use as a
mailing list that looks like this (Warning! Schema made up just for this example):
dn: cn=Accounting Staff List, dc=my, dc=com

cn: Accounting Staff List
o: my.com
objectclass: maillist
mailacceptinggeneralid: accountingstaff
mailacceptinggeneralid: accounting-staff
maildrop: mylist-owner
maildrop: an-accountant
maildrop: some-other-accountant
maildrop: this, that, theother
● If you use an LDAP map for lookups other than aliases, you may have to make sure the
lookup makes sense. In the case of virtual lookups, maildrops other than mail addresses
are pretty useless, because Postfix can't know how to set the ownership for program or
file delivery. Your query_filter should probably look something like this:
query_filter = (&(mailacceptinggeneralid=%s)(!(|
(maildrop="*|*")(maildrop="*:*")(maildrop="*/
*"))))
● And for that matter, even for aliases, you may not want users able to specify their
maildrops as programs, includes, etc. This might be particularly pertinent on a "sealed"
server where they don't have local UNIX accounts, but exist only in LDAP and Cyrus.
You might allow the fun stuff only for directory entries owned by an administrative
account, so that if the object had a program as its maildrop and weren't owned by
"cn=root" it wouldn't be returned as a valid local user. This will require some thought on
your part to implement safely, considering the ramifications of this type of delivery.
You may decide it's not worth the bother to allow any of that nonsense in LDAP
lookups, ban it in the query_filter, and keep things like majordomo lists in local alias
databases.
query_filter = (&(mailacceptinggeneralid=%s)(!(|

Postfix LDAP Howto
(maildrop="*|*")(maildrop="*:*")(maildrop="*/*"))
(owner=cn=root, dc=your, dc=com)))
● LDAP lookups are slower than local DB or DBM lookups. For most sites they won't be
a bottleneck, but it's a good idea to know how to tune your directory service.
● Multiple LDAP maps share the same LDAP connection if they differ only in their query
related parameters: base, scope, query_filter, and so on. To take advantage of this, avoid
spurious differences in the definitions of LDAP maps: host selection order, version,
bind, tls parameters, ... should be the same for multiple maps whenever possible.
Feedback
If you have questions, send them to postfix-users@postfix.org. Please include relevant
information about your Postfix setup: LDAP-related output from postconf, which LDAP
libraries you built with, and which directory server you're using. If your question involves your
directory contents, please include the applicable bits of some directory entries.
Credits
● Manuel Guesdon: Spotted a bug with the timeout attribute.
● John Hensley: Multiple LDAP sources with more configurable attributes.
● Carsten Hoeger: Search scope handling.
● LaMont Jones: Domain restriction, URL and DN searches, multiple result attributes.
● Mike Mattice: Alias dereferencing control.
● Hery Rakotoarisoa: Patches for LDAPv3 updating.
● Prabhat K Singh: Wrote the initial Postfix LDAP lookups and connection caching.
● Keith Stevenson: RFC 2254 escaping in queries.
● Samuel Tardieu: Noticed that searches could include wildcards, prompting the work on
RFC 2254 escaping in queries. Spotted a bug in binding.
● Sami Haahtinen: Referral chasing and v3 support.
● Victor Duchovni: ldap_bind() timeout. With fixes from LaMont Jones: OpenLDAP
cache deprecation. Limits on recursion, expansion and query results size. LDAP
connection sharing for maps differing only in the query parameters.
● Liviu Daia: Support for SSL/STARTTLS. Support for storing map definitions in
external files (ldap:/path/ldap.cf) needed to securely store passwords for plain auth.
And of course Wietse.

Postfix CDB Howto
Postfix CDB Howto
Introduction
CDB (Constant DataBase) is an indexed file format designed by Daniel Bernstein. CDB is
optimized exclusively for read access and guarantees that each record will be read in at most
two disk accesses. This is achieved by forgoing support for incremental updates: no single-
record inserts or deletes are supported. CDB databases can be modified only by rebuilding
them completely from scratch, hence the "constant" qualifier in the name.
Postfix CDB databases are specified as "cdb:name", where name specifies the CDB file name
without the ".cdb" suffix (another suffix, ".tmp", is used temporarily while a CDB file is under
construction). CDB databases are maintained with the postmap(1) or postalias(1) command.
The DATABASE_README document has general information about Postfix databases.
CDB support is available with Postfix 2.2 and later releases. This document describes how to
build Postfix with CDB support.
Building Postfix with CDB

Postfix is compatible with two CDB implementations:
● The original cdb library from Daniel Bernstein, available from http://cr.yp.to/cdb.html,
and
● tinycdb (version 0.5 and later) from Michael Tokarev, available from http://www.corpit.
ru/mjt/tinycdb.html.
Tinycdb is preferred, since it is a bit faster, has additional useful functionality and is much
simpler to use.
http://www.subneural.net/postfix-master/CDB_README.html (1 of 2)01/16/2005 15:46:54

Postfix CDB Howto
To build Postfix after you have installed CDB, use something like:
% make tidy
% CDB=../../../tinycdb-0.5
% make -f Makefile.init makefiles "CCARGS=-DHAS_CDB -I
$CDB" \
"AUXLIBS=$CDB/libcdb.a"
% make
for tinycdb, or alternatively, for the D.J.B. version:
% make tidy
% CDB=../../../cdb-0.75
% make -f Makefile.init makefiles "CCARGS=-DHAS_CDB -I
$CDB" \
"AUXLIBS=$CDB/cdb.a $CDB/alloc.a $CDB/buffer.a
$CDB/unix.a $CDB/byte.a"
% make
After postfix has been built with cdb support, you can use "cdb" tables wherever you can use
read-only "hash", "btree" or "dbm" tables. However, the "postmap -i" (incremental record
insertion) and "postmap -d" (incremental record deletion) command-line options are not
available. For the same reason the "cdb" map type cannot be used to store the volatile address
verification cache for the verify(8) service.
http://www.subneural.net/postfix-master/CDB_README.html (2 of 2)01/16/2005 15:46:54

Postfix Queue Scheduler
What this file is about

This is the beginning of documentation for the clever queue manager scheduling algorithm by
Patrik Rak. For a long time, this code was made available under the name "nqmgr(8)" (new
queue manager), as an optional module. As of Postfix 2.1 this is the default queue manager,
which is always called "qmgr(8)". The old queue manager will for some time will be available
under the name of "oqmgr(8)".
Why the old Postfix queue manager was replaced

The old Postfix scheduler had several limitations due to unfortunate choices in its design.
1. Round-robin selection by destination for mail that is delivered via the same message
delivery transport. The round-robin strategy was chosen with the intention to prevent a
single (destination) site from using up too many mail delivery resources. However, that
strategy penalized inbound mail on bi-directional gateways. The poor suffering inbound
destination would be selected only 1/number-of-destinations of the time, even when it
had more mail than other destinations, and thus mail could be delayed.
Victor Duchovni found a workaround: use different message delivery transports, and
thus avoid the starvation problem. The Patrik Rak scheduler solves this problem by
using FIFO selection.
2. A second limitation of the old Postfix scheduler was that delivery of bulk mail would
block all other deliveries, causing large delays. Patrik Rak's scheduler allows mail with
fewer recipients to slip past bulk mail in an elegant manner.
How the queue manager scheduler works
http://www.subneural.net/postfix-master/SCHEDULER_README.html (1 of 3)01/16/2005 15:46:56

The following text is from Patrik Rak and should be read together with the postconf(5) manual
that describes each configuration parameter in detail.
From user's point of view, oqmgr(8) and qmgr(8) are both the same, except for how next
message is chosen when delivery agent becomes available. You already know that oqmgr(8)
uses round-robin by destination while qmgr(8) uses simple FIFO, except for some preemptive
magic. The postconf(5) manual documents all the knobs the user can use to control this
preemptive magic - there is nothing else to the preemption than the quite simple conditions
described below.
As for programmer-level documentation, this will have to be extracted from all those emails we
have exchanged with Wietse [rats! I hoped that Patrik would do the work for me -- Wietse] But
I think there are no missing bits which we have not mentioned in our conversations.
However, even from programmer's point of view, there is nothing more to add to the message
scheduling idea itself. There are few things which make it look more complicated than it is, but
the algorithm is the same as the user perceives it. The summary of the differences of the
programmer's view from the user's view are:
1. Simplification of terms for users: The user knows about messages and recipients. The
program itself works with jobs (one message is split among several jobs, one per each
transport needed to deliver the message) and queue entries (each entry may group
several recipients for same destination). Then there is the peer structure introduced by
qmgr(8) which is simply per-job analog of the queue structure.
2. Dealing with concurrency limits: The actual implementation is complicated by the fact
that the messages (resp. jobs) may not be delivered in the exactly scheduled order
because of the concurrency limits. It is necessary to skip some "blocker" jobs when the
concurrency limit is reached and get back to them again when the limit permits.
3. Dealing with resource limits: The actual implementation is complicated by the fact that
not all recipients may be read in-core. Therefore each message has some recipients in-
core and some may remain on-file. This means that a) the preemptive algorithm needs
to work with recipient count estimates instead of exact counts, b) there is extra code
which needs to manipulate the per-transport pool of recipients which may be read in-
core at the same time, and c) there is extra code which needs to be able to read
recipients into core in batches and which is triggered at appropriate moments.
4. Doing things efficiently: All important things I am aware of are done in the minimum
time possible (either directly or at least when amortized complexity is used), but to
choose which job is the best candidate for preempting the current job requires linear

search of up to all transport jobs (the worst theoretical case - the reality is much better).
As this is done every time the next queue entry to be delivered is about to be chosen, it
seemed reasonable to add cache which minimizes the overhead. Maintenance of this
candidate cache slightly obfuscates things.
The points 2 and 3 are those which made the implementation (look) complicated and were the
real coding work, but I believe that to understand the scheduling algorithm itself (which was
the real thinking work) is fairly easy.

Postfix Cyrus Howto
Postfix Cyrus Howto
http://www.subneural.net/postfix-master/CYRUS_README.html01/16/2005 15:47:00
Postfix Berkeley DB Howto
Introduction
Postfix uses databases of various kinds to store and look up information. Postfix databases are
specified as "type:name". Berkeley DB implements the Postfix database type "hash" and
"btree". The name of a Postfix Berkeley DB database is the name of the database file without
the ".db" suffix. Berkeley DB databases are maintained with the postmap(1) command.
Note: Berkeley DB version 4 is not supported by Postfix versions before 2.0.
This document describes:
1. How to build Postfix on systems without Berkeley DB library.
2. How to build Postfix on BSD or Linux systems with multiple Berkeley DB versions.
3. How to tweak performance.
4. Missing pthread library trouble.
Building Postfix on systems without Berkeley DB

Many commercial UNIXes ship without Berkeley DB support. Examples are Solaris, HP-UX,
IRIX, UNIXWARE. In order to build Postfix with Berkeley DB support you need to download
and install the source code from http://www.sleepycat.com/
Warning: some Linux system libraries use Berkeley DB, as do some third-party libraries such
as SASL. If you compile Postfix with a different Berkeley DB implementation, then every
Postfix program will dump core because either the system library, SASL library, or Postfix
itself ends up using the wrong version.
http://www.subneural.net/postfix-master/DB_README.html (1 of 4)01/16/2005 15:47:05

The more recent Berkeley DB versions have a compile-time switch, "--with-uniquename",

which renames the symbols so that multiple versions of Berkeley DB can co-exist in the same
application. Although wasteful, this may be the only way to keep things from falling apart.
To build Postfix after you installed the Berkeley DB from http://www.sleepycat.com/, use
something like:
% make tidy
% make makefiles CCARGS="-DHAS_DB -I/usr/local/
BerkeleyDB.3.1/include" \
AUXLIBS="-L/usr/local/BerkeleyDB.3.1/lib -ldb"
% make
The exact pathnames depend on the DB version that you installed. For example, Berkeley DB
version 2 installs in /usr/local/BerkeleyDB.
Warning: the file format produced by Berkeley DB version 1 is not compatible with that of
versions 2 and 3 (versions 2 and 3 have the same format). If you switch between DB versions,
then you may have to rebuild all your Postfix DB files.
Warning: if you use Berkeley DB version 2 or later, do not enable DB 1.85 compatibility
mode. Doing so would break fcntl file locking.
Warning: if you use Perl to manipulate Postfix's Berkeley DB files, then you need to use the
same Berkeley DB version in Perl as in Postfix.
Building Postfix on BSD systems with multiple Berkeley

DB versions
Some BSD systems ship with multiple Berkeley DB implementations. Normally, Postfix builds
with the default DB version that ships with the system.
To build Postfix on BSD systems with a specific DB version, use a variant of the following
commands:
% make tidy
% make makefiles CCARGS=-I/usr/include/db3 AUXLIBS=-
ldb3
% make

Building Postfix on Linux systems with multiple Berkeley

DB versions
Some Linux systems ship with multiple Berkeley DB implementations. Normally, Postfix
builds with the default DB version that ships with the system.
Warning: some Linux system libraries use Berkeley DB. If you compile Postfix with a non-
default Berkeley DB implementation, then every Postfix program will dump core because
either the system library or Postfix itself ends up using the wrong version.
On Linux, you need to edit the makedefs script in order to specify a non-default DB library.
The reason is that the location of the default db.h include file changes randomly between
vendors and between versions, so that Postfix has to choose the file for you.
Tweaking performance
Postfix provides two configuration parameters that control how much buffering memory
Berkeley DB will use.

● berkeley_db_create_buffer_size (default: 16 MBytes per table). This setting is used by

the commands that maintain Berkeley DB files: postalias(1) and postmap(1). For "hash"
files, create performance degrades rapidly unless the memory pool is O(file size). For
"btree" files, create performance is good with sorted input even for small memory pools,
but with random input degrades rapidly unless the memory pool is O(file size).
● berkeley_db_read_buffer_size (default: 128 kBytes per table). This setting is used by all
other Postfix programs. The buffer size is adequate for reading. If the cache is smaller
than the table, random read performance is hardly cache size dependent, except with
btree tables, where the cache size must be large enough to contain the entire path from
the root node. Empirical evidence shows that 64 kBytes may be sufficient. We double
the size to play safe, and to anticipate changes in implementation and bloat.
Missing pthread library trouble

When building Postfix fails with:
undefined reference to `pthread_condattr_setpshared'

undefined reference to `pthread_mutexattr_destroy'
undefined reference to `pthread_mutexattr_init'
undefined reference to `pthread_mutex_trylock'
Add the "-lpthread" library to the "make makefiles" command.
% make makefiles .... AUXLIBS="... -lpthread"
More information is available at http://www.sleepycat.com/.

Postfix PCRE Support
PCRE (Perl Compatible Regular Expressions) map

support
The optional "pcre" map type allows you to specify regular expressions with the PERL style
notation such as \s for space and \S for non-space. The main benefit, however, is that pcre
lookups are often faster than regexp lookups. This is because the pcre implementation is often
more efficient than the POSIX regular expression implementation that you find on many
systems.
A description of how to use pcre tables, including examples, is given in the pcre_table(5)
manual page. Information about PCRE itself can be found at http://www.pcre.org/.
Building Postfix with PCRE support

Note: to use pcre with Debian GNU/Linux's Postfix, all you need is to install the postfix-pcre
package and you're done. There is no need to recompile Postfix.
In some future, Postfix will have a plug-in interface for adding map types. Until then, you need
to compile PCRE support into Postfix.
First of all, you need the PCRE library (Perl Compatible Regular Expressions), which can be
obtained from:
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/.
NOTE: pcre versions prior to 2.06 cannot be used.
In order to build Postfix with PCRE support you need to add -DHAS_PCRE and a -I for the
PCRE include file to CCARGS, and add the path to the PCRE library to AUXLIBS, for
http://www.subneural.net/postfix-master/PCRE_README.html (1 of 2)01/16/2005 15:47:05

example:

"CCARGS=-DHAS_PCRE -I/usr/local/include" \
"AUXLIBS=-L/usr/local/lib -lpcre"
Solaris may need run-time path information:

"CCARGS=-DHAS_PCRE -I/usr/local/include" \
"AUXLIBS=-L/usr/local/lib -R/usr/local/lib -lpcre"
Things to know
● When Postfix searches a pcre: or regexp: lookup table, each pattern is applied to the
entire input string. Depending on the application, that string is an entire client hostname,
an entire client IP address, or an entire mail address. Thus, no parent domain or parent
network search is done, "user@domain" mail addresses are not broken up into their user
and domain constituent parts, and "user+foo" is not broken up into user and foo.
● Regular expression tables such as pcre: or regexp: are not allowed to do $number
substitution in lookup results that can be security sensitive: currently, that restriction
applies to the local aliases(5) database or the virtual(8) delivery agent tables.
http://www.subneural.net/postfix-master/PCRE_README.html (2 of 2)01/16/2005 15:47:05

Guidelines for Package Builders
Guidelines for Package

Builders

This document has hints and tips for those who manage their own Postfix distribution for
internal use, and for those who maintain Postfix distributions for general use.
General distributions: please provide a small default main.

cf file
The installed main.cf file must be small. PLEASE resist the temptation to list all 300+
parameters in the main.cf file. Postfix is supposed to be easy to configure. Listing all 300+ in
main.cf defeats the purpose. It is an invitation for hobbyists to make random changes without
understanding what they do, and gets them into endless trouble.
General distributions: please include README or HTML

files
Please provide the applicable README or HTML files. They are referenced by the Postfix
manual pages and by other files. Without README or HTML files, Postfix will be difficult if
not impossible to configure.
Postfix Installation parameters

Postfix installation is controlled by a dozen installation parameters. See the postfix-install and
post-install files for details. Most parameters have system-dependent default settings that are
configurable at compile time, as described in the INSTALL file.
http://www.subneural.net/postfix-master/PACKAGE_README.html (1 of 3)01/16/2005 15:47:06

Preparing a pre-built package for distribution to other

systems
You can build a Postfix package on a machine that does not have Postfix installed on it. All
you need is Postfix source code and a compilation environment that is compatible with the
target system.
You can build a pre-built Postfix package as an unprivileged user.
First compile Postfix. After successful compilation, execute:
% sh postfix-install
You will be prompted for installation parameters. Specify an install_root directory other than /.
The mail_owner and setgid_group installation parameter settings will be recorded in the main.
cf file, but they won't take effect until the package is unpacked and installed on the destination
machine.
If you want to fully automate this process, specify all the non-default installation parameters on
the command line:
% sh postfix-install -non-interactive
install_root=/some/where ...
Begin Security Alert

When building an archive for distribution, be sure to archive only files and symbolic
links, not their parent directories. Otherwise, unpacking a pre-built Postfix package may
mess up permission and/or ownership of system directories such as / /etc /usr /usr/bin /
var /var/spool and so on. This is especially an issue if you executed postfix-install (see
above) as an unprivileged user.
End Security Alert

Thus, to tar up the pre-built package, take the following steps:
% cd INSTALL_ROOT
% rm -f SOMEWHERE/outputfile
% find . \! -type d -print | xargs tar cf SOMEWHERE/

outputfile
% gzip SOMEWHERE/outputfile
This way you will not include any directories that might cause trouble upon extraction.
Installing a pre-built Postfix package

● To unpack a pre-built Postfix package, execute the equivalent of:
# umask 022
# gzip -d <outputfile.tar.gz | (cd / ; tar xvpf -)
The umask command is necessary for getting the correct permissions on non-Postfix
directories that need to be created in the process.
● Create the necessary mail_owner account and setgid_group group for exclusive use by
Postfix.
● Execute the postfix command to set ownership and permission of Postfix files and
directories, and to update Postfix configuration files. If necessary, specify any non-
default settings for mail_owner or setgid_group on the postfix command line:
# postfix set-permissions upgrade-configuration \

setgid_group=xxx mail_owner=yyy
With Postfix versions before 2.1 you achieve the same result by invoking the post-
install script directly.

Postfix IPv6 Support
Introduction
Postfix 2.2 introduces support for the IPv6 (IP version 6) protocol, whose main feature of
interest is that it uses 128-bit IP addresses instead of the 32-bit addresses used by IPv4.
With this, Postfix can use the same SMTP protocol over IPv6 as it already uses over the older
IPv4 network, and Postfix can do AAAA record lookups in the DNS in addition to the older A
records. Information about IPv6 can be found at http://www.ipv6.org/.
● Supported platforms
● Configuration
● Known limitations
● Credits
Supported Platforms
Postfix version 2.2 supports IPv4 and IPv6 on the following platforms:
● AIX 5.1+
● Darwin 7.3+
● FreeBSD 4+
● Linux 2.4+
● NetBSD 1.5+
● OpenBSD 2+
● Solaris 8+
● Tru64Unix V5.1+
http://www.subneural.net/postfix-master/IPV6_README.html (1 of 5)01/16/2005 15:47:10

On other platforms Postfix will simply use IPv4 as it has always done.
Configuration
Postfix IPv6 support introduces two new main.cf configuration parameters, and introduces an
important change in address syntax notation in match lists such as mynetworks or
debug_peer_list.
Postfix IPv6 address syntax is a little tricky, because there are a few places where you must
enclose IPv6 address inside [] characters, and a few places where you must not. It is a good
idea to use [] only in the few places where you have to. Check out the postconf(5) manual
whenever you do IPv6 related configuration work with Postfix.
● The new inet_protocols parameter specifies what IP protocols Postfix will use. This
parameter also controls what DNS lookups Postfix will do.
# You must stop/start Postfix after changing
this parameter.
inet_protocols = ipv4 (DEFAULT: enable
IPv4 only)
inet_protocols = all (enable both IPv4
and IPv6)
inet_protocols = ipv4, ipv6 (enable both IPv4
and IPv6)
inet_protocols = ipv6 (enable IPv6 only)
By default, Postfix uses IPv4 only, because most systems aren't attached to an IPv6
network.
❍ On systems with combined IPv4/IPv6 stacks, attempts to deliver mail via IPv6
would always fail with "network unreachable", and those attempts would only
slow down Postfix.
❍ Linux kernels don't even load IPv6 protocol support by default. Any attempt to
use it would fail immediately.
Note 1: you must stop and start Postfix after changing the inet_protocols configuration
parameter.

Note 2: if you see error messages like the following, then you're running Linux and need
to turn on IPv6 in the kernel: see http://www.ipv6.org/ for hints and tips. Unlike other
systems, Linux does not have a combined stack for IPv4 and IPv6, and IPv6 protocol
support is not loaded by default.
postconf: warning: inet_protocols: IPv6 support

is disabled: Address family not supported by
protocol
postconf: warning: inet_protocols: configuring
for IPv4 support only
Note 3: on older Linux and Solaris systems, the setting "inet_protocols = ipv6" will not
prevent Postfix from accepting IPv4 connections. Postfix will present the client IP
addresses in IPv6 format, though. In all other cases, Postfix always presents IPv4 client
IP addresses in the traditional dotted quad IPv4 format.
● The other new parameter is smtp_bind_address6. This sets the local interface address
for outgoing IPv6 SMTP connections, just like the smtp_bind_address parameter does
for IPv4:
smtp_bind_address6 = 2001:240:5c7:0:250:56ff:
fe89:1
● If you left the value of the mynetworks parameter at its default (i.e. no mynetworks
setting in main.cf) Postfix will figure out by itself what its network addresses are. This
is what a typical setting looks like:
% postconf mynetworks
mynetworks = 127.0.0.0/8 168.100.189.0/28
[::1]/128 [fe80::]/10 [2001:240:5c7::]/64
If you did specify the mynetworks parameter value in main.cf, you need update the
mynetworks value to include the IPv6 networks the system is in. Be sure to specify IPv6
address information inside [], like this:
mynetworks = ...IPv4 networks... [::1]/128
[2001:240:5c7::]/64 ...

NOTE: when configuring Postfix match lists such as mynetworks or debug_peer_list, you
must specify IPv6 address information inside [] in the main.cf parameter value and in
files specified with a "/file/name" pattern. IPv6 addresses contain the ":" character, and
would otherwise be confused with a "type:table" pattern.
Known Limitations
● The order of IPv6/IPv4 outgoing connection attempts is not yet configurable. Currently,
IPv6 is tried before IPv4.
● Postfix currently does not support DNSBL (real-time blackhole list) lookups for IPv6
client IP addresses; currently there are no blacklists that cover the IPv6 address space.
● IPv6 does not have class A, B, C, etc. networks. With IPv6 networks, the setting
"mynetworks_style = class" has the same effect as the setting "mynetworks_style =
subnet".
● On Tru64Unix, Postfix can't figure out the local subnet mask and always assumes a /128
network. This is a problem only with "mynetworks_style = subnet" and no explicit
mynetworks setting in main.cf.
Credits
The following information is in part based on information that was compiled by Dean Strik.
● Mark Huizer wrote the original Postfix IPv6 patch.
● Jun-ichiro 'itojun' Hagino of the KAME project made substantial improvements. Since
then, we speak of the KAME patch.
● The PLD Linux Distribution ported the code to other stacks (notably USAGI). We
speak of the PLD patch. A very important feature of the PLD patch was that it can work
with Lutz Jaenicke's TLS patch for Postfix.
● Dean Strik extended IPv6 support to platforms other than KAME and USAGI, updated
the patch to keep up with Postfix development, and provided a combined IPv6 + TLS
patch. Information about his effort can be found on Dean Strik's Postfix website at http://
www.ipnet6.org/postfix/.

● Wietse Venema took Dean Strik's IPv6 patch, merged it into Postfix 2.2, and took the
opportunity to eliminate all IPv4-specific code from Postfix that could be removed. For
systems without IPv6 support in the kernel and system libraries, Postfix has a simple
compatibility layer, so that it will use IPv4 as before.

Postfix and Linux
Postfix and Linux
Berkeley DB issues
On RedHat Linux 7.0 you must install the db3-devel RPM before you can compile the Postfix
source code.
Warning: do not use multiple Berkeley DB versions. Every Postfix program will dump core
when it is built with a different Berkeley DB version than the version that is used by the system
library routines. See the DB_README file for further information.
Procmail issues
On RedHat Linux 7.1 procmail no longer has permission to write the mail spool directory.
Workaround: chmod 1777 /var/spool/mail.
Syslogd performance
LINUX syslogd uses synchronous writes by default. Because of this, syslogd can actually use
more system resources than Postfix. To avoid such badness, disable synchronous mail logfile
writes by editing /etc/syslog.conf and by prepending a - to the logfile name:
/etc/syslog.conf:
mail.* -/var/log/mail.log
Send a "kill -HUP" to the syslogd to make the change effective.
http://www.subneural.net/postfix-master/LINUX_README.html01/16/2005 15:47:10
Postfix and NFS
Postfix and NFS
This question was asked on the postfix-users mailing list a while ago:
Also, what considerations are there for file locking or other potential problems
when running Postfix with a Netapp-style box for /var/mail delivery? I know that
FreeBSD has broken NFS file locking (both client and server?) but I'm not sure
if this is something Postfix can work around or not.
Postfix jumps several hoops in order to deal with NFS-specific problems. Thus, Postfix on NFS
is slightly less reliable than Postfix on a local disk. That is not a problem in Postfix; the
problem is in NFS and affects other MTAs as well.
For queue locking within Postfix, NFS is not an issue because you cannot share Postfix queues
among multiple Postfix instances.
In order to have mailbox locking over NFS, you have to configure everything to use fcntl()
locks for mailbox access (or switch to maildir style, which needs no application-level lock
controls).
To turn on fcntl() mailbox locks with Postfix you specify:
virtual_mailbox_lock = fcntl
mailbox_delivery_lock = fcntl
Obviously, this approach is useful only if all other mailbox access software also uses fcntl()
locks.
You can also "play safe" and throw in username.lock files:
http://www.subneural.net/postfix-master/NFS_README.html (1 of 2)01/16/2005 15:47:11

Postfix and NFS
virtual_mailbox_lock = fcntl, dotlock

mailbox_delivery_lock = fcntl, dotlock
This is the combination that many applications end up using.
http://www.subneural.net/postfix-master/NFS_README.html (2 of 2)01/16/2005 15:47:11

Postfix and Ultrix
Postfix and Ultrix
Postfix on Ultrix
This document is probably only of historical value, because Ultrix version 4 dates from the
early 1990s. However, as long as Wietse keeps Postfix alive for SunOS 4, it is likely to run on
Ultrix 4 with very little change. Feedback is welcome if anyone actually still uses Postfix on
any version of Ultrix.
The source of this document is an email message by Christian von Roques that was sent on Jun
2, 1999.
I've upgraded the MTA of our DECstation-3100 running Ultrix4.3a to postfix-

19990317-pl05 and am sending you the patches I needed to get it running under
Ultrix.
...
One of the bugs of Ultrix's /bin/sh is that shell-variables set in arguments of `:'
expand to garbage if expanded in here-documents. Using a different shell helps. I
needed to replace all calls of ``sh .../makedefs'' by ``$(SHELL) .../makedefs'' in
all the Makefile.in and am now able to use ``make SHELL=/bin/sh5'' or zsh.
...
Ultrix's FD_SET_SIZE is 4096, but getdtablesize() returns 64 by default, if not

increased when building a new kernel. getrlimit() doesn't know
RLIMIT_NOFILE. This makes event_init() always log the warning: `could
allocate space for only 64 open files'.
I just reduced the threshold from 256 to 64, but this is not good. The initial
problem still remains: How to disable this warning on Ultrix without making the
http://www.subneural.net/postfix-master/ULTRIX_README.html (1 of 2)01/16/2005 15:47:11

Postfix and Ultrix
source ugly?
To work around the first problem, all the Makefile.in files have been updated to use `
$(SHELL)' instead of `sh'. So you only need to supply a non-default shell in order to eliminate
Ultrix shell trouble.
To work around the latter, util/sys_defs.h was updated for Ultrix, with a default FD_SETSIZE
of 100. This should be sufficient for a workstation. Even in 1999, no-one would run a major
mail hub on Ultrix 4.
http://www.subneural.net/postfix-master/ULTRIX_README.html (2 of 2)01/16/2005 15:47:11

Postfix Manual Pages
Information for new Postfix users

New Postfix users should first look at the following introductory documents. These
introductions are hyperlinked to more advanced documents and to UNIX-style manual pages.
The UNIX-style manual pages are intended for people who are already familiar with Postfix.
● Postfix architecture overview

● Basic configuration
● Trouble shooting
● Content inspection overview
● Relay/access control overview
● Lookup table overview
Postfix manual page organization

Each Postfix manual page is numbered after a section of the UNIX manual: examples are mailq
(1) or access(5). Unfortunately, there is no single universal method to organize manual pages;
each UNIX flavor appears to be different. Postfix documentation assumes the following
convention:
Section Topic
1 Commands
Library
3
routines
5 File formats
8 Daemons
Commands
http://www.subneural.net/postfix-master/postfix-manuals.html (1 of 3)01/16/2005 15:47:12

● postalias(1), create/update/query alias database

● postcat(1), examine Postfix queue file
● postkick(1), trigger Postfix daemon
● postlock(1), Postfix-compatible locking
● postlog(1), Postfix-compatible logging
● postmap(1), Postfix lookup table manager
● postqueue(1), Postfix mail queue control
● postsuper(1), Postfix housekeeping
● sendmail(1), Sendmail compatibility interface
Postfix configuration
● master(5), Postfix master.cf file syntax
● postconf(5), Postfix main.cf file syntax
Table-driven mechanisms
● access(5), Postfix SMTP access control table
● aliases(5), Postfix alias database
● header_checks(5), body_checks(5), content inspection
● canonical(5), Postfix address rewriting
● relocated(5), Users that have moved
● transport(5), Postfix routing table
● virtual(5), Postfix virtual aliasing
Table lookup mechanisms

● cidr_table(5), Associate CIDR pattern with value
● ldap_table(5), Postfix LDAP client
● mysql_table(5), Postfix MYSQL client
● nisplus_table(5), Postfix NIS+ client
● pcre_table(5), Associate PCRE pattern with value
● pgsql_table(5), Postfix PostgreSQL client
● regexp_table(5), Associate POSIX regexp pattern with value
● tcp_table(5), Postfix client-server table lookup

Daemon processes
● anvil(8), Postfix connection/rate limiting
● bounce(8), defer(8), trace(8), Delivery status reports
● cleanup(8), canonicalize and enqueue message
● discard(8), Postfix discard delivery agent
● error(8), Postfix error delivery agent
● flush(8), Postfix fast ETRN service
● lmtp(8), Postfix LMTP client
● local(8), Postfix local delivery agent
● master(8), Postfix master daemon
● oqmgr(8), old Postfix queue manager
● pickup(8), Postfix local mail pickup
● pipe(8), deliver mail to non-Postfix command
● proxymap(8), Postfix lookup table proxy server
● qmgr(8), Postfix queue manager
● qmqpd(8), Postfix QMQP server
● scache(8), Postfix session cache manager
● showq(8), list Postfix mail queue
● smtp(8), Postfix SMTP client
● smtpd(8), Postfix SMTP server
● spawn(8), run non-Postfix server
● trivial-rewrite(8), Postfix address rewriting
● verify(8), Postfix address verification
● virtual(8), Postfix virtual delivery agent

Catching up with Wietse Venema, creator of Postfix and TCP Wrapper
Features 7/9/2004 16:40

Securing Linux,
Part 1: Catching up with Wietse Venema, creator of Postfix and TCP
Introduction Wrapper
Jul 23
Internet Extortion By Duane Dunston

Ring Smashed 7/9/2004 16:40
Jul 23
Wietse Venema is best known for the software TCP Wrapper, which is still widely
Linux Advisory
used today and is included with almost all unix systems. Wietse is also the author of
Watch - July 23rd the Postfix mail system and the co-author of the very cool suite of utilities called The
2004
Coroner's Toolkit or "TCT". He is currently working at the Thomas J. Watson
Jul 23
Research Center and he has gratiously agreed to allow us to catch up with him and
and see what he's been up to lately.
Wietse Venema is best known for the software TCP Wrapper, which is still widely used
today and is included with almost all unix systems. Wietse is also the author of the Postfix
mail system and the co-author of the very cool suite of utilities called The Coroner's Toolkit
Today's Term or "TCT". He is currently working at the Thomas J. Watson Research Center and he has
penetration: gratiously agreed to allow us to catch up with him and and see what he's been up to lately.
Successful,
repeatable, Linuxsecurity.com: Thanks for taking the time to interview with us. How you doing these
unauthorized days? The most we hear from you is when Postfix is updated, the mailing lists, or
access to a something like that. What are you up to?
protected system
resource. (See:
Wietse: I have been finishing things, so that I can start work on new projects. After a major
attack,
violation.) ... documentation rewrite for the Postfix mail system, I finished the manuscript for a book on
computer forensic analysis with Dan Farmer. When I finish something, I normally start
reading everything that I can lay my hands on and then inspiration comes.
Linuxsecurity.com: On your website you mentioned you go bike riding, weather

permitting, how's the weather been where you are this year?
Today's Tip
Wietse: It has been fairly typical here in southern New York state. We dig ourselves out
Monitoring Files
from the snow a few times in January and February. Once the snow is gone in March, we
with Special
spend quality time walking up a hill or riding a bike. Many several former railroads are/
Permissions:
were converted into trails, and riding them is fun. Unlike Europe, where I grew up, the
Monitoring system
roads in southern New York state are not really safe for riding a bicycle.
files is crucial in
maintaining host
integrity. Linuxsecurity.com: You have a suite of tools available on your website. Any new ones
coming out that address basic fundamental security practices that still aren't followed or are
you going to add any new functionality to your existing programs?
Wietse: Some tools such as TCP WRAPPER are complete, and adding more features does
http://www.subneural.net/postfix-master/linuxsecurity-200407.html (1 of 4)01/16/2005 15:47:15

not make them more useful. I would update them only so that they survive changes in
operating systems, language compilers and/or network protocols. Some tools such as
SATAN have served their purpose, and now have historical value only.
Linuxsecurity.com: Does the continued success of TCP Wrapper surprise you? If so, why
is that? What does TCP Wrapper have that makes it so valuable today.
Perhaps the biggest virtue is that tcp_wrappers works as expected. This means that not only
the software is relatively error free, it is also possible for human beings to install, configure,
and forget tcp_wrappers without getting into trouble.
It does not matter how well software is written when people can't figure out how to use it,
or when it has sharp edges that make it unsafe to use. Being safe and secure is hard enough
with software like tcp_wrappers that spans only a few thousand lines of code.
With a 10 times larger system such as Postfix, even relatively error-free software contains a
number of errors, and one has to build additional safety features into the architecture to
prevent accidents from happening. Just like elevators have safety brakes that prevent them
from crashing into the basement, Postfix has safety brakes that most people never notice
until they are needed.
Linuxsecurity.com: Postfix is a really good Mail Transport Agent (MTA), I've been using
it for a long time and I set it up for someone any chance I get. Why did you decide to write
a new MTA instead of scaling down an existing MTA? :-)
Wietse: Indeed, why would anyone spend so much time writing yet another UNIX-based
mail system, when Sendmail and qmail already existed? When I was looking for a
programming project, neither mail system was a desirable option for me, and enough
people felt the same way.
Writing a new mail system from scratch was a change from previous projects. Normally I
would retrofit security features almost invisibly, either by replacing an existing server such
as portmap by a hardened version that was 100% compatible, or by adding a very thin layer
such as tcp_wrappers. In the case of the Postfix mail system, there was no way that the
changes could be made in an invisible manner.
Linuxsecurity.com: What is your take on spam and the role the MTA plays in helping to
prevent it?
Wietse: Stopping email that contains spam is not fundamentally different from stopping
email that contains viruses.
In both cases, complex content analysis is better done outside the mail system. That allows
people to choose the best mail system and the best spam/virus software for their
environment.
And in both cases, a lot of spam or viral email comes from systems that have no business
sending email directly across the Internet. These are often PCs on residential networks that
have been compromised via some worm of virus, and that are under remote control by
criminals that use those systems to send spam and/or to infect more systems. These rogue
systems can often be recognized by the way they implement the email protocols wrongly, if
not by their residential IP address.
Blocking direct mail from rogue systems is best done by the ISP that hosts those systems,
but that happens rarely. The next best solution is to block direct mail from rogue systems at
the receiving end, and that is where Postfix can help.

Linuxsecurity.com: In one article, I wrote about how attackers are still breaking into
computer systems using well-known exploits. Any ideas on how to help instill basic
security practices in administrators and vendors?
Wietse: I think that learning by example is a good way to bring the point across. This is
what Dan Farmer and I attempted years ago with our white paper on improving the security
of your system by breaking into it.
I have the same experience when explaining how to build more secure software. People just
don't see that there is a problem until you can show good examples of software that does
not do the things that it obviously was meant to do. Security problems happen when there is
a mismatch between expected behavior and actual behavior.
Linuxsecurity.com: How did you get into the forensics side of computers?
Wietse: The initial motivation for getting involved with computer forensics was to
reconstruct computer break-ins, so that I could prevent them from happening again. An
amazing amount of information can be found after an incident. As computers become more
complex, humans have less control over when and where information is stored, and how
that storage is recycled when information is discarded.
Because of this it is practically impossible to erase all information about an incident from a
disk, without physically destroying the hardware. Erasing all memory is difficult too, if you
don't want to draw attention by crashing the system. How much reconstruction is possible
depends only on the amount of skill and effort you're willing to put in.
Linuxsecurity.com: You and Dan Farmer still work on The Coroner's Toolkit (TCT).
What research, seminars, or open source programs you working on in forensics?
Wietse: We just finished a manuscript for a book on computer forensic analysis that we
hope will come out this year. In this book we write about things that we learned after we
released the TCT. For some experiments we used the TCT, and for other measurements we
wrote a few new tools. When this book is published I will be happy to turn my attention to
other projects.
Linuxsecurity.com: We just wanted to catch up with you and see how things were going.
Can you please give us a final statement about keeping our systems secure?
Wietse: You don't make a system secure by patching the holes - if the system wasn't built
to be secure then it never will be.
Linuxsecurity.com: Wietse provided this quote:
"As long as there is support for ad hoc fixes and security packages for these inadequate
designs and as long as the illusory results of penetration teams are accepted as
demonstrations of computer system security, proper security will not be a reality."
Roger Schell et al., Preliminary notes on the Design of Secure Military Computer Systems,
1973. Archive of seminal security papers at http://seclab.cs.ucdavis.edu/projects/history/
seminal.html
Linuxsecurity.com: Okay one last thing, where were you and who drew that caricature on
your website?
Wietse: The caricature was drawn, by an artist whose name I do not know, at a conference
dinner in 1997 when the Forum of Incident Response and Security Teams (www.first.org)
met for its annual conference in Bristol, UK. I have supported this organization for many

years, and I even had the privilege of spending more than the maximal time as its chair.
Duane Dunston is an Information Technology Specialist (Security) for the National

Climatic Data Center. He was previously a contractor for STG Inc. for the same
organization. He received his B.A. and M.S. degrees from Pfeiffer University and he has
his GSEC certification from SANS. Hey, Ann Curry!
Contact Us | Legal Notice | About Our Site

© Guardian Digital, Inc., 2000

HEC Montréal: Deployment of a Large-Scale Mail Installation
http://www.subneural.net/postfix-master/linux-journal-20040501.html01/16/2005 15:47:15
HEC Montréal: Follow-up on the Large-Scale Mail Installation
http://www.subneural.net/postfix-master/linux-journal-20040413.html01/16/2005 15:47:16
Sharing Software, IBM to Release Mail Program Blueprint
December 14, 1998
Sharing Software, IBM to Release Mail

Program Blueprint
By JOHN MARKOFF
dding momentum to the open-source movement for the free

sharing of software, IBM plans Monday to make available
the original programmer's instructions for a new mail program that
can be used to store and forward e-mail messages with a high level
of security.
The program, Secure Mailer, serves as an electronic post office for

server computers connected to the Internet. It was developed by
Wietse Venema, an IBM researcher and computer security
specialist. Executives said they were using the free, open-source
model of software distribution to insure that the program would be
widely available on the dozens of kinds of computers that are used
to route Internet mail traffic.
The open source model of software development, pioneered by a

loosely affiliated group of expert programmers, is built on
universal sharing of the programmer's original written instructions
to the computer. In traditional, proprietary development models,
those instructions are hidden because they have been compiled
into the binary 1s and 0s that computers understand.
The open-source model has been gaining popularity in the last year
based on the success of the free Linux operating system, and in
recent months several major technology corporations have
endorsed part or all of the idea.
http://www.subneural.net/postfix-master/14blue.html (1 of 3)01/16/2005 15:47:17

"This is IBM's Christmas present to the Related Articles

Internet," said Abner Germanow, a Netscape to Release New
computer security analyst at the Browser Engine to
International Data Corp., a market Developers
research firm. "For these are core (Dec. 7, 1998)
pieces of software, and we're going
beyond trying to make money off of Sentiment Growing for
them, to the idea that by freely sharing Freeware
them it will make the world a better (April 13, 1998)
place."
Like many big companies, the

International Business Machines Corp. seems to be cautiously
feeling its way toward an open-source strategy. Secure Mailer
follows by just a week the company's release of the source code
for a compiler, the tool used by software developers to transform
instructions written in a programming language into the
computer's binary machine code.
In addition, IBM is making its software compatible with Apache, a

popular open-source Web server program, and earlier this year it
announced plans to make a version of its DB2 relational data base
program available for the open-source Linux operating system.
"We're still trying to understand exactly what open source means,"

said Paul Horn, vice president for research. "It obviously plays an
important role where standards are critical, but what it means to
IBM is still under formulation."
Secure Mailer offers an alternative to several other freely available

programs that route Internet mail, including Sendmail and Q Mail,
as well as to commercial programs like Microsoft's Exchange.
Currently about 70 percent of all e-mail worldwide is handled by

Sendmail, a program that has been developed over more than a
decade and supported by a programmer named Eric Allman and a
loose group of colleagues. Recently, Allman started a company to
develop a commercial version of the program.
IBM researchers said one of the drawbacks to Sendmail was that it

had been written as a large, monolithic piece of software. As a

result it has both performance and security limitations.
In contrast, Venema has developed Secure Mailer as a cluster of

modules, all of which distrust each other. This creates a more
secure program. The program could be compared to a ship that has
many independent compartments and therefore is harder to sink,
he said.
Charles Palmer, who manages a computer security research group

at IBM's T.J. Watson Research Laboratory, said that enabling
other programmers to look at all the original instructions written
by the program's author would give them a high degree of
confidence in the security of a program.
Related Sites
These sites are not part of The New York Times on the Web, and The
Times has no control over their content or availability.
● IBM
● Sendmail
Home | Site Index | Site Search | Forums | Archives | Marketplace
Quick News | Page One Plus | International | National/N.Y. | Business | Technology |

Science | Sports | Weather | Editorial | Op-Ed | Arts | Automobiles | Books | Diversions |
Job Market | Real Estate | Travel
Help/Feedback | Classifieds | Services | New York Today
Copyright 1998 The New York Times Company

The Standard: Behind the Big Blue Wall
June 3, 2001
NEWS & ANALYSIS
THE INDUSTRY STANDARD MAGAZINE
Headlines
Money & Markets Behind the Big Blue Wall
Tech & Telecom By Elinor Abreu
Issue Date: Jan 22 2001
Media & Marketing
Metrics & Stats How IBM learned to quit worrying and love open-source
Policy & Politics software.
Careers
Lifestyle
Opinion
Just over two years RELATED CONTENT
International
ago, Nick Donofrio, * Companies (4)
senior vice president
* Articles (9)
SEARCH for technology at
GO IBM (IBM), received * Topics (2)
advanced search a surprise phone call * Research (3)
from his boss, Louis * Insights (1)
SERVICES
Gerstner. The
Company Index Printer-friendly version
company's CEO had
Newsletters
just read a New York Email to a friend
Research Store Write the author:
Times article about * Elinor Abreu
Conferences
an IBM developer who had released an e-
Wireless
mail program called SecureMailer, Subscribe to The
My Account
written in open-source code - freely
Industry Standard
PRINT EDITION distributed software that could be
Read the Magazine modified by anyone. Though he didn't
phrase it this way, Gerstner was essentially calling to ask,
"What the hell's going on here?"
Gerstner wanted to know if SecureMailer would compete with

IBM's proprietary Lotus Notes. More broadly, he wondered how
the company should respond to the growing popularity of open-
The Industry source software.
Standard Magazine
Since that phone call, the open-source movement at IBM,
which had been a ripple within the organization, has become a
tidal wave. IBM has made Linux, the popular open-source
operating system, its choice for the Internet. Linux will run on
every computer model sold by Big Blue, from its wristwatch-
computer prototype to its mainframes. In December, Gerstner
announced plans to spend $1 billion in 2001 researching,
developing and marketing Linux-based products and services
worldwide.
"A lot of companies that embrace Linux view it as an operating

system," says Irving Wladawsky-Berger, an IBM vice president
who is the top Linux man in the company. "We viewed it as a
major game-changer in this whole world of technology."
By changing their game to embrace Linux, IBM execs hope to

avoid missing another paradigm shift - as they missed the PC
revolution and, to a lesser degree, the Internet. In the early
'80s, IBM developed one of the first personal computers but
was too focused on maintaining its mainframe business to see
the PC tsunami building. Years of financial losses, totaling $8
billion by 1993, resulted. The company also did pioneering work
on the Arpanet, the Internet's predecessor, but has watched its
networking business all but dry up. Gerstner isn't about to let
another big wave pass him by.
http://www.subneural.net/postfix-master/standard.200101/0_1902_21395-0_00.html (1 of 3)01/16/2005 15:47:19

"Only the greatest of sinners know how to repent," says John

Patrick, IBM's VP of Internet technology. "We've seen this kind
of radical shift before. With Linux, we're trying very hard to
anticipate the full impact."
But tying the company's fortunes to open-source systems

represents a powerful threat to IBM's Unix-based AIX operating
system, which was launched in February 1990 and represented
about $257 million in revenue for IBM in 1999, according to
IDC. The open-source push points to a deeper cultural shift
within Big Blue, reflecting changing attitudes about innovation,
software development and intellectual property.
Created by Finnish college student Linus Torvalds in 1991,

Linux is an open-source operating system; unlike Microsoft
(MSFT)'s Windows, its source code is available for anyone to
use and alter, as long as they in turn freely broadcast their
changes. Advocates say open-source software is more secure,
reliable and flexible than closed, proprietary programs. Long
popular among hard-core technologists, Linux is now the
fastest-growing server operating system in the world, IDC
reports.
Like the wider open-source movement, IBM's open-source

efforts began at the grass roots. For years, engineers in its
various divisions dabbled in open-source projects, known as
"skunk works," and communicated via an internal IBM e-mail
list. At the same time, an IBM programmer in Germany was
tinkering with Linux on mainframes. As early as 1995, IBM
Research worked with outside engineers to port Linux to the
company's PowerPC. Things started heating up in 1998, when
Gerstner noticed SecureMailer and when IBM released its
WebSphere application server based on the open-source
Apache Web server.
Page 1 | Page 2 | NEXT
MENTIONED COMPANIES
* Shell Oil Company (dossier)

* O'Reilly & Associates, Inc. (dossier)
* International Business Machines Corporation (IBM)
* Microsoft Corporation (MSFT)
RELATED ARTICLES
* Virus Alert ... Psych!

May 15, 2001
* Big Blue Joins Web Services Fray
May 14, 2001
* Sun, I2 to Collaborate on Software Offering
May 09, 2001
* Sun, Microsoft Servers Vulnerable to New Worm
May 08, 2001
* Napster Reportedly Wants Microsoft's Anti-Piracy Technology
May 04, 2001
* Microsoft Ups Ante in Game Wars
May 03, 2001
* Intershop's Ups and Downs
May 03, 2001

* As Napster Fades, Alternatives Come On Strong

May 02, 2001
* Computer Associates Defends Accounting Practices
April 30, 2001
RELATED TOPICS
* Money & Markets > Corporate Activity > Earnings Reports

* Tech & Telecom > Software
RELATED RESEARCH REPORTS
Available for purchase from the Research Store.

* Success Strategies In Online Content Markets
Published by ActivMedia Research
* Benchmarking's Value -Science or Sleight of Hand?
Published by Giga Information Group
* ZEUS Q3 ASP Report
Published by Zona Research
RELATED INSIGHTS
From our Marketing Partners.

* Microsoft Office XP
Provided by Microsoft
ADVERTISEMENT
FEATURED LINKS
Visit www.Office.com. The #1 online business resource center.
NextCard Visa APRs as low as 0.00% Intro! Click NOW to apply
Check out Microsoft Office XP at a Launch Event near you
Click Here To Shop Ralph Lauren's Polo.com
Save time and $$$. Enroll in Hertz' Business Account Program
Home | Customer Service | My Account | Subscribe | About Us | Media Kit

Australia | Brazil | China | Korea | Norway | Poland | Sweden | Switzerland | Taiwan
Copyright ©2001 Standard Media International. Privacy Policy

Stock data provided by Stockpoint and its data suppliers. Copyright © 1995-2001

June 3, 2001
NEWS & ANALYSIS
THE INDUSTRY STANDARD MAGAZINE
Headlines
Money & Markets Behind the Big Blue Wall
Tech & Telecom continued
Media & Marketing
Metrics & Stats "Suddenly, IBM was the cool company RELATED CONTENT
Policy & Politics on the block," says James Berry, then * Companies (4)
Careers the WebSphere product manager at IBM
* Articles (9)
Lifestyle and now vice president of strategy at
* Topics (2)
Opinion open-source consulting firm Collab.Net.
International "The dot-com phenomenon was running * Research (3)
on Linux and Apache, and guess what? * Insights (2)
SEARCH
IBM had a product that ran on Linux and
GO Apache. For the first time, we were the Printer-friendly version
advanced search lead dog rather than the rear dog." Email to a friend
SERVICES Write the author:
Company Index Meanwhile, in Böblingen, Germany, 28- * Elinor Abreu
Newsletters year-old Boas Betzler was working on
Research Store IBM's System 390 mainframe technology Subscribe to The
Conferences at the office and on Linux at home. One Industry Standard
Wireless day in 1998, he suggested to a
My Account colleague that it might be fun to have
Linux running on S/390. His managers liked the idea and so did
PRINT EDITION
executives in the U.S. They brought Betzler and his wife to
Read the Magazine
IBM's Poughkeepsie, N.Y., headquarters in mid-1999 to
complete his work.
By that time the open-source mind-set had penetrated to the

highest reaches of the organization. In late 1998 at a meeting
in Toronto, a group of Linux devotees within IBM had submitted
The Industry a so-called Earthquake Petition to IBM's Academy of
Technology, the company's brain trust of 280 top scientists.
Standard Magazine The petition described Linux as a groundbreaking technological
opportunity too important to miss. "We said Linux was an
important phenomenon and we had to get started," says Dan
Frye, director of IBM's Linux Technology Center.
The Academy concurred. In January 1999, Frye and several

colleagues met in Research Triangle Park, N.C., with open-
source experts Tim O'Reilly, president of O'Reilly &
Associates (dossier), and Richard Stallman, founder of the
Free Software Foundation.
The visitors quickly realized that IBM was not the staid Big Blue
of old. "I remember being amazed to discover that the person
hosting me didn't wear a suit and tie," recalls Stallman.
The changes, in a sense, take IBM back to its roots. "For IBM,
open source is a return to an industry they understand better,"
says O'Reilly. "Some of [IBM's] operating systems were
originally user-developed. So in a way, this is a real
comfortable arena for them."
IBM is hoping to combine the flexibility and low cost of open-

source software with its strengths in hardware and services. It
can offer its Global Services customers, for example, a cheaper
alternative to licensed software - which should mean more
consulting contracts and more hardware sales. Many enterprise
http://www.subneural.net/postfix-master/standard.200101/0_1902_21395_00.html (1 of 3)01/16/2005 15:47:50

customers would prefer to have an operating system that runs

across all their hardware platforms and is easy to modify. Plus,
open source allows IBM to reduce its investment in software
development.
The strategy is already paying off. In December, Scandinavian

telecom Telia said it would replace 70 Sun servers with an IBM
machine capable of running multiple versions of Linux. And
Shell Oil (dossier) recently announced plans to create a
supercomputer by installing more than 1,000 IBM servers
running Linux.
But revelations don't come without risks. Though IBM

executives downplay the threat Linux poses to AIX - arguing
that the former is targeted at low-end applications and the
latter at the high end - Linux will certainly add functionality
over time, eventually converging with AIX to become one
standard Unix-based operating system. While that could erode
IBM's AIX business, it will also enable programmers to spend
their time building new applications instead of porting
applications between variants of Unix.
The blurring of lines between IBM's proprietary programs and

Linux "won't happen in the near future," says Dick Sullivan, a
VP in IBM's software group. "But if it did, that would be good
for the industry and good for us."
PREV | Page 1 | Page 2
MENTIONED COMPANIES
* Shell Oil Company (dossier)

* O'Reilly & Associates, Inc. (dossier)
* International Business Machines Corporation (IBM)
* Microsoft Corporation (MSFT)
RELATED ARTICLES
* Ready, Set ... Office XP

May 30, 2001
* Oracle Bids Joe Lockhart Adieu
May 24, 2001
* U.S. Security Site Back From Attack
May 23, 2001
* EU Waits for U.S. in Microsoft Antitrust Case
May 23, 2001
* Another Net Consultancy Finds Shelter in the Arms of a Tech
Firm
May 23, 2001
* Merrill Trims 4th-Quarter Earnings, Revenue Outlook for Oracle
May 23, 2001
* Microsoft, McAfee Forge .Net alliance
May 22, 2001
* The Rise and Fall of Computer Associates' Earnings
May 22, 2001
* Software Piracy on the Rise in Asia, Study Says
May 22, 2001
RELATED TOPICS
* Money & Markets > Corporate Activity > Earnings Reports

* Tech & Telecom > Software

RELATED RESEARCH REPORTS
Available for purchase from the Research Store.

* Success Strategies In Online Content Markets
Published by ActivMedia Research
* Benchmarking's Value -Science or Sleight of Hand?
Published by Giga Information Group
* ZEUS Q3 ASP Report
Published by Zona Research
RELATED INSIGHTS
From our Marketing Partners.

* Microsoft Office XP
Provided by Microsoft
* Consumer Relevancy: Today's Challenge, Tomorrow's Currency
Provided by Chain Store Age / Cap Gemini Ernst & Young U. S. L. L. C.
ADVERTISEMENT
FEATURED LINKS
Visit www.Office.com. The #1 online business resource center.
NextCard Visa APRs as low as 0.00% Intro! Click NOW to apply
Check out Microsoft Office XP at a Launch Event near you
Click Here To Shop Ralph Lauren's Polo.com
Save time and $$$. Enroll in Hertz' Business Account Program
Home | Customer Service | My Account | Subscribe | About Us | Media Kit

Australia | Brazil | China | Korea | Norway | Poland | Sweden | Switzerland | Taiwan
Copyright ©2001 Standard Media International. Privacy Policy

Stock data provided by Stockpoint and its data suppliers. Copyright © 1995-2001

Salon.com Technology | How Big Blue fell for Linux
Search About Salon Table Talk Newsletters Advertise in Salon Investor Relations
Find out more | Log in
Search
Salon Gear You know

All of Salon.com you want it: Bushed!
goodies are here.
Only Technology
The Web with Improve
eBusiness operations
by quantum leaps
OK
Let us Clean
your house
Directory for a Year!
FREE!
Hot Topics
Napster Looking for
Andrew Leonard Love? Try
Censorship Salon
Linux Chapter 7, part 1 Personals
Scott Rosenberg ------------
Java Extra goodies and
Technology Log great services in
Dottie Downturn
How Big Blue fell for Linux Salon Plus
View From the Top
When open-source developers and IBM took gambles on each
J.R.R. Tolkien other, free software showed it can flourish in the heartland of
corporate computing.
Articles by date
------------
● All of Salon.com By Andrew Leonard
By department
Free Software
●
Sept. 12, 2000 | The kitchen is the receptionist at Collab.net, a Project home
software start-up in the South of Market neighborhood of San page
Francisco. No one is present to greet an inquisitive visitor walking
through the open door on the fourth floor of a nondescript building
About Salon's
-- just stacked cases of Snapple fruit juice and giant bags of
pretzels; a refrigerator and a sink; a coffee machine and a water Free Software
dispenser. Project
The ambience screams of youthful coder necessities. On top of the Complete list of
refrigerator, huge boxes of Trix and Cap'n Crunch line up like published
crates of ammunition. Next to the sink sits a large jar of Twizzlers. chapters and
From the large, open room stretching beyond the kitchen, a discussions
seductive slither of spooky trance music pulses -- inviting, and yet
at the same time a little intimidating. People who work in this kind Full outline of
http://www.subneural.net/postfix-master/salon.200009/index.html (1 of 3)01/16/2005 15:47:54

Arts & Entertainment of environment are almost too cool. the book
- The Movie Page
Books
A few concessions are made to the Andrew
Comics
Mothers Who Think
sensitivities of the less hip -- the potential Leonard
News investors or clients from the old world of biography
Print story
People computing who might drop by, looking to
Politics dump a million bucks here or there. Along one Glossary
Sex wall stands a free-standing rack packed with
E-mail story
Tech & Business hundreds of issues of business/high tech
- Free Software Project magazines -- The Industry Standard, Business
Audio
2.0, Red Herring, Fortune.
- Salon Radio
Letters The magazines may not make good marketing View Salon
Columnists
material right now. Collab.net, the brainchild privately with
Corrections
of open-source star Brian Behlendorf,* aims to SafeWeb
Salon Plus make a business out of, he says, "distilling the
Salon Shop principles of open source." But at least half of
Personals
the covers of these new-economy bibles are
screaming dire, boldface warnings about the current dot-com
meltdown, including Wall Street's sharp turn away from Linux-
related stocks in the spring and summer.
Table Talk
[Free, spirited
Salon forums]
It's a good thing the office tunes are soothing, because jangled
nerves are suddenly everywhere in that strange land where free
The OS wars Which software and dot-com start-ups mix. In the summer of 1999, Red
side are you on? Hat's IPO, occurring right in the middle of a packed LinuxWorld
convention, sent attendees into a dither of delight. But in mid-
Passion or pay? Why August, no less an authority than the New York Times takes
do you do what you do advantage of another LinuxWorld convention to declaim about
for a living? how Wall Street is souring on Linux.
Dear Clown in the
Corner Office ... What
The Gray Lady is a bit late to the story -- the trade press has been
do you really want to hooting about declining valuations since early in the spring, and
say to your boss? competitors have long become adept at using the stock price
declines of companies like Red Hat and VA Linux as evidence that
● Posts of the week the open-source upstarts don't pose a threat to established,
proprietary software enterprises. Critics of free software are also
muttering about continuing delays pushing back the release of the
The Well
next version of Linux, and the failure of Netscape's Mozilla project
[Pioneering members-
only discussions] to release a usable browser.
Supplanting tobacco But the Times may also be a bit overeager: Barely one week after
The war on drugs has August's LinuxWorld, Linux companies like Caldera and VA
warped more minds Linux handily beat analyst estimates and watch their stock prices
than drugs
themselves. surge. Linux investors suddenly rejoice.
And yet, those who take heart in a one-day surge are just as guilty
Sound Off
of overeagerness. Both cynics and Pollyannas are like marks
suckered into a New York huckster's game of three-card monte.
● E-mail Salon
While they busily stare, striving to follow the movements of the
● Send us a Letter to
the Editor
dealer's hand, they never notice that Times Square around them is
● Today's letters
meanwhile being transformed from pimp heaven into Disneyland.
Sure, companies in the business of selling Linux may have
questionable prospects -- but the open-source revolution is still in
full effect, rebuilding the software industry from top to bottom,
forcing everyone to adapt.

Downloads Corporations involved in the software industry are exploring open-

● Get Salon.com on
source software, some with the enthusiasm of bodysurfers losing
your PDA
themselves in the roaring surf, others with the timidity of diffident
● Salon.com headlines
from My Netscape waders in a lagoon full of sharks. They are by no means unified in
● More ways to get their approach as an industry sector, or even internally within a
Salon single company. But there are executives and engineers at all of
these companies who believe that an extraordinarily clear business
case can be made for open-source software: Figure out how to
make it your friend, before it starts dancing on your grave.
To see this process in action, you don't need to look further than
the computer industry's venerable giant, IBM -- which has become
perhaps the best corporate friend open-source software has ever
had.
Next page | Hacker showdown at the mainframe

corral
1, 2, 3, 4
Illustration by Richard Sala
The Free Software Project

Read Andrew Leonard's book-in-progress on Linux and open source -- and post your comments.
Salon Search About Salon Table Talk Newsletters Advertise in Salon Investor Relations
Arts & Entertainment | Books | Comics | Mothers Who Think | News

People | Politics | Sex | Tech & Business and The Free Software Project
Letters | Columnists | Salon Plus | Salon Shop
Reproduction of material from any Salon pages without written permission is strictly prohibited
Copyright 2001 Salon.com
Salon, 22 4th Street, 16th Floor, San Francisco, CA 94103
Telephone 415 645-9200 | Fax 415 645-9204
E-mail | Salon.com Privacy Policy

Search How Big Blue fell for Linux | 1, 2, 3, 4

Salon Gear You know
The morning of Dec. 16, 1999, started out as it usually did for goodies are here.
Only Technology Linas Vepstas. Warming himself against the Austin, Texas, winter
The Web with cold seeping through his drafty, unheated house, he settled down See the trailers
to read his e-mail and drink his coffee. Sometimes the ritual was a before you see the
movie.
relaxing way to ease into the day; other times, the caffeine and the
messages would combine to get him bouncing off the walls. Like Discover
OK
most hackers, Vepstas lived his life via e-mail -- his main hobby, exquisite
at the moment, involved coordinating a major Linux project via handmade
Directory world art and home
online communiques with an international band of similarly
décor at NOVICA
dedicated coders.
Hot Topics
Napster Slam-dunk
Andrew Leonard But his e-mail on this winter morning was neither soothing nor
your IT competition!
Censorship invigorating. It was paralyzing. In just a few lines, all the work he
Linux had done for the last year and a half evaporated.
Extra goodies and
Scott Rosenberg great services in
Java Salon Plus
The message came from Alan Cox,* a man
Technology Log
Dottie Downturn widely considered to be the second most
View From the Top influential hacker in the Linux community,
Print story
J.R.R. Tolkien after Linus Torvalds. From his home in
Swansea, Wales, Cox -- his independent
Articles by date contractor's salary paid by Red Hat -- fulfilled E-mail story
an extraordinarily important role as maintainer
● All of Salon.com of the Linux kernel.* While Torvalds was off
● By department working on the next version, Cox spent much
of his time consolidating bug fixes and patches
to older versions -- keeping the kernel up to View Salon
date and secure, extending its ability to privately with
interface with new kinds of hardware. SafeWeb
The message read as follows:
They finally delivered code. A decent-looking SMP

kernel, console and some networking stuff. Glibc,
gcc, binutils, gdb patches.
The kernel stuff is in 2.2.14pre14. I'll forward you

the other patches if you want.
http://www.subneural.net/postfix-master/salon.200009/index1.html (1 of 6)01/16/2005 15:47:56

Arts & Entertainment Alan

- The Movie Page Free Software
Books Project home
Comics
"They" meant IBM. And the "code" was a package of extensions
and patches to the Linux kernel and other associated free page
Mothers Who Think
News programs, created by a team of IBM programmers in Böblingen,
People Germany, near Stuttgart. The additions made it possible to run About Salon's
Politics Linux-based operating systems on IBM's top-of-the-line Free Software
Sex mainframe computer, the System 390. Project
Tech & Business
- Free Software Project
Audio
Vepstas stared at the message from Cox in shock. Complete list of
- Salon Radio published
I tried to read a few more e-mails," he says, "but found I couldn't chapters and
Letters
concentrate. I bit my lip, I bit my tongue. I'd long ago learned the discussions
Columnists
Corrections lesson of regretting one's words, and wasn't about to regress. A
measured response would come later." Full outline of
Salon Plus
the book
Salon Shop
Personals
Vepstas was irritated for several reasons. He had heard rumors
about the Böblingen "skunk works,"* but nothing definitive, Andrew
nothing as impossible to ignore as the actual delivery of code. He Leonard
felt he should have been better informed. At the very least, he biography
thought he deserved first notice of IBM's official efforts.
Table Talk
[Free, spirited Glossary
Salon forums] For the better part of two years, Vepstas and a small cadre of
programmers had been writing their own version of Linux capable
The OS wars Which of running on the 390. The project was called Bigfoot, and it had
side are you on? attracted a fair amount of admiring -- even if somewhat perplexed
-- attention from the Linux community. Mainframes were "big
Passion or pay? Why iron," the biggest, most powerful and expensive computers
do you do what you do
for a living?
available this side of a supercomputer -- the kind of computers that
a bank or an airline would use to run its operations.
Dear Clown in the
Corner Office ... What Once upon a time, mainframes had ruled the computer roost. But
do you really want to toward the close of the 20th century, mainframes had lost some of
say to your boss? their grand allure. During the '90s, the network came of age, and
scampering, decentralized agglomerations of PCs made lumbering
● Posts of the week
mainframes seem like evolutionary losers. Heck, all you needed
was a cheap PC, a Linux-based operating system and the Apache
The Well Web server, and you could host your own Web site, right?
only discussions] Right, and wrong. By the end of the '90s, mainframes, much to the
surprise of some observers, were back in favor. Only now they
Supplanting tobacco were being called "servers." The reasons for their comeback?
The war on drugs has
warped more minds
Running Web sites had become big business for many companies,
than drugs including a significant portion of IBM's traditional Fortune 500
themselves. customers. The pure processing power and ironclad reliability of
the monster mainframe was once again beginning to look
attractive, as the Web increasingly became part of an infrastructure
Sound Off
channeling massive quantities of mission-critical data in torrents
● E-mail Salon that would drown even the mightiest of PCs.
● Send us a Letter to
the Editor Vepstas wasn't particularly interested in the resurgence of the
● Today's letters mainframe market; he wanted to hone his technical chops. To get
Linux to run on a killer machine like the 390 would be a nice hack
indeed -- he would have to write his own compiler and assembler
and master the tricky job of porting an entire kernel to a new
hardware architecture. As Vepstas notes, the 390 had "a fabled,

legendary status as a computer design, and I figured it was damned

Downloads high time I learned it."
your PDA
● Salon.com headlines But Linux had originally been designed to run on cheap Intel PC
from My Netscape hardware. And the 390 already had two different proprietary-to-
● More ways to get
IBM operating systems designed just for it, considered by many
Salon
IBM engineers to be the culmination of decades of the best work
of IBM research and development talent. Getting Linux to run on
an IBM mainframe was not only technically challenging, but also
seemingly pointless -- like using a cheap, tinny transistor radio as
the sound system in your brand new BMW.
As it turned out, IBM had very good reasons for wanting Linux
running smoothly on the 390 -- as well as for keeping the project
quiet while it was still incomplete. But on the morning of Dec. 16,
nothing could have prevented Vepstas' shock from quickly turning
to anger. As he wrote to the Linux/390 mailing list on Dec. 18,
after IBM announced to the world what it had demonstrated to
Cox two days earlier:
"I personally have spent many evenings and weekends working on

this project, without pay, for just the glory of it," wrote Vepstas.
"Although I cannot speak for others, others have also invested
their time. I am not happy; I take IBM's actions to be a personal
affront."
Eight months later, Vepstas has let his grudges subside -- he's
immersed in a new project, GNUCash, a free personal-finance
management program. He's moved on. But at the time, Vepstas
could be excused for feeling slighted. One of the motivating forces
fueling free software hackers is the reputation game -- the better
the hack, the more cred you get in your community. But by
obliterating his project, IBM had eviscerated his chance for such
cred. His own background as a programmer who had worked for
IBM for 10 years made the blow hit especially hard.
Hurt feelings were only one part of Vepstas' discontent. Of larger

concern was the fundamental contradiction between a "skunk
works" project -- carried out in secrecy, not only from the rest of
the world, but also from the rest of IBM -- and the basic
philosophy of open-source software. Ideally, open-source software
involves the coordination of large numbers of programmers, thus
reducing unnecessary duplication of work and improving the
chances for peer review. Even more fundamentally, open source is
open: Everyone gets to look at the code. But IBM's programmers
had done their work in private. Was the company attempting to
gain the advantages of Linux without allowing the collective
participation essential to a smoothly functioning (and ideologically
correct) open-source effort?
"Without conversations and communications, development cannot

be coordinated," Vepstas declared to the list. "We could have
gotten more done, been further along. Due to bad management
decisions within IBM, time was wasted and money was wasted. I
believe that these bad decisions were made because the managers
do not understand the open-source development process. This is

why I write this screed."
"Lack of transparency and secretive development leads to other

problems besides just wasted and duplicated effort," continued
Vepstas. "It directly harms the open-source community, and
directly harms the corporate image and credibility of IBM. I have a
four-year-old son who has recently learned the phrase 'trust me.'
He says 'trust me,' and then, minutes later, is doing something bad
again. We are trying to reason with him: 'You know that is a bad
thing to do. Why did you do it? Next time, think before you act.
Do the right thing. If you always do the right thing, then we can
trust you.' (Unfortunately, the only effect this has had is that he's
stopped saying 'trust me.')"
Perhaps the most incongruous aspect of Vepstas' unfortunate

experience with IBM was its context. IBM boasts a reputation for
playing by open-source rules that surpasses that of any other major
computing corporation. Even Richard Stallman, a man utterly
unafraid of castigating the high and mighty, has little negative to
say about Big Blue. Indeed, the eyebrow-raising announcement, in
the summer of 1998, that IBM was basing its WebSphere family of
e-business products on the Apache Web server program did more
to create a relationship between the world of open source and the
established corporate software industry than any other single act.
Today, IBM executives like to portray the Linux-for- the-390

effort as part of a coherent strategy aimed at coming to grips with
vast changes overtaking the software landscape, changes it saw
coming way back in 1998. As Bill Zeitler, the general manager of
the Enterprise Servers division, declaims -- "It is in IBM's strategic
interest to work as closely with the open source community as we
can... This is not a fad -- this is a profound disruptive change in the
way that software will be developed and deployed." So Linux for
the 390 is not only the crown jewel in a current initiative to
support Linux on every level of IBM hardware, from Thinkpads to
mainframes, but is also the logical conclusion to a three-year
journey of rapprochement with the world of free software.
The truth is a little more complicated.
The story of how IBM made friends with free software hackers,
from the early days when it dipped its toes into the Apache Project
to its current headfirst plunge into Linux, is not the story of a
carefully executed strategy. It is instead a tale of contingency,
luck, a few committed engineers and a few canny executives. Its
twists and turns hinge on the results of combating agendas,
political maneuvering and software ambition. At its most
mundane, it is a story that hints at how the battle for dominance
over new software markets will be waged over the next few years.
At its most metaphysical, it is a story that illuminates the
contradictions inherent in the very concept of a "corporation."
It's all too easy to see a company like IBM, or Sun, or even
Microsoft, in the terms of the legal fiction that is represented by
the word "corporation," to anthropomorphize it as a "body" and
give it attributes -- evil, good, brilliant, stupid, spunky, lumbering.

But the modern corporation is far too fragmented and balkanized

to personify in such simple, unitary terms.
The 390 Project provides a perfect example. The engineers

responsible, a group of young Germans, wanted to, in the words of
team leader Boas Betzler, "do something totally strange. We were
just a group of techies that wanted to find out how smart we were."
"In the beginning, we really did not think about how big an impact
we could make," says Betzler. "We always wanted to demonstrate
the power and capability of the mainframe and then give it to
someone who would know Linux and see the machine and use it
and say 'Wow, that's a really big Linux.'"
A higher tier of engineers, those who defended the project in turf

wars within IBM (or hid knowledge of it from competing
factions), saw a chance to make a strategic move that would help
boost 390 sales -- by ensuring that the 390 would be a platform
comfortable with the vast array of Unix/Linux applications
available. Even further up, executives jockeying their way up the
corporate ladder placed bets on Linux as a means of gaining
advantage in the never-ending political warfare that exists in any
large company. And at the top, even CEO Lou Gerstner played a
role, determined that if IBM was going to support open source, it
wouldn't do so in a halfhearted manner.
Even Linas Vepstas, after his initial rage had subsided,

acknowledges that IBM's internal politics made it impossible to
allow the Burblingen team to interact with the wider open-source
software community.
"I think many people don't realize how much the social dynamics
inside of large companies [such as IBM] resemble that of the open-
source community," says Vepstas. "It's just that within large
corporations the cooperation and the bickering are hidden from
public view. The Linux/390 guys within IBM were stepping on all
sorts of land mines internally."
The huge importance of the 390 mainframe within IBM -- both

symbolically and strategically -- ensured that the executives with
the most knowledge about Betzler's activities kept them quiet. But
at just about the same time Betzler got started -- the spring of 1998
-- other groups at IBM were reaching out to the open-source world
with open arms.
Next page | Dinner at the Big Tomato -- IBM

meets Apache
1, 2, 3, 4



Telephone 415 645-9200 | Fax 415 645-9204


Salon Gear You know
On the corner of Third Street and Bryant, in the South of Market goodies are here.
Only Technology neighborhood of San Francisco, there is a restaurant known as the
The Web with Big Tomato. Its real name is Vine e Cucina, but the local clientele Improve
are too busy programming or otherwise online-obsessed to be eBusiness operations
bothered with its actual name, and just refer to it by the by quantum leaps
unavoidable sign out front.
OK
The perfect
summer
In 1998, the Big Tomato enjoyed a fortuitous propinquity to one of
Directory apparel. Order
the world's most thriving physical nodes of Internet culture and
a Salon T-shirt today!
business. Countless Web-related start-ups clustered in the
Hot Topics
Napster
buildings nearby. Organic Online, the high-end Web production Looking for
Andrew Leonard studio that employed open-source star Brian Behlendorf as its Love? Try
Censorship chief technical officer, was just a few feet away. So were the Salon
Linux offices of Wired magazine, for which Behlendorf, at the tender age Personals
Scott Rosenberg of 19, had brought Wired's online adjunct, HotWired, onto the Net.
Java Behlendorf still hasn't strayed far -- Collab.net, his current startup, Extra goodies and
is just another long block away. Salon Plus
Dottie Downturn
View From the Top
J.R.R. Tolkien So when people came to visit Behlendorf in
his own neighborhood, there was a good
Articles by date chance that the Big Tomato was where they
Print story
would end up -- which explains why one
● All of Salon.com spring evening in 1998, he had dinner there
By department with two representatives of IBM, James Barry Free Software
●
E-mail story
and Yen-ping Shan.
Project home
page
In retrospect, the meeting was a dramatic
turning point, the moment when the old world
About Salon's
and new world of computing met to shake View Salon
Free Software
hands. At the time, though, unless you were a privately with
very close follower of the nascent open-source SafeWeb Project
scene, you might have been excused for
wondering what reason Big Blue could have Complete list of
for setting up a powwow with a ponytailed 24- published
year-old who split his time between Organic chapters and
Online and rave DJing. discussions
By that summer, Linux-based operating systems had already Full outline of

Arts & Entertainment attracted a huge following, and earlier that spring Netscape had the book
- The Movie Page made the dramatic announcement that it would be releasing the
Books source code to its Navigator Web browser. But the traditional Andrew
Comics
corporate world, at least from a managerial standpoint, still didn't Leonard
Mothers Who Think
News
seem to know what to make of this hacker frenzy. Software biography
People engineers everywhere were already gung-ho, but the suits were a
Politics step or two behind.
Glossary
Sex
Tech & Business James Barry and Yen-ping Shan weren't your ordinary IBM suits,
- Free Software Project however. Barry, the product manager for WebSphere, a set of
Audio
closely related e-business programs, was a jeans-in-the-office kind
- Salon Radio
of guy, and had been employed by IBM for little more than a year.
Letters Shan, IBM's chief architect for e-business tools, came from an
Columnists engineering background. The two men were complementary
Corrections
halves to the same coin. Barry was a gregarious and jovial 43-year-
Salon Plus old who in 1998 already had years of experience in online affairs,
Salon Shop dating back to a bulletin board he had operated in Boulder, Colo.,
Personals in the early '90s. He recalls, "Shan was the technical guy who
knew a lot about marketing, while I was the marketing guy who
knew a lot about the technology."
Table Talk Both men were certain of one thing: It was in IBM's interest to
[Free, spirited support the Apache Web server, a program developed by a loose
Salon forums]
group of volunteer programmers led by -- or, more accurately,
coordinated by -- Brian Behlendorf. But just getting as far as this
The OS wars Which
meeting had required mastering an internecine political process at
side are you on?
IBM that defied ordinary mortal comprehension. Engineers at IBM
Passion or pay? Why
had been fans of Apache since at least 1996, when it was used as
do you do what you do the Web server platform underlying IBM's Web-based front end to
for a living? the Atlanta Summer Olympic Games. But IBM also owned Lotus
software, which had its own Web server program: Domino Go.
Dear Clown in the IBM software executives kept squashing engineering's Apache
Corner Office ... What enthusiasm, tracing their mandate all the way back to the CEO,
do you really want to
Lou Gerstner. You've got to eat your own dog food; if IBM had a
say to your boss?
Web server product, it should be pushing that product and using it
for its own servers.
The only problem was, practically no one besides IBM itself was
The Well using Domino Go, which made it rather unwise to rely on the
[Pioneering members- program as a first step for penetrating other Internet software
only discussions]
markets. For months, Barry and Shan had been working to
persuade IBM of Apache's strategic advantage.
Supplanting tobacco
warped more minds First, Apache was what people were using. Shortly after Barry had
than drugs been hired, initially as a consultant to evaluate IBM's
themselves.
"middleware"* offerings, he had lectured IBM managers on the
fact that Apache was the most popular Web server program on the
Sound Off Internet -- and the single most widely used piece of software for
the hosting of Web sites. Even in the Fortune 500, IBM's home
● E-mail Salon territory, more companies were running their Web sites on Apache
● Send us a Letter to than on Domino Go. (Though, to be fair, some of those high-
the Editor
profile corporate sites, such as those belonging to Nike and Levi's,
● Today's letters
were actually being hosted by Organic Online.)
Second, although Apache dominated the statistics for publicly

accessible Web servers, owning more than 50 percent of a hotly

contested market, Microsoft's share was also growing steadily.

Downloads And again, that growth was occurring in the well-heeled market
your PDA sector that IBM most lusted after. Apache owned the low end of
● Salon.com headlines the market, but Microsoft was gunning for where the money was.
from My Netscape If IBM wanted to prevent Microsoft from claiming yet another
● More ways to get software market, it needed to join forces with Apache.
Salon
Third, since so many sites were using Apache, a vast amount of

software tools had been created that would work with Apache.
And since Apache was both open-source and conformed as closely
as possible to all public Internet standards, it was easy to adapt
those tools to different software platforms. According to Barry, if
IBM came up with a set of software services that worked on top of
Domino Go, it took a good deal of code rewriting to get that
software to work with either Apache or Microsoft's IIS Web
server. By making Domino Go the center of IBM's strategy, it was,
in effect, handcuffing itself.
For a year and a half -- much of which, say his friends, was spent
in the air traveling from IBM office to IBM office -- Barry pushed
the open-source strategic imperative to anyone who would listen.
If IBM was interested in fending off Microsoft, if it cared at all
about creating the widest possible pool of customers for all the
fancy e-business services that IBM wanted to offer its customers,
then it must get with the real program -- the open-source program,
the Apache program.
There was just one niggling problem, even after Barry and Shan
finally won over higher levels of IBM management: IBM wanted
Apache, but did Apache want IBM?
Certainly, Brian Behlendorf was cautious. He describes his own

state of mind at The Big Tomato that night as "guardedly thrilled."
Behlendorf is not by nature a suspicious man, but he was wary. He
might still have appeared to be a wet-behind-the-ears Internet
hacker, but he knew IBM. His parents had actually met each other
while they both worked at IBM -- if anyone had grown up steeped
in the culture of the computing industry's most dominant
enterprise, it was Behlendorf. IBM had a way of swallowing its
collaborators, of overwhelming smaller companies with its
phalanxes of sales shock troops and mind-numbing invasions of
managers. As a representative of not just the Apache Group, but
all of emergent Net culture, Behlendorf couldn't help being
restrained in the face of outreach from one of the world's biggest
corporations.
Behlendorf did not "run" Apache. No one did. Instead, he helped

coordinate the efforts of a group of programmers, all of whom for
one reason or another needed a good Web server program to help
them carry out their day job or hobby, to improve the existing
publicly available Web server technology. The original base of
code came from the University of Illinois, developed by the same
team of programmers that had created Mosaic.
But those programmers had moved on en masse to Netscape,

which -- at the time of Apache's emergence in the mid-'90s -- was

developing, slowly, its own high-priced, proprietary Web server.

Meanwhile, as the Web expanded at phenomenal speed, there was
a drastic need for improvements to the existing freely available
Web server code. All across the Net, webmasters were hacking
their own patches* to the code, quick fixes that would help them
respond to their daily needs. Finally, a group of these programmers
got together, collated all the patches and created "a patchy server"
-- Apache.
Behlendorf's influence came through his calming presence on

Apache-related mailing lists, as the systems administrator for the
Apache Web site and as the maintainer of the Apache "source
tree"* -- the code base for Apache to which the core group of some
20 programmers had access. His interest always was, and still is, to
devise technological means of enhancing collaboration. Lacking
the ideology of a Stallman, or the programming skills of a Linus
Torvalds (he is quick to say of himself, with a self-deprecating
smile, that "I am not a very good programmer"), his motivation
has always been to create things that work, that get the job done.
Apache got the job done. It wasn't necessarily the best Web server,
the fastest, the most powerful or the most secure. But it was still
the most widely used, in large part because it handled, simply and
effectively (and freely), the tasks that most people needed
handling.
Of course, IBM had a different set of motivations -- generating

revenue being chief among them. So when James Barry told Brian
Behlendorf that IBM wanted to use Apache as part of its own
family of e-business products, and that it wanted to start
contributing to the Apache project, Behlendorf's first reaction,
recalls Barry, was defensive. The Apache group did not want a
giant corporation to come in suddenly and take over. Yen-ping
Shan hastened to sooth him.
"I told him," recalls Shan, "that we are going to play by your rules,
because we believe that your structure and practice actually
works."
Shan added that IBM's support could only strengthen Apache.

"There are multiple ways IBM is going to help," Shan remembers
saying, "not just technologically but as an endorsement that will
solidify Apache in the IT [information technology] world. IBM
will announce enterprise-level support."
Fine. If IBM was going to play by Apache's rules, then that's what
it would have to do to win the Apache group's support. To do that
would require something a bit more substantive than taking
Behlendorf out to dinner.
It would require code.
IBM had to become a contributor. And it would have to prove

itself the way any Apache contributor did, by submitting patches
that were accepted by the core as valuable improvements to the
Apache code base. And it had to do so in a sensitive way.

Behlendorf did not want to see hundreds of patches appearing

from scores of IBM engineers. He didn't want IBM to suddenly
dominate the open discourse of existing Apache programmers. If
IBM wanted one of its employees to become a member of the
Apache core (which Barry and Shan's boss had set forth as an
essential requirement before greenlighting their mission to
Apache), then that employee would have to earn his or her way
there like anybody else, by merit, through the quality of his or her
hacking.
Barry and Shan agreed. It wouldn't be easy. The very concept of

an IBM employee contributing code to a project that wasn't owned
by IBM raised hackles on legions of IBM lawyers. Traditional
software industry policy held that an employer owned everything
an employee did, even to the extent of idle thoughts the employee
might linger over while showering in the comfort of home. There
was also the sticky question of patents -- what if a contribution of
code from an IBM engineer included concepts or techniques that
had been patented by IBM -- what would happen to those patents
if they became part of the public domain? What about liability
issues?
Barry recalls with a pained grimace the months of meetings that

had to be undergone in order to work out such issues. But, credit
must be given to IBM's legal team. The issues were worked out. A
single programmer, Bill Stoddard, was given the job of being the
connection between IBM and Apache -- if any of IBM's
programmers came up with a patch, Stoddard reviewed it first, and
then he personally submitted to the Apache group.
And in the Apache group, good code always won the day.
Stoddard's contributions were accepted. IBM was accepted. IBM
endorsed Apache, and gave open source an entree into the land of
the suits. And Apache endorsed IBM, proving that hackers could
work with the biz guys. The announcement of the agreement
generated some 1,000 media stories -- which, more than any other
fact, Barry recalls with a rueful grin, sealed the deal for upper
management. That kind of positive press was by definition a
successful strategic move.
Today, all three representatives at that meeting have moved on to

new jobs. Yen-ping Shan is the chief technical officer at the largest
payments-processing firm in the United States. Brian Behlendorf
is CTO of Collab.net. And James Barry works a desk about 30 feet
from Behlendorf. He is now Collab.net's vice president of strategic
development.
Next page | Lou Gerstner reads the New York

Times, loses it, and IBM goes open source
1, 2, 3, 4



Telephone 415 645-9200 | Fax 415 645-9204


Salon Gear You know
The summer and fall of 1998 saw one open-source-related goodies are here.
Only Technology announcement after another from Big Blue. IBM joined the
The Web with Apache Project in June. In mid-July, two researchers named David Looking for
Shields and Philippe Charles announced the release of a version of Love? Try
Salon
their JIKES Java compiler for Linux. By September they had open-
Personals
sourced JIKES. At the same time, a Toronto researcher named
OK
Gary Valentin had completed his own skunk works project, New Salon
porting IBM's db2 database software to Linux. Meanwhile, that Gear!
Directory
spring, Boas Betzler and his Burblingen cohorts had begun work Featuring
on their 390 port. our original
Hot Topics artwork.
Napster
Andrew Leonard But there was still no companywide strategy. In various corners of 0% Intro
Censorship the IBM empire, individual researchers like Shields or strategists APR & up
Linux like Barry (who met and became friends through an open-source to 2% Cashback®
Scott Rosenberg mailing list started by Barry for IBM employees) were doing their
Java own thing, but as a company, IBM was hardly united. Shields does Extra goodies and
recall one key meeting of the IBM Academy of Technology, a
Dottie Downturn Salon Plus
grouping of 300 of IBM's most distinguished scientists in October
View From the Top
J.R.R. Tolkien
1998, at which both he and Barry spoke, as crucial. The Academy
declared Linux to be an "earthquake" (as it had earlier declared
Articles by date
Unix and the Internet) and petitioned Lou Gerstner to review their
findings.
● All of Salon.com
● By department But even though Gerstner formed a task force
to study Linux, the struggle over policy at
lower levels still raged without cohesion.
Print story
Barry recalls how plans to write a version of
WebSphere 3.0 for Linux were spiked by an
IBM executive who gave a speech at IBM's
E-mail story
research lab in Raleigh, North Carolina,
declaring that Linux was "going nowhere."
That executive, he notes now, without hiding
his satisfaction, is currently in charge of an
IBM division devoted to Linux. View Salon
privately with
The task force recommendations, says Barry, SafeWeb
were watered down and "milquetoasted." IBM
seemed lost at sea.

Arts & Entertainment

- The Movie Page Then came the morning of Dec. 14, 1998. Free Software
Books Project home
Comics That day, John Markoff, the lead technology reporter for the New page
Mothers Who Think York Times, wrote a short piece entitled "Sharing Software, IBM
News
to Release Mail Program Blueprint." In it, Markoff detailed how About Salon's
People
IBM was planning to release a mail program called Secure Mailer, Free Software
Politics
developed by a programmer named Wietse Venema, as open
Sex Project
Tech & Business source. What the article didn't say was that the program had been
- Free Software Project something that Venema had created before joining IBM, that it had
Audio
Complete list of
always been open source, and that IBM was only now
- Salon Radio acknowledging that Venema could keep working on it as an open- published
source project. chapters and
Letters
discussions
Columnists
Corrections But that didn't matter. All that counted was that IBM CEO Lou
Gerstner read the article, and, according to legend, immediately Full outline of
Salon Plus
became apoplectic. As far as he knew, IBM already had a mail the book
Salon Shop
Personals program -- it was part of the Lotus Notes package. And if IBM
was endorsing open-source software as a worthwhile strategy, then Andrew
Gerstner wanted to know about it. Leonard
biography
Table Talk James Barry says that Gerstner didn't care one way or another
[Free, spirited about open source as a software methodology. Barry says that Glossary
Salon forums] Gerstner frequently liked to note, "I am not a technologist." What
he cared about was strategy. Did IBM have an open-source
The OS wars Which strategy? And if so, what was it?
side are you on?
Gerstner started making phone calls. First he called his chief of

Passion or pay? Why
do you do what you do
software, who called his subordinate, who in turn called his. The
for a living? conference call kept expanding, until it made its way down to the
research director who managed Venema. By the end of day,
Dear Clown in the Gerstner had his answer. There was no clear strategy. Or at least
Corner Office ... What there hadn't been up to that point.
do you really want to
say to your boss?
"There was that one morning in December of 1998, and by that
afternoon the open-source strategy had jumped into the runway,"
says Dan Frye, IBM's program director for open source and Linux.
"We talked to everyone in the industry. The answer we came back
The Well with was that open source was good for us."
only discussions]
As a result, Linux got the green light. The skunks could come out
of the woodwork.
Supplanting tobacco
warped more minds Of course, it still wasn't easy.
than drugs
themselves.
"Internally, the battles were amazing, and you could understand
why," says Jeff Nick, chief architect for the System 390. "A lot of
Sound Off the [IBM] technical community was very incredulous about this.
You grow up in an OS/390 [the operating system designed for the
● E-mail Salon 390] community, and there is great passion and pride in the
● Send us a Letter to heritage of OS/390 and the integration of its capabilities into the
the Editor
hardware platform. To suggest that there is a value proposition for
● Today's letters
running an open-source, not controlled, Unix platform on our
hardware, and to propose that Unix applications might be better
suited for running on Linux on the 390, than on OS/390. I was
almost seen in my own technical community, particularly in the

system 390 design council, as antichrist. There were multiple

Downloads painful meetings with my technical peers across IBM on the
your PDA OS/390 platform. They were saying, you must be out of your
● Salon.com headlines mind, why would you want to do this, we need to protect the
from My Netscape OS/390 environment."
● More ways to get
Salon
"It was a huge risk," says Nick. "And the reason we were
ultimately successful was that we could show that by supporting
middle-tier Unix applications that are collaborative in a distributed
environment with the 390 back end and by running that entire
heterogeneous workload on our platform, we would actually in the
end be providing a bigger platform for our customers than we
would if we forced everything to be on OS/390. There's a huge
risk in that statement, but we are banking on the power of open
source."
Huh? Just what exactly is Nick trying to communicate here, in that

mix of techno-jargon?
In essence, pretty much the same thing that James Barry and Yen-
ping Shan were saying when they pushed Apache. There is a
whole world of people using Linux-based operating systems and
the vast ecology of programs that run on those operating systems
right now. An enormous amount of work is being done using a set
of tools that have a Unix heritage and are currently at home on
Linux-based systems.
The Linux generation is in some ways the heart and soul of the
Net, and its numbers, according to Nick, are surging. An entire
generation of programmers has adopted Linux. It doesn't matter
whether they are doing this because they hate Microsoft, or think
Linux-based systems are technically superior, or just like to hack
on free software. The fact is, it's happening. Market share for
Linux-based operating systems -- and mind share for Linux among
developers -- is continuing to rise.
By ensuring that Linux will run on the 390, IBM would ensure that
its mainframes would be an attractive environment for all those
programmers and system administrators to work in. A bank could
use its mainframe to handle its massive data-processing needs, and
at the same time allow its Linux-skilled programmers to do
whatever they needed to do -- in particular, to make use of all the
middle-tier software applications that have been developed to get
things done in an open, Internet environment. By expanding the
possibilities, IBM would be able to expand its own market
penetration.
The break with tradition represented by IBM's decision to open up

the mainframe to non-IBM software is hard to overstate. For
decades, IBM banked on selling customers the entire "vertical"
package. From the hardware to the software to the support, it was
all Big Blue, all the way. But now, by acknowledging that it made
strategic sense to -- paraphrasing Chairman Mao -- let a hundred
software programs bloom on the mainframe, IBM was signaling
that it knew it could no longer call the shots in the mainframe
marketplace.

Again, it just doesn't matter, from this perspective, whether Linux-

based operating systems might actually be technically inferior to
their Windows NT or Sun Solaris competitors in certain aspects. I
asked Nick why, if it made so much sense to try and take
advantage of all those people with Linux skills, wouldn't it also be
prudent to attempt the same with NT, and gain access to that huge
world as well?
"It would be great if you could do that," says Nick. "But the
difference is that because Linux is open source, which allows it to
be worked on by a large collaborative set of developers, it has also
been built to be platform agnostic. It's got what we call horizontal
layering of function, so you can easily port the OS to multiple
machine architectures and platforms. This is not true of NT and
this is not true of most Unixes -- where each operating system has
grown up tied to its machine architecture. "
In other words, Linux, even if it may have started out as a hack to

run Unix on a cheap Intel processor, has since evolved into the
ultimate protean operating system. Over the years, its functions
have been streamlined and compartmentalized to the point where it
has become relatively easy to adapt it to different systems.
As such, Linux-based operating systems (as well as BSD operating

systems, although they represent a much smaller percentage of the
current OS marketplace) are the true heirs of what one
programmer once immortalized as the "worse is better" paradigm.
In the 1980s, a programmer named Dick Gabriel wrote a paper

about the programming language C++ and the operating system
Unix called "Worse is Better." His argument was that simple
systems that get most of the job done are better at surviving, over
the long run, than complex systems designed to do everything
perfectly. Complex systems are hard to adapt to new situations,
and can break down easily. Simple systems can be fixed quickly,
and mutate even faster.
Today, Gabriel is the main open-source evangelist at Sun

Microsystems, and C++ and Unix are the building blocks out of
which the Internet has been constructed. Linux is just the newest
all-purpose building material.
There's a "virtuous cycle" here that feeds voraciously on itself. As

Linux is ported to an ever-increasing number of hardware
platforms, an ever-increasing number of programmers gain the
opportunity to work on code that benefits everyone. Which in turn
makes Linux-based systems even more attractive.
And that's the business case for open source. At first listen, "worse
is better" sounds like Orwellian doublespeak, a phrase designed
more to confuse than enlighten. But in practice, "worse is better" is
an actual evolutionary success strategy -- and nothing exemplifies
its principles better than open source.
------------

Read Chapter One of the Free Software Project
Join the discussion on this chapter
Next installment: The Sun also rises on open-source software --

how Sun Microsystems, with a little help from Collab.net, is
learning from its mistakes and joining the world of open source.
salon.com
------------
About the writer

Andrew Leonard is a senior writer for
Salon Technology and author of Salon's
Free Software Project, an online book-in-
progress exploring the history and culture
of the free software movement.
Sound Off
Send us a Letter to the Editor
Salon.com >>
Technology


Telephone 415 645-9200 | Fax 415 645-9204

Postfix and Mailman deliver enhanced e-mail security and performance
Advertisement: Support SunWorld, click here!
Search Subscribe, It's Technical FAQs

Free
Submit Query Solaris Security
March 1999 Letters to the Secure
Topical Index Programming
Editor
Home Backissues Performance Q&A
Events
SunWHERE SE Toolkit
Mail this Article Calendar
TechDispatch
Newsletters
Postfix and Mailman deliver enhanced e-mail

security and performance
Learn how these new open source products can improve the way you
manage mail
Summary
Good news -- there are better ways to do e-mail. Cameron and Kathryn introduce
two new open source mail products called Postfix and Mailman and explain how
you can begin to use them in your own work. Find out what you need to get
started with these interesting and rewarding technologies. (2,500 words)
By Cameron Laird and Kathryn Soraiz
hile e-mail is the most mature and most widely diffused Internet application, it hasn't
stopped growing. The last year alone has seen several exciting developments and
announcements, even in the oldest and least "sexy" domains: mail transfer agents and mailing
list managers.
Keep in mind the fundamental architecture of e-mail processing: At your desktop, you
compose a message. You use a mail user agent (MUA) as the user interface to pass your
http://www.subneural.net/postfix-master/sunworld-199903.html (1 of 9)01/16/2005 15:48:01

message, along with such other information as the address for which it's intended, to an e-mail
server. A mail transfer agent (MTA) on the server takes responsibility for figuring out how best
to deliver your message (Is it local -- should it go through my LAN? Is it external? What server
on the other end will receive it?). Generally, it communicates with another MTA on the server
used by your intended recipient. Once the message has been received by that second MTA, it's
available for your recipient's MUA to access it.
The MTA market

Sendmail dominates the MTA market, as it has for the last 20 years. About two-thirds of all e-
mail servers rely on this open source product. Sendmail is far more reliable, flexible, and
portable than most of the commercial products that attempt to compete with it, and the recent
launch of the for-profit Sendmail Inc. seems to have only enhanced the vigor of this venerable
no-cost creation.
Sendmail isn't perfect, though. It's bulky, difficult, and has a history of security problems. More
precisely, it's in just the shape you'd expect of a product originally built for a much different
computing environment, and it's been patched and rewritten during several computing
generations. Still, the Sendmail development team has achieved quite a feat in bringing it
forward from the far more relaxed security traditions of two decades ago.
Wietse Venema has an alternative, though. Venema, a security expert on the IBM Research
staff, started fresh, and has produced Postfix, a drop-in replacement for Sendmail which
promises to deliver e-mail more quickly, conveniently, and safely.
Postfix isn't Sendmail's only challenger. Zmailer, Smail, qmail, Post.Office, exim, the Sun
Internet Mail Server (SIMS), MMDF, CommuniGate, PMDF, Netscape Messaging Server, and
a variety of other products offer specific benefits for Unix-hosted e-mail service. Postfix is the
newest of these, however, and worth a look.
Postfix's heritage
Venema has a track record in secure computing. He says his "claim to fame is largely based on
the low incidence of error" in the systems he's written, including Security Administrator Tool
for Analyzing Networks (SATAN) and TCP Wrapper. In designing and implementing Postfix
(which began life as VMailer and Secure Mailer; don't be confused by the name changes),
Venema's goal was for it "to be fast, easy to administer, and hopefully secure, while at the same
time being Sendmail-compatible enough to not upset your users."
He's made enough progress toward that goal that IBM has agreed to release Postfix as an open
source product under an IBM license in the spirit of Perl's Artistic License. (Caution: While
IBM supports Venema, its marketing department occasionally garbles the message. Don't be
alarmed if you run into a Web page that suggests you must pay for Postfix, or that its use is

otherwise restricted. While IBM is arguably the big

company that best understands the open source story, it's
still learning. The first official IBM Web pages about
Postfix were confusing.)
Venema labels the current Postfix a "beta." To him this

means "something close to perfection... It has nothing to do
with software quality." He's quite confident in the quality
of Postfix. For him, beta releases amount to an experiment
to determine users' needs.
Sendmail is a famous monolith: it's one big program that

does everything. Postfix is more Unix-like in that it
consists of a number of little programs, each of which is
easy to understand and validate, including postlock,
postalias, postlog, postmap, and others. This is part of the
answer to Sendmail's notorious vulnerability. Because
Sendmail does so much, it effectively needs superuser Wietse Venema
privileges and is correspondingly easy to subvert. Each of
Postfix's parts has a limited role, so even if it's faulty and behaves in an unplanned way, it's
unlikely to have enough security permissions to do any serious damage.
Becoming a Postfix administrator

Trying out Postfix for yourself is only a small commitment. A compressed source code bundle
(cryptographically authenticated, of course) is well under a megabyte. Once fully expanded,
unpacked, and generated, a complete build tree, including all object files and binaries, fills
from 30 to 50 megabytes, depending on the target operating system. It's utterly straightforward
to build a complete installation kit on every common Unix platform: the make takes less than
10 minutes to run, even on poky hardware. The INSTALL directions included thoroughly
explain how to do one of the following:
● Send mail only, without changing an existing Sendmail installation

Sendmail installation
● Replace Sendmail altogether
You might choose the first of these if your primary motivation is to improve the performance
of bulk mailing. This gives you a way to experiment and quantify the speed-up, while leaving
everything you've already configured to handle incoming e-mail in place and unaltered.
Postfix seems to be less scary to manage than Sendmail. Customizing or even configuring
Sendmail always feels like a big deal; on the other hand, Postfix is quite a bit easier to

experiment with because you can test just one thing at a time. Venema, for example, recently
added a "debugging" feature suggested by Bennett Todd, a Unix systems and security analyst
working on Wall Street: a "soft_bounce" selection to ensure that, even in the case of
misconfiguration, messages are not erroneously returned to their senders.
Our speed tests were equivocal: While Postfix consistently was zippier for us, the results were
so sensitive to configuration that anyone with serious performance requirements will need and
want to run his or her own tests. For the light loads the majority of hosts typically experience,
performance enhancements can be invisible. With very high traffic levels, though, whether
inbound or outbound, Postfix (and such alternatives as qmail and Post.Office) handles a
multiple of Sendmail's limits.
Both Sendmail's and Postfix's current releases run about 50,000 lines of source code. Postfix
has six times as many source files and they average, of course, only about a sixth the size of
Sendmail sources. That's the sort of thing that contributes to Postfix's approachability. It's much
easier to localize changes, problems, and opportunities in Postfix's sources.
Choosing an MTA
Should you stay with Sendmail? Try Postfix? Test-drive a commercial alternative? Here are the
main elements we consider when deciding between these possibilities:
Sendmail has it all. If you need features, Sendmail is likely to be the place they first appear and
are exercised the most. Sendmail has at least an order of magnitude more source-code hackers
than any of the other MTAs. Most Unix boxes ship with Sendmail. Sendmail's the easy choice
for most system administrators.
If you're using Sendmail, though, you have a professional responsibility to update it to a current
release. The security hazards of running an older version (some major Unix vendors still ship
Sendmail 5.65!) are simply unacceptable.
It takes less than an hour to do a basic installation of Postfix. If you inherit a complicated and
undocumented Sendmail.cf configuration, you might be tweaking your Postfix tables for a
while; Postfix does not support Sendmail.cf. Postfix's address-rewriting tables are easy enough
to use, though, so that even starting from scratch shouldn't take you all day. What you have
after such an investment is a far safer MTA that will probably perform much better.
Anyone considering Postfix should also know about qmail -- a more mature open source
project that occupies almost exactly the same niche as Postfix. Its security and performance are
very good, and it's had a couple more years to ripen than Postfix. It has about the same set of
features as Postfix, plus a clever built-in "aliasing" scheme that simplifies mailing list
management. Postfix's configuration files are fewer and perhaps more readable than qmail's;

choosing between their approaches seems to be a matter of personal taste. Venema and qmail's
inventor, Daniel J. Bernstein, have such strong personalities that some users decide between
their products based on compatibility with their authors. Also, note that the qmail license is an
unusual one. While Bernstein has liberalized it again recently, it generally has been more
restrictive than the licenses for many other open source products in that it restricts developers
from modifying the core of qmail or distributing binary images. This has been a predictably
contentious topic throughout qmail's history. On one side, Bernstein doesn't want people to
degrade qmail's security, even if inadvertently, and give his product a bad name. But then
proponents of license liberalization argue that the license is a practical inconvenience that
decreases the usefulness of qmail.
You're probably running Sendmail now, and all you need to do is pick up the latest release for
its tighter security and antispamming features. But do tens of thousands of people look to you
when they have e-mail problems? Is your domain a prominent one that might attract crackers?
Has your uptime been floating higher? In such cases, it's time you at least begin to experiment
with Postfix (or qmail, or one of the higher-end commercial products), which will give you
superior performance and security to Sendmail with all the reliability that the latter has gained
during two decades of refinement.
Finally, if you select or are leaning toward Postfix, strongly consider subscribing to the postfix-
announce, postfix-users, and/or postfix-testers mailing lists. The latter, in particular, is where
the design of new features is properly discussed. The Postfix home pages supplies more
information about these mailing lists.
The Mailman arrives

Another open source product released to beta just this winter is Mailman, the GNU Mailing
List Manager.
The market for

mailing list
management systems
(MLMSs) is
reminiscent of that for
MTAs: While a
plethora of products is
available, Majordomo
is freely available and
has led the pack in
popularity for many
years. But also like
Sendmail, Majordomo
now seems clumsy

and difficult to
manage.
Mailman has been

designed for a
Webified world. All
actions -- subscription
requests, list
administration,
management reports --
can be performed
either through a Web
interface or more
traditional textual
commands. Moreover,
Mailman integrates archiving, digests, Usenet gateways, spam protection, and bulk mailing.
Improved customization and filtering are planned after the first official release.
One reassuring aspect of Postfix and Mailman is that their creators use them. Venema has
depended on Postfix as the only MTA on his own node for over a year, while Ken Manheimer,
John Viega, Scott Cotton, and Barry Warsaw developed Mailman largely as an extension of
their own needs for more convenient and higher performing mailing list management than
other products afford. Among other responsibilities, Mailman keeps the mailing lists of all
python.org activities, including the Python Special Interest Groups (Python SIGs), straight.
Performance primary
Warsaw, a system engineer at the Corporation for National Research Initiatives, told us,
"Performance was primary. We used Majordomo before, and when a lot of messages came
through, they just bogged the machine down. We're really happy with how Mailman's working
out." The migration from Majordomo has been easy: "It took five minutes to convert three
mailing lists, purely through the Web interface."
According to Warsaw, Mailman is coded in approximately 13,000 lines of Python code, along
with 600 lines of C which wrap security facilities. Mailman exposes Python as an extension
language that allows for customization of Mailman's interfaces.
Mailman further resembles Postfix in having a robust and swift generation. Warning: As a
practical matter, you'll need root access on your host to configure Mailman properly. Most
open source products can be generated and initially tested by ordinary Unix users. Some
organizations have a policy that requires this. With Mailman, though, you'll at least need to
create a new account and group (the default for both is "mailman") for Mailman's use.

The distributions for both Postfix and Mailman have clearly written README files that point
to details on licensing, installation procedures, and known problems. Be careful. Sometimes the
documentation lags the application. There have been a few cases where a fix appeared in a
release, but the documentation didn't catch up until later. In the worst case, this means that
something works, but you can only scrutinize further by reading source or experimenting with
the installation in getting Mailman to work in other environments.
Warsaw needs only a few words to explain his judgment of Mailman's progress: "I'm biased,
but I really see no reason to use Majordomo now. Mailman's performance is that much better, it
has more features, and it's just as reliable." He's working on making the conversion from one to
the other just as simple. While migrating a Majordomo mailing list into Mailman is
straightforward now, Warsaw intends to document and further automate it after the 1.0 release.
The final milestone before the Free Software Foundation releases Mailman as an official
product is resolution of a couple of faults reported on Linux file systems that Mailman's core
development team haven't yet reproduced.
Summary
The software you're already using to handle your e-mail requirements probably works reliably.
However, the scale of your operations is likely growing, while security threats become more
difficult, and your users' demands for convenience expand. It might be time for you to move to
a new technology -- one better suited to modern needs. Several of the best e-mail products are
open source. In particular, you can easily install Postfix and Mailman, and test their
performance in realistic settings. Postfix and Mailman already have healthy user communities.
You can have confidence that Postfix and Mailman will be fresh and well-supported for years
to come.
Thanks to Bennett Todd for his candid discussions of MTAs.
About the author

Cameron Laird and Kathryn Soraiz manage their own software consultancy, Network
Engineered Solutions, from just outside Houston, TX. They write SunWorld's bi-weekly
Regular Expressions column.
Home | Mail this Story | Comment on this Story | Resources and Related Links
Also this month in SunWorld Go

Advertisement: Support SunWorld, click here!
Resources and Related Links

● Sendmail Consortium
http://www.sendmail.org/
● Sendmail Inc.
http://www.sendmail.com/
● The Postfix home page
http://www.postfix.org/
● MTA survey
ftp://koobera.math.uic.edu/www/surveys/smtpsoftware3.txt
● "The original 'killer app'" (a LinuxWorld-Tapping the Source feature on qmail)
http://www.linuxworld.com/linuxworld/expo/lw-email.html
● The Open Source page
http://www.opensource.org
● Mailman home page
http://www.list.org/
● The GNU Project and the Free Software Foundation
http://www.gnu.org
● Wietse Venema's tools
ftp://ftp.porcupine.org/pub/security/index.html
● "Report from SANS '98: Why Wietse Venema says Sendmail can never be made
secure" July 1998 Security column in SunWorld

http://www.sunworld.com/swol-07-1998/swol-07-security.html
● Majordomo FAQ
http://www.greatcircle.com/majordomo/FAQ.html
● Cameron Laird's personal notes on Python
http://starbase.neosoft.com/~claird/comp.lang.python/python.html
Other SunWorld resources
● The SunWorld Topical Index -- a comprehensive listing of all SunWorld articles by

subject
http://www.sunworld.com/common/swol-siteindex.html
● sunWHERE -- launchpad to hundreds of online resources for Sun users
http://www.sunworld.com/sunwhere.html

● Back issues of SunWorld

http://www.sunworld.com/common/swol-backissues.html
● IDG.net, your one-stop IT resource
http://www.idg.net
Tell Us What You Thought of This Story
-Very worth reading -Too long -Too technical

-Worth reading -Just right -Just right
-Not worth reading -Too short -Not technical enough
Comments:
Name:
Email:
Company Name: Send data
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-03-1999/swol-03-mailtools.html
Last modified: Thursday, March 30, 2000

SecurityPortal - Kurt's Closet: Postfix - the Sendmail replacement
Jun 03, 2001 About Us Advertise Feedback
SUBSCRIBE to our
Weekly Newsletters
Hot Topics!
IIS
Sulfnbk.exe
HEADLINES
Personal
Firewalls Kurt's Closet: Postfix - the Sendmail IWON:
NetWolves Says
Lopez Worm
replacement GE To Use Its
Services Internet
NetRadarEWS Security System
InfoSecU
Newsbytes:
Top News SETI At Home
September 15, 1999 – Most, if not all the readers of this column run a mail
All News server, and more then likely it is running Sendmail. In all fairness Sendmail is Servers
Linux a damn good MTA (Mail Transfer Agent), Eric Allman originally wrote it with Invaded, Users
Microsoft one main goal in mind: the mail must get through. Unfortunately, when Spammed
Virus Sendmail was originally written security wasn't a major concern on the Boston Internet:
Press Releases Internet and it shows. Sendmail runs almost exclusively as the root user on RSA Security
Features most systems, meaning any flaws are potentially very serious. In addition to Opens Ireland
Ask Buffy this Sendmail isn't very good at handling high loads. New mailers, such as Plant
K-Files Postfix, Zmailer, and Qmail are several times faster then Sendmail on the
Slashdot:
Kurt's Closet same hardware. Until recently most of the alternative mailers to Sendmail
OpenBSD 2.9
Top 20 Virus were not drop-in replacements, to replace Sendmail was a painful task, and
Released
Archives the new software typically behaved differently then Sendmail. Postfix was
designed from the start to address all these problems. CNET: Central
Centers Command
Firewalls Releases Its
Security
Virus/Malware Dirty Dozen --
Security 101 Top 12 --
Careers
Postfix does not run exclusively as root, instead a master program (called
Viruses For May
Community
"master") runs as root and spawns off processes to handle incoming,
2001
eForensics
outgoing and local mail delivery as needed. Using a series of modular
Networking
components, each task is handled by a separate program (which makes More News
Crypto/PKI
auditing it easier), for example outgoing email is dumped into the queue
Vendors
directory by your software, where "pickup" gets it and hands it to "cleanup", Send
Microsoft
which hands it to "trivial-rewrite" which handles the headers, and finally is
Feedback
Macintosh
given to "smtp" if bound for a foreign system. Postfix is also much easier to
More...
setup for a chroot'ed environment than Sendmail is, simply make a few edits
to the master.cf file (typically in /etc/postfix) and Postfix will run chroot'ed in
Weekly Digests its defined queue directory (usually /var/spool/postfix). It is also possible to
BSD set process limits for individual portions of postfix, again in the master.cf file.
Careers You can also easily set which user the Postfix programs run as, typically it
Check Point defaults to "postfix" (a user similar in concept to the "nobody" user for
Executive apache), which has access to certain queue directories. Another major benefit
Linux of Postfix is the clarity of the configuration files, if you haven't yet looked at
Microsoft the guts of a sendmail.cf file I would recommend that you don't (O'Reilly has
PGP an 800 page book on Sendmail).
Raptor
Solaris
The master.cf file:
Tools
Virus # ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
CryptoArchive # ==========================================================================
smtp inet n - n - - smtpd
Discussion Forum pickup fifo n n n 60 1 pickup
cleanup unix - - n - 0 cleanup
Get SecurityPortal qmgr fifo n - n 300 1 qmgr
rewrite unix - - n - - trivial-rewrite
To Go
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
smtp unix - - n - - smtp
showq unix n - n - - showq
http://www.subneural.net/postfix-master/securityportal.199909/closet19990915.html (1 of 3)01/16/2005 15:48:02

error unix - - n - - error

local unix - n n - - local
cyrus unix - n n - - pipe
flag=R user=cyrus argv=/usr/cyrus/bin/deliver -e -q -m ${extension} ${user}
uucp unix - n n - - pipe
flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail unix - n n - - pipe
flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
Replacing Sendmail
As stated before, replacing Sendmail with another MTA used to be a very

painful task, many mailers approached the "problems" in Sendmail by doing
things quite differently and require a pretty extensive overhaul of the mail
system, and a very different set of configuration files. With Postfix you can
use most of your existing configuration files (such as access, aliases,
virtusertable, etc.) simply by defining them appropriately in the main.cf file.
In addition to this Postfix behaves like Sendmail, you can invoke it using
"sendmail", get a listing of the mailq with "mailq", feed it pretty much the
same options and so forth. I find a typical Postfix conversion takes around 10
minutes for most sites (assuming you use an RPM and don't have to compile
it), and have yet to encounter any major disasters (although I have found
several small to medium sized glitches).
New problems
Of course replacing one software package with another will solve certain
problems, and create new ones, to which Postfix is no exception. Partly due
to it's design as a secure MTA you may experience some minor problems with
Postfix. The best example is email to root, Postfix, by default, does not like to
deliver email with elevated privileges (necessary to send email to root
typically). You will need to define an alias for root in the aliases file, such as:
"root: someuser". This also leads to problems with several mailing list
packages, especially SmartList, which by default does all sorts of funky things
that Postfix will not stand for. In any case I would advise switching to
Majordomo, it is easier to configure and maintain via email for owners of
mailing lists.
Scalability
A major issue with Sendmail is scalability, and performance in general. Small

things such as restarting Sendmail on a daily basis so that you can update
config files automatically (for example email redirection for virtual hosting) is
problematic. Sendmail spawns off processes to receive and send email which
sometimes linger until delivery is accomplished before Sendmail exits,
meaning your script may not restart Sendmail properly. With postfix you
simply issue the command "postfix reload" and postfix reloads it configuration
files. This raises another issue, sites are starting to handle email for 10's of
thousands of users on a single server, and using flat text files for
configuration details such as mapping outgoing user email addresses (to
make bob appear as from sales@example.org for example). This file could
become several hundred thousand lines long in the future and slow the
system down. Postfix can however be integrated with a database backend
(currently MySQL is supported) to host it's configuration files, which not only
scales better but allows you to do things such as dynamically blocking email
to and from certain sites, and allow users to administrate their own accounts
more easily (a database beats a flat file any day).
Licensing
The IBM Open Source License is surprisingly liberal. Previous versions had a
rather ugly termination clause, which prevented wide spread acceptance of
Postfix, however this has been removed and Postfix is now "safe" to use. You
can distribute the software, develop it, make changes and so forth, the only
catch being that you must contribute any changes back to IBM (rather
reasonable since they paid Wietse to develop it).

Qmail
Some of you are probably wondering why I haven't mentioned Qmail yet, or
written an article "Qmail - the Sendmail replacement". I have tested Qmail,
and used it for a while, in general I found (and several sites I communicated
with, one being a large Linux vendor) Qmail to be very painful to configure
and maintain. In addition to this the Qmail license is very unclear, and
doesn't even ship with the software. To quote the author: "If you want to
distribute modified versions of qmail (including ports, no matter how minor
the changes are) you'll have to get my approval." This and other issues have
hindered Qmail's acceptance.
Kurt Seifried is a security analyst and the author of the "Linux Administrators
Security Guide", a source of natural fiber and Linux security, part of a
complete breakfast.
Related links:
Postfix:
Binary distributions of Postfix:

ftp://contrib.redhat.com/contrib/libc6/i386/
ftp://ftp.debian.org/pub/debian/dists/potato/main/binary-i386/mail/
ftp://ftp.suse.com/pub/suse/i386/6.2/suse/n1/
Other Sendmail alternatives:

http://www.zmailer.org/ (GPL)
http://www.qmail.org/ (license is unclear)
http://www.sendmail.com/ (commercial)
http://netwinsite.com/dmail_first.htm (Commercial)
Home | Search | Feedback | Privacy Policy | Advertise | About SecurityPortal

© Copyright 1999-2001 AtomicTangerine, Inc. All rights reserved.

SecurityPortal - Postfix - The Sendmail replacement part II
Jun 03, 2001 About Us Advertise Feedback
SUBSCRIBE to our
Weekly Newsletters
Hot Topics!
IIS
Sulfnbk.exe
HEADLINES
Personal
Firewalls Postfix - The Sendmail Replacement, IWON:
NetWolves Says
Lopez Worm
Part II GE To Use Its
Services Internet
NetRadarEWS Security System
By Kurt Seifried (seifried@securityportal.com) for SecurityPortal
InfoSecU
Newsbytes:
Top News SETI At Home
Kurt's Closet Archive
All News Servers
Linux Invaded, Users
Microsoft Spammed
Virus
Boston Internet:
Press Releases
RSA Security
Features Opens Ireland
Ask Buffy Plant
November 22, 2000 -
K-Files Subscribe to get FREE security
I've written about Postfix Slashdot:
Kurt's Closet news, commentary, and articles.
before, over a year ago, OpenBSD 2.9
Top 20 Virus and since then it has Released
Archives gotten even better. I (email address) Go
CNET: Central
Centers must confess that I've Command
Firewalls been using the 31 Dec. Releases Its
Virus/Malware 1999 release on my servers until last week, which, while Dirty Dozen --
Security 101 extremely stable, lacks a lot of the features now available in Top 12 --
Careers current snapshots of Postfix. Postfix is now more useful than ever Viruses For May
Community as a gateway mail server. I'll cover some of the more interesting 2001
eForensics available features and how you can use them to secure and
protect your email infrastructure. Most of these features are More News
Networking
Crypto/PKI actually quite old, but are probably news to most users.
Vendors Send
Microsoft This article was written using Postfix snapshot 20001030. Since Feedback
Macintosh then several things (like virtual) have changed, making some
More... points in this article incorrect.
Weekly Digests Print this
BSD Article
Careers Check_recipient_access
Check Point
Executive This is probably the best way of restricting incoming email to valid
Linux email accounts only. Let's assume you have a decent-sized
Microsoft corporate LAN based on Windows and are using Exchange server
PGP for email. Exchange can only validate incoming email based on the
Raptor domain, not the user, and since it will attempt to deliver the email
Solaris for 48 hours, your system can get quickly clogged up - with no
Tools easy way to clean it out. Place your Exchange server behind a
Virus firewall so no one on the Internet can connect to it directly, and
then place a Postfix server on the public side. Add this to your
main.cf:
CryptoArchive
Discussion Forum smtpd_sender_restrictions = check_recipient_access
hash:/etc/postfix/access-inbound

Get SecurityPortal
To Go Then in your /etc/postfix/access-inbound file, simply put,
validuser@example.org OK
example.org REJECT
You will also need to create the hash file. The following command
will do so:
postmap /etc/postfix/access
You could also use the generic access file, but splitting it up allows
for extremely selective access controls. You can then have the
mail delivered locally or forwarded to another (internal) system. If
an email is sent to an email address not listed specifically, and the
domain is covered by a reject rule, the sender will receive an
email with an error like,
The Postfix program

<useraccount@stench.seifried.org>:
host stench.seifried.org[10.3.0.10] said: 554
<useraccount@stench.seifried.org>:
Recipient address rejected: Access denied
You can also specify a custom error such as "useraccount does not
exist." However, a spammer could theoretically use this to build an
address list by simply testing all the email addresses - those that
generate an error message do not exist, and those that do not
generate one do exist.
Virtual
This feature can be used as intended, for having virtual users (i.e.,
if you handle multiple domains and more than one wants a
webmaster@ email address) as well as for protecting internal
servers.
virtual_maps = hash:/etc/postfix/virtual
Then in your /etc/postfix/virtual simply remap email:
userbob@example.org userbob@internal-mail.example.org
userbo@example.org userbo@internal-mail.example.org
userbill@example.org userbill@internal-mail.example.org
@example.org bounce-local
You will also need to create the hash file:
postmap /etc/postfix/virtual
If incoming email does not match a virtual user, mapping it is sent

to another address, in this example a local user called "bounce-
local." It may then be blackholed to /dev/null, simply bounced (no
such user), or sent to an admin email account - where it is deleted
or forwarded to the correct person, if an obvious typo was made in
the address, or whatever. You can also use a database backend
instead of a hash or dbm file. This is definitely the way to go for
large installations. See man virtual(5) for more information.
Simply use the same machine as the outbound mail server (i.e.,

smart host) and it will rewrite the email addresses outgoing from
@internal-mail.example.org to @example.org (or whatever you
want).
Local_recipient_maps
This keyword lets you allow only local delivery of email to valid
users and/or definitions in the aliases map. Thus any email bound
for a nonexistent user gets bounced immediately with an error
message saying the user does not exist. This is useful if you the
postmaster do not want to receive as many error messages.
Potentially, however, an attacker could use this to find valid
names (anything valid won't generate an error). This is probably
most useful for large installations such as ISPs and large
corporations. An additional consideration would be to use
relocated_maps. Simply put this in your main.cf:
local_recipient_maps = $alias_maps unix:passwd.byname
This will accept any email defined in aliases or for user accounts in
the password database.
Relocated_maps
This is an ideal feature for large companies that want to remap

users without too much trouble. It allows you to specify the
original email address and the new email address. For example,
user joebob goes to another ISP instead of forwarding all their
mail, which results in senders not realizing it has changed. They
get an error message specifying the new email address. This can
be used for wholesale domain moves as well. Simply add the
following to your main.cf:
Then put the email address, username or domain name, followed

by the email address or domain name, and anyone sending email
in will get a nice error telling them the new address. See man
relocated(5) for more information.
Blocking Spam
This is probably one of the favorite features for administrators;

under Postfix it is trivial to implement. Simple add the following to
your main.cf:
maps_rbl_domains = rbl.maps.vix.com, dul.maps.vix.com
The rbl is the real-time blackhole list, basically a list of known

spammers and open relays that spammers use. The dul is the
dialup list. Generally speaking, you shouldn't be receiving to much
email directly from dialup users, i.e., people using their own
servers. However, quite a few legitimate users do set up their own
email servers for use on dialup links, and blocking them
inadvertently may be a problem.

Database Backends
One thing I really love about Postfix is the ability to use databases
instead of flat text files or hash and dbm files. Currently only
MySQL is supported, but that is more than sufficient for most
users. You must first compile in support for MySQL. See the
"MYSQL_README" file for more information on this. Then you
simply create a table in the MySQL database of usernames, virtual
mappings or whatever. The cool thing is, this allows for very
efficient sharing of configuration files between servers; and since
you can specify multiple MySQL servers, you can replicate the
database and avoid a single point of failure as well as being able
to vary the order the databases are listed in on various servers, as
a simplistic form of load balancing.
MySQL has plans to add database replication to its available

features. For now, you will have to create your own solution, such
as a simple tool that connects to and updates all the databases at
once. The configuration is reasonably simple. In your main.cf, put
something like,
alias_maps = mysql:/etc/postfix/mysql-aliases.cf
And then in the mysql-aliases.cf, put
user = someone
table = mxaliases
where_field = alias
hosts = maildb1.example.org maildbt2.example.org
This would allow you to have a table called "mxaliases" in the

database called "customer_database," where the field "forw_addr"
matches and where the "status" field is set to "paid" (so you can
easily block email to customers who don't fork over). The really
useful thing is that you can easily update configuration files on the
fly. As soon as it is updated in the database, it's ready to go.
Additionally, this makes giving users control over their own
accounts much easier. A Web hosting provider could easily let
people handle virtual user mappings on their own domain, for
example, through a cgi interface.
TLS
Transport Layer Security is to email as SSL is to Web browsing.

TLS allows you to encrypt email transfers from server to server,
but more importantly, it allows you to add authentication to the
mail server. Instead of having to allow access based on IP and
hostname, you can use usernames and passwords. That way
people can connect securely from off-site - while using dialup on
the road - and spammers are not able to use you as a relay.
There is an add-on TLS package for Postfix (see URL at bottom)

available from Germany. (Germany is very pro-encryption; the
federal government has even gone so far as to sponsor GnuPG

development.) TLS is becoming more common now that the RSA

patent has expired. Red Hat 7.0 ships Sendmail configured for TLS
out of the box.
Regular Expressions
Postfix supports the use of regular expressions for header

rewriting and other neat tricks. There's support for basic regex
(regexp), and support for perl-compatible regular expressions
(PCRE). The first are simpler. To use them, just put this in your
main.cf:
header_checks = regexp:/etc/postfix/header-checks
And then add rules to your header-checks file; the target can be
REJECT, OK or a custom error.
/^Subject: Make money fast/ REJECT

/^X-Mailer: Microsoft Outlook Express/ REJECT
See man regexp_table(5) for more information. You can also use
PCRE by simply specifying pcre: instead of regexp: in your main.
cf. The rules are basically the same, except that the syntax used
for pattern matching is a bit more advanced.
/^friend@(?!my.domain).*$/ 550 Stick this in your pipe $0
See man pcre_table(5) for more information.
Summary
Postfix is ideal for large installations, with its database backends

and extremely tight control of mail delivery. Additionally, it
supports numerous security features, such as TLS and even the
ability to specify which users are allowed to send mail off-site and
which aren't - again, in a very selective manner. Qmail has quite a
few of these features, but has one significant problem: The license
makes it extremely difficult to distribute in a binary format, which
is what most people want.
Postfix, on the other hand, comes under the IBM Public License,
which is surprisingly considerate to end users. My real favorite is
the simplicity of configuration. An average main.cf is under 30
lines of configuration directives. Hopefully more vendors will start
shipping Postfix with their distributions.
Related Links
FAQ and other information pages

TLS for Postfix

http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/

Postfix RPMs and SRPMs

http://www.pobox.com/~sjmudd/postfix/
Home | Search | Feedback | Privacy Policy | Advertise | About SecurityPortal

© Copyright 1999-2001 AtomicTangerine, Inc. All rights reserved.

Venema aims to make network software safe
Click here to visit our sponsor
Directories -
Downloads
The Journal
IT Focus
Tech Focus
Tech Workshop Search
Profiles
Users' Choice October 2, 1998
Departments Venema aims to make network software safe
About the Journal
What's Cool:
News Central by Cameron Laird John Law vs.
Training Center the virus
Discussions "It's a lot more work than I expected." -- Wietse Venema
Ask the Experts
What's New:
E-mail is so mature an Internet application that it now almost
Job Bank DHTML
doesn't seem like "technology"; it's just an expectation of late
Calendar Behaviors
Twentieth Century life, like clean water or falling gasoline
Search Central directory
prices. It hasn't become easy yet, though, for people like IBM
Books for Sale research staff member Wietse Venema, who's in the middle of a
project "to build a mail system that does not screw up your What's Hot:
Classifieds
machine," called VMailer. FREE trial
About us
subscription to
Venema's a good man for the job. He's ITKnowledge
worked for over a decade on a broad
range of "software whose existence you
don't notice because it works well":
Journal by E-mail: network security, inter-company
your e-mail financial transactions, terminal
emulation, and so on. "My software
Subscribe rarely fails ... My claim to fame is
Get the weekly e- largely based on the low incidence of error" in the infrastructural
mail highlights from applications he's written. Now he's moved permanently to the
the most popular "beautiful landscape" of central New York state from his native
online Journal for Netherlands to dedicate a year to VMailer.
developers!
Current issue
How e-mail moves
When you send a letter through e-mail to someone down the

street or on the other side of the globe, dozens of distinct
operations are typically involved: "Electronic mail is one of the
most complex applications. It's a network server, because it
receives mail from the network; it's a network client, because it
http://www.subneural.net/postfix-master/developer.199810.html (1 of 5)01/16/2005 15:48:06

EarthWeb Sites: delivers mail through the network; it's a queue management
system, because sometimes mail can't be delivered right away;
it's a database management system, because it must deal with
multi-user access to the mailbox store. And of course, it has to be
DATAMATION safe, fast and secure, and easy to administer."
DEVELOPER.COM
DICE
EARTHWEB DIRECT
When things work right, you aren't aware of all these
GAMELAN complexities. You see only the so-called "user agent" on your
HTML GOODIES own machine, that manages communications with all the other
INTRANET JOURNAL pieces. You might have heard, though, of one of the most widely
ITKNOWLEDGE used of these other pieces: sendmail. It is an open-source
ITLIBRARY application originally written by Eric Allman in 1980 while a
JARS student. sendmail is the "transfer agent" in use on the
JAVA GOODIES
overwhelming majority of Internet servers; its job is to pass
JAVASCRIPTS.COM
ROADCODERS
letters along from one machine to another, until they arrive at
Y2KINFO their final destination.
sendmail is a resounding success; it has delivered trillions of

messages in the last two decades, and the Sendmail Consortium
and Sendmail, Inc. co-operate well to maintain and enhance it.
It's also notoriously complex and subject to cracking. That's
where Venema comes in.
The VMailer alternative
VMailer is Venema's alternative to sendmail. "VMailer attempts

to be fast, easy to administer, and hopefully secure, while at the
same time being sendmail compatible enough to not upset your
users." Venema's aim is that Internet servers will soon begin to
switch over from sendmail to VMailer. End-users shouldn't
notice this when it happens, apart from small improvements in
reliability and speed of delivery.
It'll be a big change for system administrators, though. Sendmail

is written as a monolithic program, with an exceedingly terse
configuration language ("R$* <@$+.uucp> $* $: $1
<@ $(U $2.uucp $) >$3" is typical). VMailer is a
collection of small, relatively simple, secure, swift programs,
which work together to do the job sendmail now does. "The
reason for making VMailer distributed was to get better
insulation between different parts of the system. ... Monolithic
programs have poor damage control. ... As with Titanic, a
compartmentalized architecture does not make the system
immune against disaster, but it won't fail as easily as a system
that isn't compartmentalized."
The VMailer "teammates" are fast. "With a [US] $3,000 desktop

PC, VMailer can receive and deliver a million different messages
per day." They're safe -- they respond intelligently when loaded

heavily or attacked. And they're compatible with existing work;

Venema has designed VMailer so it can replace a working
sendmail installation without wasted motion.
The price for VMailer is also right. To encourage the widest

possible dissemination, Venema doesn't charge for VMailer.
IBM Research has supported him in this, he says, because the
attitude it has communicated to him is, "if you don't give it away,
you might as well throw it away."
VMailer's prospects
So when will you begin to use VMailer? If you've traded letters

with Venema this year, or are on one of the specialty mailing
lists he manages, you already have: "In December 1997 I turned
off sendmail, forever, on all my machines." VMailer handles
everything to and from porcupine.org (the name is an insider
joke: "Europe is a collection of countries each with their own
regulations. Making progress in Europe reminds me of
porcupines making love. Auch! Sorry! Look out!"). Alpha tests
with a small group of trusted colleagues began a month later.
Beta release will be public, and he hopes it'll be in just a few
weeks, during November 1998.
Understand that Venema uses those words differently from

several commercial vendors. Public beta for VMailer means
"people expect that my programs solve more problems than they
cause. [It's] something close to perfection. ... I am preparing an
incomplete system for release [to experimentally determine
people's needs]. That's why I call it a beta. It has nothing to do
with software quality."
Life after and before VMailer
Once VMailer meets Venema's goals, he'll turn it over to a

maintenance group and move on to other work. "My next project
is porting tcp wrappers to IP version 6, the next generation of
Internet protocols; vendors have gotten ahead of me already,
which is an embarassment for me."
Before VMailer, Venema was probably best known for his work
with the Security Administrator Tool for Analyzing Networks
(SATAN). SATAN probes machines connected to the Net and
reports on problems or weaknesses it finds. This is a great
convenience for system administrators responsible for securing
these machines; it gives them a nicely formatted, thorough
explanation of the deficiencies they need to address. As with all
the tools Venema writes, "I have given away the programs ... so
that other people can inspect and use them, too."

SATAN has attracted a bit of controversy during its life. A few

commentators mislabeled it as a tool for breaking into sites. In
any case, "[m]ost people know me from my software to protect
systems against Internet intruders." That kind of high profile
attracts crackers, who treat break-ins to prominent sites as a
competitive sport. In the case of Venema's domain, though, the
most accomplished and dangerous intruders "know that for many
years, my Internet gateway has been logging every network
packet to disk. It's good insurance."
Away from the keyboard, Venema and his wife Annita are
looking forward to replacing the bicycles they sold when they
moved. This will give them a chance to explore the North
Country Trailway, which runs near their new home. "This is
continent collision zone, with lots of weird geology. It's quite a
change from the Netherlands, which is all flat and which has
almost no trees."
Links on this story
● IBM Research
● Wietse Venema's home page
● Venema's VMailer Project
● Sendmail Consortium
● Sendmail, Inc.
● tcp wrappers BLURB
● SATAN
Cameron Laird has written several other articles for developer.

com. You can reach him at claird@neosoft.com.
ANNOUNCEMENTS
Keep your tech team up to speed with a corporate subscription to
ITKnowledge, the largest and fastest growing online technical
reference library.
For tons of Windows technology resources, check out win.
developer.com.
WIN a 15" Flat Screen LCD Monitor with Built-In Speakers from
EarthWeb Direct!
Prentice Hall co-authors of Java Design Pete Coad, Mark Mayfield,
and Jon Kern are talking in our new forum. Join them!

Use of this site is subject to certain Terms & Conditions.

Earthweb's statement regarding our users' right to privacy.
Copyright ©1996-1999 EarthWeb Inc. All rights reserved. Reproduction in whole
or in part in any form or medium without express written permission of EarthWeb
is prohibited.
The preeminent online programmers journal and resource for software developers, programmers, web
builders and information technology professionals working on software development, web building,
programming and need programmers news and updates.

sendmail.net:
home search about us site map policies
topics home > q&a: wietse venema talkback

using sendmail comp.mail.sendmail
interviews newsgroup
articles
Q&A: Wietse Venema (via Google)
conferences
When you name a program SATAN, you can expect your comments? ideas?
give us feedback
sites intentions to be misread. Wietse Venema discovered this
sendmail, inc. firsthand when he and colleague Dan Farmer released the
our commercial Security Administrator Tool for Analyzing Networks, store
products and reporting software designed to let administrators test their buy the knife
services own networks for vulnerabilities, but immediately buy the t-shirt
sendmail.org misconstrued as a toy for budding crackers.
the sendmail
consortium site There's little chance that mistake will be repeated.
Venema's name has become synonymous with security in
the minds of sysadmins worldwide, thanks to his work on
SATAN, TCP Wrappers, and a host of other tools to keep
the scriptkiddies at bay. This work hasn't gone unnoticed:
at the LISA '99 conference last November, Venema
received the SAGE Outstanding Achievement Award, an
honor previously bestowed upon the likes of Paul Vixie
and Larry Wall.
The other thing Venema's famous for, of course, is

Postfix, the mail transfer agent he wrote after coming to
IBM's Thomas J. Watson Research Center from the
Netherlands. Known briefly by the name "VMailer,"
Postfix aims to be "fast, easy to configure, and hopefully
secure." We spoke with Venema by phone about Postfix,
security, and the superiority of asynchronous
communication - i.e., email.
mark durham
17 april 2000
http://www.subneural.net/postfix-master/sendmail.200004/interviewvenema.html (1 of 7)01/16/2005 15:48:07

sendmail.net:
Let's start with a question about Postfix. What are your plans for incorporating encryption? I'm
thinking specifically of Transport Layer Security (TLS) and SMTP authentication.
Hopefully those will be in the next official release. I've received several donated pieces of software
from people who use my Postfix program, and who have added things like authentication and
encryption. I'm in the process of merging that donated code into my software.
Do you foresee any legal issues with open sourcing that technology once it's been integrated?
There's no longer an issue in doing this from the United States, because as of January 15, it's legal to
export open source code with encryption functions. You only have to send a notice to the Bureau of
Export Administration.
Do you have any particular plans for September 20, the day the RSA patent runs out?
[laughs] Well, it expires several times, doesn't it? I think the US and Canadian expiration dates are
different.
I have no specific plans with respect to RSA. In any case, the encryption would not be shipped with
Postfix. All I would provide is a version of Postfix where you can throw in the encryption source code.
I don't think it makes sense to put a copy of all the SSL and related stuff inside of Postfix.
Just in terms of code bloat and efficiency?
Exactly. And if somebody else fixes a problem in SSL, then I won't have more work to do. [laughs]
You seem to have plenty to do as it is. What projects are you working on right now besides
Postfix? Last I heard, you were porting TCP Wrappers to IPv6. Is that done already?
No, that still needs to be done.
How's it going?
Slowly. It's a problem, because by now lots of vendors are shipping systems with IP version 6 support.
Postfix has taken a lot of my attention, and of course there are other things too, like the forensics tools
I've been working on with Dan Farmer. We gave a free, full-day class on computer forensics last
August and promised about six tools. The tools were given to the attendees as a beta release, but we
really want to finish a first public release. I was actually hoping we would do it in April.
Can you describe those tools in more detail?
In our class, we explained how to get evidence after a break-in. There are all kinds of little bits and
pieces of information that stay behind on a system when it's being used. And it's all very volatile,
because every bit on a computer will eventually be overwritten, so you have to be really careful to
recover the information or else it's gone forever. The most spectacular tools we have are for recovering

sendmail.net:
deleted files. And they turn out to work much better than we expected.
You used to say you wrote every single packet you received to disk as insurance against crackers.
Is that still true?
On my previous machine in the Netherlands, I used to do that. I'm not doing that currently, but I am in
the process of reinstalling this functionality again.
Do you consider that good policy for a heavily targeted site?
Well, that depends on how much disk you have and on the bandwidth of your network. When I
connected my own machine to the Internet a couple of years ago, I thought, "Well, maybe some people
will attack me. How will I find out?" One possibility was to record everything that came over my
network to a disc on a machine that no one could break into, and every now and then just look at the
logs. Even if somebody managed to break in, it would be recorded and I could still see what happened
and what the damage was.
Like running a surveillance camera in a 7-Eleven.
Well, the unfortunate thing is that nothing ever happened. So I recorded several years of "nothing
happened." [laughter] I didn't do this when I came to the US, but I'm going to do it again, just as a kind
of insurance.
Do you follow the Bugtraq list pretty closely?
I post to it infrequently, and I follow it from a distance. I don't know if you've noticed, but there are
several new vulnerabilities every week. I don't think anybody on this planet is really keeping up to date
with all these vulnerabilities. [laughs]
When we interviewed Paul Vixie some months ago, he pointed out that Internet protocols simply
were not designed to deal with malice. They were designed for civilized people who behaved in a
civilized way - friends, fellow researchers, colleagues. Do you think vulnerability is built into the
protocols of the Internet? To what extent is IPv6 successful in solving that problem?
It's very difficult to build protocols that will survive and do well in an unfriendly world. By definition,
you're trying to connect systems to each other and exchange information between them. It's really hard
to design protocols that let you connect your machine to the network and still be immune against
malice. On the other hand, it's very easy to screw up and design protocols that act as amplifiers for the
kind of attacks we've seen in the last couple of years.
What elements of the Internet protocol do you see as having specific potential to amplify attacks?
One very well-known attack is where I send one IP packet to a broadcast address on your network, and
then every machine will respond. So if you have a network with one hundred machines, all I have to do
is to send one packet and they will send one hundred packets.

sendmail.net:
So you have instant denial of service.
Yes. If I can spoof my sender address, now I can suddenly, with very little effort, make other machines
do a lot of work for me and do DOS-like attacks. You could do the same thing with application levels
in protocols. But the broadcast is a very popular example.
How about IPv6? Does it have similar vulnerabilities?
IP version 6 uses encryption and authentication - and again, it turns out to be very difficult to design
the cryptographic protocol such that a client cannot force the server into doing a lot of expensive
computations.
Which again results in denial of service?
Exactly. Encryption is computationally intensive. So by forcing responses on compute-intensive

processes, you can inflict a processor-level denial of service. The server has to do a lot of
cryptographic operations, only to find out that the client was just sending it garbage.
Do you see a way around that?
I have no solution at hand. It is a very difficult problem.
In your Bugtraq posting about the TCP data corruption problem, you mentioned that IPSEC's
limitations on traffic manipulation have provoked some controversy.
Yes, that's true. In fact, Steve Bellovin at AT&T is working on a proposal - at least, I understand he's
working on something along those lines. People do want to see some information about traffic. They
do want to do traffic analysis. If I'm a network provider, I want to know what kinds of traffic are going
over my network so I can do capacity planning. If all the traffic is totally encrypted, it's very difficult to
find out what's going on.
The problem we were dealing with in the Bugtraq posting was a bandwidth management system that
just changes a few parameters in TCP headers so that the traffic flows more smoothly. Those are things
that you simply cannot do when all the data is protected by digital signatures and such. So there are
several conflicting requirements, like people wanting to be able to see a bit more of traffic than they
would be able to see, and people actually wanting to do some management of the traffic, like
bandwidth allocation.
So there's an ease-of-administration tradeoff for the security that you get. The encryption has an
administrative cost.
Yes, the encryption makes it impossible to do certain operations. Now, from the point of view of
security, this is exactly what you want. All you want is to send your data to the other machine, and it
should be sent unchanged: no man-in-the-middle attacks by "helpful" intermediate systems. So these
are conflicting requirements.

sendmail.net:
You've been associated with IBM for a couple of years now, right? Did you come in '96, '97, '98?
Yes, yes, yes. [laughs] The answer is "yes" in all three instances. I came in 1996 as a visitor, and then I
stayed a bit longer, and then I joined IBM. So yes, the whole process extends from 1996 to the summer
of 1998.
Do you have pretty broad latitude in terms of the work you do there?
Yeah, this is research. So I have a lot of liberty.
Beyond giving you the liberty to work on it, is IBM supportive of Postfix and the other software
you produce? Do they actually help you get it out there to people? Do they help you stay in touch
with users and so on?
Well, it's pretty much up to me, I think. You have to coordinate a few things with people, but it works
fine. I can do a lot of things. [laughs] I could probably do more.
How do you see the relationship between open source development and the commercial
marketplace? Companies like Red Hat and Sendmail have married the two to create a revenue
stream that can better support open source development. Does this seem like a valid approach to
you?
It seems to make sense. I don't have much to say much on this subject, but it seems to make sense.
You've described the creation of Postfix as a response to sendmail and an attempt to create an
alternative to sendmail. What do you think about cooperation versus competition in the free
software world? Is variety a good thing?
I think it's beneficial when multiple implementations coexist. Not too many, because that confuses
people. But a number of implementations can coexist, because it gives people more choice.
What about sharing features and ideas? Eric Allman has told me on several occasions of the high
regard he has both for you personally and for your work on Postfix. Are there things that you've
learned from sendmail and implemented in Postfix? Are there things sendmail can learn from
Postfix?
The same thing happens with everybody who implements a system from the ground up. Just as Eric
Allman had to solve problems as he was building sendmail over time, I ran into several problem
instances myself and tried to solve them. And then I looked at how sendmail solved it, or how other
systems solved it. Sometimes you find your solution is better, and sometimes you find your solution is
worse. Sometimes you find a security problem in the other person's solution. All these things happen.
But the end result, of course, is that people will have better software.
So you wouldn't be offended if Eric looked at Postfix and said, "Hey, what a great idea, Wietse. I
think I'll steal it."

sendmail.net:
Not at all. I stole some ideas from qmail. And of course, I stole the user interface from sendmail. But
that was also for compatibility reasons.
I guess you have the same problem whether you're developing a new application or doing a new
version of an existing application: you have to keep from scaring users off by changing things too
fast.
Yes, and in fact, these things become a problem very quickly. Once you give your software to other
people, that's where it starts. You can no longer just totally change the software anymore, because
people have become dependent on it.
Are you planning to implement message tracking in Postfix, at least once there's a standard
protocol?
Well, if there is a standard. I really don't like to invent my own wheels. But if people need this
functionality, it will eventually be part of the mail system, yes. But you really need a standard that goes
across multiple systems. Because mail usually goes from one system via a few other systems to its final
destination, and if you want to do tracking, all these different systems need to be doing something
comparable.
As you look forward at the future of email and Internet communication generally, aside from the
obvious things - many more users and much greater security issues - what do you see as the
forces shaping the evolution of these technologies? What direction do you see email going in,
beyond simple one-to-one messaging?
I'm actually surprised that email still works so well, and works the way it does. Because it hasn't
changed fundamentally over the last couple of decades. It is still doing the same thing, I believe.
Except that it's reaching a lot more people. But the basic model hasn't changed at all.
Do you see the possibility for that model to evolve?
It's possible, but it hasn't really evolved at all. Instead, what you see is new applications coming up
and, side by side, email. There is the World Wide Web - and email has, of course, inherited some of its
features. But the basic model is still the same: I sit at my screen, I do stuff, I send it to you. You
receive my message and read it from your screen. And the two actions are completely disconnected.
That's the basic character of email. If people want realtime conversations, they have lots of choices
already.
Many people see email's asynchronous aspect as a big advantage. It gives you a rhythm of
communication that's much more appealing in certain ways.
Absolutely. I prefer email over telephone calls anytime. Not that - [laughter]
That sounds like a good note to end on.

sendmail.net:
So maybe I had a personal interest in having a reliable mail system. [laughter]
home search about us site map policies

http://www.subneural.net/postfix-master/linuxmag.200006/postfix.html
Home Info Artikel Produkte Stickers UserGroups Events Bücher

Linux-Magazin | LinuxUser | Linux-Events | Linux-Community | Perl Snapshots
Suchen:
Jetzt bestellen!
Die Software Rebellen
Jahres-CD 2000
Postfix - der Sendmail-Ersatz?
Modular und sicher

Gregor Longariva
Täglich senden weltweit über 100 Millionen Benutzer E-Mails. Erstaunlich ist, daß nach wie vor Eric Allman's betagter Sendmail der am
weitesten verbreitete Mail Transfer Agent ist. Postfix hat das Zeug, Sendmail als Standard-Mailer abzulösen.
ahezu unüberschaubar ist die Flut von Diensten, die das Internet mittlerweile bietet. Einer der wichtigsten Dienste bleibt jedoch das
N Versenden und Empfangen von Mails. Ohne Open-Source-Tools wäre das undenkbar - gerade Sendmail gehört zu den am weitesten
verbreiteten Mail Transfer Agents (MTA).
Leider ist der monolithische Sendmail alles andere als leicht zu pflegen. In solch ein "Multifunktions-Tool" schleichen sich zwangsläufig Fehler
ein - eine neue Sicherheitslücke in Sendmail gehörte in der Vergangenheit zu den Treppenwitzen der Internet-Geschichte schlechthin.
Aber auch wenn die aktuelle Version - soweit bekannt - keine großen Sicherheitsmängel aufweist: alleine die Konfiguration von Sendmail
schreit geradezu nach einer Alternativlösung. Das Standardwerk zu Sendmail, das so genannte "bat book" von Bryan Costales und Eric Allman
[3] umfaßt 1021 Seiten.
http://www.subneural.net/postfix-master/linuxmag.200006/postfix.html (1 of 13)01/16/2005 15:48:09

Die beiden am häufigsten eingesetzten (freien) Alternativen zu Sendmail sind Dan Bernsteins Qmail und Postfix von Wietse Venema. Beide
sind wie Sendmail im Quelltext frei verfügbar - Qmail unter der GPL, Postfix unter einer von der Mozilla Public License abgeleiteten Lizenz
von IBM - und beide sind einfacher zu handhaben als das altehrwürdige Sendmail.
Ursprünglich hieß das Projekt "VMailer". IBMs Rechtsanwälte haben aber herausgefunden, daß der Name zu ähnlich dem eines eingetragenen
Markenzeichens war. Wietse Venemas Antwort auf meine Frage nach dem Namen seines Mailerprojekts:
> We spent several months giving names to the program.

>
> The IBM name polizei killed every name we thought up, and so we
> decided to change tactics. The program now has TWO names:
> IBM Secure Mailer + Postfix.
Wieste's Ziel bei der Entwicklung von Postfix war, ein schnelles, einfach zu administrierendes und sicheres Programm(paket) zu entwickeln,
das so weit wie möglich zu Sendmail kompatibel sein soll. Das Interessanteste an Postfix ist sein innerer Aufbau (siehe Grafik): es besteht aus
mehreren kleinen Programmen, die über UNIX-Domain-Sockets kommunizieren. Auf diese Weise ist es viel einfacher, Probleme, Fehler oder
Sicherheitsmängel in den Griff zu bekommen. Beispielsweise kommt Postfix ganz ohne setuid-M©chanismen aus. Deshalb ist es für einen
potenziellen Angreifer unmöglich, Superuser-Rechte zu bekommen - selbst wenn er ein Sicherheitsloch von Postfix gefunden hätte. Sendmail
hingegen muß unter UID 0 (root) laufen, zumindest in einer Standardinstallation und ohne größere Klimmzüge.
Ebenfalls aus Sicherheitsgründen arbeitet Postfix mit vier verschiedenen Queues: "maildrop", "incoming", "active" und "deferred". Lokal
gesendete Mails landen in "maildrop" und werden von dort in die "incoming"-Queue kopiert, nachdem sie regelbasiert auf Größe, Inhalt und
anderes überprüft wurden. In der "active" Queue landen die Mails, die der Queue-Manager gerade bearbeitet und ausliefert (lokal oder remote).
Nachrichten, die Postfix nicht ausliefern kann (Dienst des Zielmailservers reagiert nicht, keine Route, keine Netzverbindung, ...), landen in der
"deferred" Queue. Da Postfix immer nur eine Mail gleichzeitig bearbeitet und die "active" Queue klein hält, ist es unempfindlich gegen
Ressourcenknappheit. Das Bearbeiten/Ausliefern von Mails kann also in keinem Fall, beispielsweise wegen eines vollen Dateisystems, blockiert
werden.
Modularer Aufbau von Postfix

Die Grafik zeigt den modularen Aufbau von Postfix. Hierbei bedeuten:
● gelbe Ellipsen Programme

● gelbe Kästen Mail-Queues oder -Dateien
● blaue Kästen (Nachschlage-) Tabellen
● Programme in der umrandeten Box laufen unter der Kontrolle des Postfix master Daemons.
● Dateien in diesem Kasten gehören dem Postfix-Mail-System.
Postfix bietet zudem einige Mechanismen, empfangende, möglicherweise ressourcenschwache Mailsysteme zu schützen. Der Autor bezeichnet
sein Mailsystem als "guten Nachbarn", der auch langsame Systeme nicht in Bedrängnis bringt.
Installation und Konfiguration
Postfix befindet sich derzeit immer noch in der Entwicklungsphase. So findet man auf den verschiedenen FTP-Servern verschiedene Versionen:
die offiziellen und die experimentellen Releases (Snapshots). Operative Mailsysteme sollten nur eine offizielle Release verwenden, auch wenn
die Snapshots nach Aussagen des Autors stabil laufen. Nach dem Auspacken sollte ein einfaches make genügen, um Postfix zu compilieren.
Sollte Postfix bereits vorher für ein anderes Betriebssystem übersetzt worden sein, etwa in einem heterogenen Netz mit verschiedenen Unix-

Systemen (siehe Kasten "Postfix-Plattformen"), löscht make tidy alle betriebssystemspezifischen Einstellungen.
ach dem Übersetzen folgt etwas Handarbeit. Bei Ersetzen eines bestehenden Mailsystems (etwa Sendmail), empfiehlt sich das Anlegen einer
Sicherheitskopie der bestehenden Programme. Ein Beispiel:
mv /usr/sbin/sendmail /usr/sbin/sendmail.OFF
mv /usr/bin/newaliases /usr/bin/newaliases.OFF
mv /usr/bin/mailq /usr/bin/mailq.OFF
chmod 755 /usr/sbin/sendmail.OFF /usr/bin/newaliases.OFF
/usr/bin/mailq.OFF
Da Postfix nicht als "root" laufen sollte, ist es sinnvoll, einen neuen (virtuellen) Account einzurichten - etwa mit dem Namen "postfix" und ohne
Login Shell:
Postfix verwaltet die Systemmailbox (etwa /var/ mail oder /var/spool/mail) auf zwei mögliche Arten: als systemweit schreibbares Verzeichnis,
oder mittels SGID-Bit. Welche Methode sinnvoller ist, bleibt dem Systemadministrator überlassen. Ein SGID-Bit zu vergeben, ist immer mit
Risiken verbunden. Wenn Postfix mit SETGID installiert wird, führt das Installationsskript folgendes aus:
chmod 1733 $QUEUE_DIRECTORY/maildrop

chmod g-s $COMMAND_DIRECTORY/postdrop
andernfalls (nicht setgid):
chgrp $setgid $COMMAND_DIRECTORY/postdrop

chmod g+s $COMMAND_DIRECTORY/postdrop
chgrp $setgid $QUEUE_DIRECTORY/maildrop
chmod 1730 $QUEUE_DIRECTORY/maildrop
Das Installationsskript installiert die einzelnen Postfix-Dateien und ermöglicht gleichzeitig, einige Pfade interaktiv zu setzen. Diese werden
gespeichert, um bei einer Neuinstallation nicht alles nochmal eingeben zu müssen.
Postfix-Plattformen
Postfix ist derzeit auf folgende Unix-Systemen erfolgreich getestet:
AIX 3.2.5 AIX 4.1.x AIX 4.2.0

BSD/OS 2.x BSD/OS 3.x BSD/OS 4.x

FreeBSD 2.x FreeBSD 3.x FreeBSD 4.x
HP-UX 9.x HP-UX 10.x HP-UX 11.x
IRIX 5.x IRIX 6.x Mac OS X server
Linux Debian 1.3.1 Linux Debian 2.x
Linux RedHat 4.x Linux RedHat 5.x Linux RedHat 6.x
Linux Slackware 3.5 Linux Slackware 4.0 Linux Slackware 7.0
Linux SuSE 5.x Linux SuSE 6.x NEXTSTEP 3.x
NetBSD 1.x OPENSTEP 4.x Digital UNIX V3 - 5
OpenBSD 2.x Reliant UNIX 5.x Rhapsody 5.x
SunOS 4.1.x Solaris 2.4..7 Ultrix 4.x
Nun folgt die eigentliche (Laufzeit-) Konfiguration des Postfix-Mailsystems. Die Konfigurationsdateien liegen alle in einem einzigen
Verzeichnis - in der Regel in /etc/postfix. Meistens braucht der System- oder Mailadministrator nicht viel einzustellen. Die Defaulteinstellungen
sind entsprechend gewählt, um ein einfaches Mailsystem abzudecken. Sollte die Installation ein "send-only" Mailsystem sein (etwa auf einem
Client, der über einen dedizierten Mailserver die Mails verschickt), kann Postfix einfach ohne weitere Konfigurierung gestartet werden.
Allenfalls kann man in der Datei main.cf den Eintrag "smtp" auskommentieren. So verbietet man eine Verbindung von außen per inetd/smtp auf
den Rechner.
Aber auch die Konfiguration eines "echten" Mailservers sollte keine Schwierigkeiten bereiten. Lediglich folgende Einträge in der Datei /etc/
postfix/main.cf sind bei Bedarf anzupassen, darunter in jedem Fall die eigene Domain:
myhostname = mail.softbaer.de
inet_interfaces = $myhostname
mydomain = softbaer.de
Setzt man diese Werte nicht explizit, ermittelt Postfix die Werte durch Systemaufrufe - etwa den Hostnamen durch gethostname(2). Die
Variable "myorigin" setzt den rechten Teil der Absenderadresse (longariva@MYORIGIN) der Mails. Setzt man "myorigin" nicht, setzt Postfix
den Hostname als Absenderadresse, etwa longariva@mail.softbaer.de. Meistens ist die Form longariva@softbaer.deaerwünscht. Vorausgesetzt
der MX-Eintrag im Nameserver ist richtig gesetzt, kann man dies durch

erreichen. Die Datei /etc/postfix/main.cf sowie die im gleichen Verzeichnis liegenden Beispieldateien für weitere Konfigurationen sind ziemlich
gut kommentiert - damit sollten eventuell notwendige Feineinstellungen ohne weiteres möglich sein. Bleibt noch anzumerken, daß jede
zugewiesene Variable an beliebiger anderer Stelle der Konfigurationsdatei wieder verwendet werden kann:
mydomain = domaene.de
relay_domains = $mydomain
Falls doch das eine oder andere Feintuning notwendig sein sollte, kann man sich auf die beiden zentralen Dateien main.cf und master.cf (siehe
Kasten "master.cf") beschränken. Erstere wurde bereits besprochen, letztere dient dem Steuern der Ressourcen, die Postfix verbraucht. Hier
kann unter anderem angegeben werden, wieviele Prozesse maximal gleichzeitig laufen dürfen.
Gestartet wird Postfix auf zweierlei Art: einmal so, wie der gute alte sendmail mit
sendmail -bd -q5
oder durch
postfix start
Dadurch daß der "alte" Aufruf funktioniert, brauchen eventuell vorhandene rc- (BSD) oder init.d- (SystemV) Skripte nicht angepaßt werden.
Beim ersten Aufruf legt das Postfix-Startup-Skript einige Dateien und Verzeichnisse an. Dies sollte keine Probleme bereiten, sollte aber wie
bereits erwähnt nur beim ersten Start erfolgen. Sollten im laufenden Betrieb Änderungen in den Konfigurationsdateien gemacht werden, genügt
das Kommando
postfix reload
Um die Sicherheit von postfix noch etwas zu erhöhen ist es möglich, die einzelnen Postfix-Dämonen in einer "chroot"-Umgebung laufen zu
lassen. Beispiele dazu liegen in examples/chroot-setup des Sourcebaumes.

Datei master.cf
# ====================================================================
# service type private unpriv chroot wakeup maxproc command + args
# ====================================================================
. . .
smtp inet n - - - 5 smtpd
pickup fifo n n - 60 1 pickup
cleanup unix - - - - 0 cleanup
qmgr fifo n - - 300 1 qmgr
Postfix im Einsatz
Auch im laufenden Betrieb ist Postfix pflegeleicht. Die wenigen für den Mailadministrator relevanten Kommandozeilen-Utilities sind folgende:
Das Kommando postfix dient zum Steuern des gesamten Systems. Damit kann der Administrator das Mailsystem starten oder herunterfahren,
die Konfiguration neu laden, ohne das Mailsystem ganz runterfahren zu müssen. oder ähnliches. Dieses Kommando ist dem Superuser
vorbehalten.
ähnlich Sendmails Kommando newaliases ist postalias für die Mail-Aliases zuständig
postcat zeigt in der aktuellen Postfix-Version den Inhalt der Queues an
postconf zeigt die in der Datei main.cf gesetzten Werte an.
postdrop wird auf solchen Systemen verwendet, die kein für alle schreibbares Verzeichnis für die "maildrop"-Queue haben. postdrop wird vom
Kommando sendmail ausgeführt.
postkick dient als Schnittstelle zu internen -ommunikationskanälen, etwa für Shellskripts.
postlock stellt ein Postfix-kompatibles Mailbox-Locking zur Verfügung, etwa für Shellskripts.

postlog stellt für externe Programme oder Shellskripts eine Postfix-kompatible Logging-Funktion bereit.
postmap stellt in etwa dieselbe Funktion wie makemap zur Verfügung und generiert die Lookup-Tabellen, je nach System als hash (db) oder
dbm.
postsuper ist das Tool, das die Mails in den verschiedenen Queues verschiebt. Das Postfix-Startskript führt dieses Kommando aus.
Wer den alten Sendmail gewöhnt ist, kann auch gewohnte Kommandos wie
sendmail -q
zum Absenden der Mails in der Queue
sendmail -bp
zum Anzeigen der Mail-Queue verwenden. Außer sendmail -v sollten alle gewohnten Befehle funktionieren. Dies erleichtert den Umstieg von
Sendmail auf Postfix ungemein.
Virtuelle Domains
Postfix kann auch mit "virtual domains" umgehen. Das ist vor allem für Internet Service Provider interessant. Anstatt für jede Domäne einen
eigenen Mailserver aufzubauen, kann Postfix das genauso wie Sendmail oder Qmail übernehmen. Wer das schon einmal unter Sendmail
konfiguriert hat, wird erstaunt sein, wie einfach es ist. Am besten verwendet man dazu die leere Datei /etc/postfix/virtual aus den Beispielen.
Die Einträge sollen in etwa folgendermaßen aussehen:
bereich.com EGAL WAS HIER STEHT

longariva@bereich.com grlongar
reimer@bereich.com reimer@softbaer.de
info@bereich.com grlongar, bnreimer, xwolf@xwolf.com
mein-zahnarzt.net Zahnarztportal

info@mein-zahnarzt.net info@softbaer.de
In der ersten Zeile wird die Domäne ohne Mailadresse angegeben. Der rechte Teil spielt hier keine Rolle - als Tipp: eine kurze Erklärung zur
Domäne kann ganz hilfreich sein. Darauf folgen die EMail-Adressen, die Postfix annehmen soll. Im rechten Teil stehen die (existierenden)
Benutzeraccounts oder externe EMail-Adressen, an die Postfix die Mail weiterleiten soll. Postfix akzeptiert nur die hier eingetragenen Adressen.
In /etc/postfix/main.cf muß man die Datei noch bekannt machen, je nach installiertem System mit db- oder dbm-Hashes:
#virtual_maps = dbm:/etc/postfix/virtual
virtual_maps = hash:/etc/postfix/virtual
Nach einer Änderung in der Datei sollte der Administrator nicht vergessen, postmap /etc/postfix/virtual aufzurufen, um die Hashtabelle für
Postfix zu generieren. Sollten Hosts über eine Dialin-Verbindung die Mails an den Mailserver abschicken, kann es notwendig sein, die
Domäne des Providers, über den der Dialin erfolgt, zusätzlich als akzeptierte Relay-Domain einzutragen:
relay_domains = $mydestination, einwahl.provider.de, noch.einer.de
Verschickt nämlich jemand von einem solchen Host aus eine Mail - zwar mit korrekter Absenderadresse - an jemanden außerhalb einer von
Postfix verwalteten Domain, wird diese Mail nicht akzeptiert, weil Postfix die Domäne des Hosts überprüft.
Die meisten Provider bieten keine feste IP-Adresse für ihre Kunden; damit erscheinen die Dialin-Hosts unter der Domäne des Providers. Es
sollten hier wirklich nur die allernotwendigsten Domänen oder Hosts eingetragen werden! Abhilfe könnte hier das weiter unten erläuterte
"POP before SMTP" bieten.
Auf die Einträge in den DNS-Server soll hier nicht weiter eingegangen werden. Natürlich hat es keinen Sinn, virtuelle Domänen einzurichten,
wenn der entspre- chende MX-Eintrag nicht auf den Postfix-Server zeigt.
Mail Relaying durch POP before SMTP
Generell ist es keine gute Idee, jedem Host zu erlauben, Mails auf dem Server abzulegen und weiterzuschicken. Genau dies benutzen nämlich
die Mail-Spammer, um ihre Mails zu verteilen: auf einem schlecht administrierten Mailserver werden Mails abgelegt. Der sichtbare Absender
einer solchen Mail ist in der Regel eine nichtexistierende Adresse (das SMTP Protokoll sieht hier keine Überprüfungsmechanismen vor), und
der oder die Empfänger sind real existierende Adressen. Die Mails werden zugestellt, und der Empfänger hat in der Regel keine Chance
festzustellen, woher die Mail tatsächlich kam. Der Absender ist gefälscht; als Absenderhost steht der angegriffene Mailhost im Header.

Lediglich der Rechner, der den Connect zum Mailhost aufgebaut hat, ist im Header ersichtlich. Meistens ist das ein Dialin-Account, der
einmalig für solche Aktionen verwendet und danach nie wieder benutzt wird. Außerdem kann ein "normaler" Benutzer nichts mit den
Informationen eines Mailheaders anfangen. Somit bleiben die Absender weitgehend anonym. Deshalb soll kein Rechner, der über das Internet
erreichbar ist, Mails relayen!
.procmailrc
VERBOSE=off
LOGABSTRACT=none
MAILHOME=$HOME/Mail
FRIENDS=$MAILHOME/friends
SPAM=$MAILHOME/spam
WORK=$MAILHOME/work
LISTS=$MAILHOME/lists
:0
* ^From.*bnreimer@(office\.|)softbaer\.de.*
$FRIENDS
:0
* ^(To|Cc).*info@softbaer\.de.*
$WORK
:0
* ^(From|To|Cc).*BUGTRAQ@SECURITYFOCUS.COM.*
$LISTS
:0
* ^Subject: .*FREE .*
$SPAM
Eine Möglichkeit um auftretende Probleme zu lösen - man will ja schließlich nicht wirklich jedem den Zugang verwehren - ist das so genannte
POP before SMTP. SMTP bietet per se keine Authentifizierungsmöglichkeit. Es gibt zwar einige Erweiterungen des SMTP-Protokolls; diese
muß aber auch der sendende Client unterstützen. Deshalb wird oft folgender einfacher Trick angewandt: Der Client (oder besser: der Benutzer)
loggt sich in den POP-Server ein und holt seine Mails ab. Dazu muß er sich Login und Paßwort authentifizieren. Nun kann man den POP Server

"aufbohren" und ihn anweisen, den gerade eben authentifizierten Host in eine Tabelle einzutragen. Beim Versenden von Mails schaut Postfix in
dieser Tabelle nach und gestattet das Weitersenden von Mails von eben diesem Host. Nach einer gewissen Zeit löscht Postfix die Einträge
wieder.
Das Paket DRAC (Dynamic Relay Authorization Control Daemon, [6]) wurde ursprünglich für Sendmail entwickelt. Es besteht aus einem Patch
für den weit verbreiteten (freien) POP-Daemon qpopper [7] von Qualcomm und einem Dämon. Der Patch bewirkt, daß qpopper sich nach
erfolgreicher Authentifizierung an den dracd verbindet und diesem die aktuelle Adresse des Rechners mitteilt. Der dracd schreibt diese dann in
eine bestimmte Datei, die Postfix ausliest.
Der dazu nötige Eintrag in /etc/postfix/main.cf lautet:
smtpd_recipient_restrictions = permit_mynetworks \
check_client_access hash:/etc/postfix/client_access \
check_relay_domains
Auch hier ist zu beachten, ob man Hashes in db- oder dbm-Form verwendet. Den dracd muß man natürlich auch entsprechend konfigurieren.
Generell sollte man möglichst wenig Rechnern Zugriff gestatten; nicht nur um sich und seine Benutzer zu schützen, sondern auch um dem
Phänomen SPAM entgegenzuwirken, das täglich Millionen von Dollar an Kosten verursacht - irgendjemand muß ja für das Datenaufkommen
zahlen!
Postfix-Erweiterungen
Wegen des modularen Aufbaus von Postfix läßt sich das Paket sehr leicht erweitern. Es ist beispielsweise sehr leicht möglich, einen
Virenscanner für einkommende Mails in Postfix einzubauen. Dazu kann es ein externes Programm an zwei Stellen aufrufen: entweder gleich
beim Eintreffen der Mail, bevor die Mail in die Postfix-Queue übernommen wird, oder sobald die Mail in die Systemmailbox geschrieben wird
- also wenn die Mail die Postfix-Queue wieder verläßt. In /etc/postfix/main.cf ist dazu ein lokales Mailverteilprogramm aufzurufen:
mailbox_command = /local/bin/viruscheck
Man sollte nicht vergessen, die Mail nach dem Check auch wirklich in die Mailbox zu schreiben, etwa mit Procmail [8]. Das Verwenden von
Procmail hat übrigens den Vorteil, daß eventuell von den Benutzern definierte Filter automatisch verwendet werden. Das heißt, daß eine
möglicherweise vorhandene .procmailrc im Home-Verzeichnis eines Benutzers automatisch verwendet wird, ohne daß der Benutzer die Mails

mittels .forward an Procmail weiterleitet (siehe Kasten .procmailrc). Natürlich ist das nur ein sehr allgemeines Beispiel, das auf keinen Fall die
Funktion von procmail erklären kann. Es zeigt aber, wie die Regeln auf einfachen regulären Ausdrücken basieren - damit sollte jeder, der etwas
Perl, sed, awk oder grep>beherrscht, zurechtkommen. Lesen der Man-Pages von Procmail (procmail(1), procmailrc(5), procmailsc(5),
procmailex(5)) hilft in jedem Fall weiter.
Untersuchung Mailer im Internet

Anfang April 2000 veröffentlichte Dan Bernstein, der Autor von Qmail, in den Newsgroups comp.mail.misc, comp.mail.sendmail,comp.
security.unix eine Untersuchung über die Anteile der verschiedenen Mailer im Netz. Dazu schaute er sich 1/256 aller "second level" .com-
Domains an, insgesamt 12595 IP-Adressen, und bekam in 11460 Fällen Kontakt auf dem SMTP-Port. Für die Verhältnisse in Europa mag diese
Untersuchung wenig relevant sein, sie gestattet aber trotzdem einen gewissen Einblick. Einige Details der Untersuchung:
● Unix ist mit einem Anteil von 65% das meistgebräuchliche Betriebssystem; etwa 22% der Hosts sind Windows, und bei zirka 8% ist
keine eindeutige Aussage möglich.
● Sendmail, Inc. spricht auf seiner Webseite von einem Marktanteil von "über 75 Prozent", diese Zahl ist aber schon ein paar Jahre alt.
● die meisten gefundenen Sendmail-Versionen sind bekanntermaßen fehlerhaft; in einigen Fällen kann man sich hierüber unautorisierten
Zugriff verschaffen. Die wenigsten Server haben eine aktuelle Sendmail-Version. Offenbar nehmen die meisten Sendmail-Nutzer, was
gerade auf einem System installiert ist.
Die "Markt"-Anteile im einzelnen:
Anteil % Anzahl Mailer

54.5 6247 UNIX Sendmail
9.2 1057 Windows Ipswitch IMail
5.7 650 Windows Microsoft Exchange
5.3 607 UNIX qmail
4.1 472 UNIX/Windows Software.com Post.Office
294 unsicher
231 UNIX Exim
168 Windows Gordano NTMail
148 UNIX/Windows Netscape Messaging Server
134 MacOS Eudora Internet Mail Server, früher AIMS

122 UNIX IBM Postfix, früher VMailer
Die Möglichkeiten, externe Programme in Postfix einzubinden, sind sehr vielfältig. Beispielsweise könnte der Administrator eine automatische
Ver/Entschlüsselung von Mails vom Firmensitz zu einer Außenstelle implementieren, damit sie "unterwegs" nicht lesûar sind. Außerdem kann
ein SPAM-Filter an zentraler Stelle eingebaut werden. Ein solcher ist wesentlich einfacher zu verwalten als Procmail-Filter für jeden einzelnen
Benutzer. Der Fantasie der Mailadministratoren sind (fast) keine Grenzen gesetzt. (hmi)
Infos
[1] Wietse Venema's postfix, http://www.postfix.org

[2] Eric Allman's sendmail, http://www.sendmail.org
[3] Bryan Costales, Eric Allman sendmail, 2nd Edition O'Reilly, 1997
[4] Dan Bernstein's qmail, http://www.qmail.org/top.html
[5] postfix download sites, http://www.postfix.org/ftp-sites.html
[6] Dynamic Relay Authorization Control Daemon, http://www.mbnet.mb.ca/howto/ dynamic.htm
[7] Qpopper - POP3 Daemon, http://www.eudora.com/qpopper
[8] procmail, http://www.procmail.org
Der Autor
Gregor Longariva studierte Informatik an der Uni Erlangen. Während des Studiums gründete er die Firma SOFTbaer, die sich in erster Linie
mit dem Thema Sicherheit und Netzwerkadministration auf Unix-Basis beschäftigt. Nebenbei ist er noch als Administrator des CIP-Pools der
Informatik an der Uni Erlangen tätig und beschäftigt sich neben HPUX und Irix vor allem mit Solaris und Linux.
Copyright © 2000 Linux New Media AG

Linux Journal
Linux Journal Home > Magazine > #78 October 2000 > Using
Postfix for Secure SMTP Gateways
Wednesday, September 13, 2000 | Last Updated 04:35:09 PM
Using Postfix for Secure SMTP

Gateways
Improve your site's e-mail hygiene and make life difficult for spammers and
hackers.
by Mick Bauer and Brenno de Winter
E-mail is easily the most popular and important Internet service today, which has
made it a popular target of cyber-criminals and spam-happy miscreants. Adding to
the problem is the inescapable reality that configuring sendmail, the most
commonly used Mail Transfer Agent (MTA), is complicated, nonintuitive and
easy to get wrong.
Wietse Venema, intrepid developer of TCP wrappers and co-creator of SATAN,

has come through for us again: his program, postfix, provides an alternative to
sendmail that is simpler in design, more modular, easier to configure and less
work to administer. Equally important, it's been designed with scalability,
reliability and sound security as fundamental requirements.
This article is intended to bring you up to speed quickly on how to use postfix on
your network as a secure means of receiving e-mail from and delivering it to
Internet hosts. In particular we'll focus on deploying postfix on firewalls, in DMZs
and in other settings in which it will be exposed to contact with untrusted systems.
http://www.subneural.net/postfix-master/linuxjournal.200010/index.html (1 of 11)01/16/2005 15:48:12

Linux Journal
Is sendmail really that bad? That depends on what you need it to do--the learning
curve may not be justified if your e-mail architecture is simple. But sendmail is
unquestionably an extremely powerful, stable and widely deployed application
that isn't going away anytime soon, nor should it. In fact, The Paranoid Penguin
will probably feature a sendmail article some time in the next few months.
Background: Mail Transfer Agents
Both sendmail and postfix are Mail Transfer Agents. MTAs move e-mail from one
host or network to another. These are in contrast to Mail Delivery Agents, which
move mail within a system (i.e., from an MTA to a local user's mailbox, or from a
mailbox to a file or directory). In other words, MTAs are like the mail trucks (and
airplanes, trains, etc.) that move mail between post offices; Mail Delivery Agents
are like the letter-carriers who distribute the mail to their destination mail boxes.
In addition to MTAs and MDAs, there are also various kinds of e-mail readers,
including POP, POP3, and IMAP clients for retrieving e-mail from remote
systems. These are also known as Mail User Agents, or MUAs. (There is no real-
life simile for these, unless your mail is handed to you each day by a minion
whose sole duty is to check your mail box now and then!) But we're not concerned
with these or with MDAs, except to mention how they relate to MTAs.
By the way, if you still use UUCP, it's supported in postfix (and continues to be in
sendmail, too); most MTAs support a variety of delivery `àgents'', almost always
UUCP and SMTP at the very least. Still, for the remainder of this article we'll
assume you're interested in using postfix for SMTP (Simple Mail Transfer
Protocol) transfers.
SMTP Gateways and DMZ Networks
One very common use of SMTP, especially in organizations which use other e-
mail protocols internally, is on an Internet e-mail gateway. Since SMTP is the
lingua franca for Internet e-mail, there must be at least one SMTP host on any
network that needs to exchange e-mail over the Internet. In such a network, the
SMTP gateway acts as a liason between non-SMTP mail servers on the inside and
SMTP hosts on the outside.
This ``liason'' functionality in and of itself isn't as important as it once was; the
current versions of Microsoft Exchange, Lotus Notes, and many other non-SMTP-
based e-mail server products have no problem communicating with SMTP servers
directly. But there are still reasons to have all inbound (and even outbound) e-mail
arrive at a single point, the chief reason being security.

Linux Journal
There are two main security benefits to using an SMTP gateway. First, it's much
easier to secure a single SMTP gateway from external threats than it is to secure
multiple internal e-mail servers. Second, separating Internet mail from internal
mail allows one to move Internet mail transactions off the internal network
entirely. The logical place for an SMTP gateway is in a DMZ (``Demilitarized
Zone'') network, separated from both the Internet and the internal network by a
firewall.
As with DNS, FTP, WWW and any other publicly accessible service, the more
protection you can place between potential hackertargets and your internal
network, the better. Adding an extra NIC to your firewall, keeping public services
in a separate network, is one of the cheapest and most effective ways of doing
this--as long as you configure the firewall to carefully restrict traffic to/from the
DMZ). It's also good risk management; in the (hopefully) unlikely event that your
web server, for example, is compromised, it won't become nearly as convenient a
launch pad for attacks on the rest of your network.
(For additional information on the DMZ technique of firewalling, see the article
Securing DNS and BIND, page 92 of this issue.)
Thus, even organizations with only one e-mail server should still consider adding
an SMTP gateway, even if that e-mail server already has SMTP functionality.
But what if your firewall is your FTP server, e-mail server, etc.? Although the use
of firewalls for any service hosting is scowled upon by the truly paranoid, this is
common practice for very small networks (e.g., home users with broadband
Internet connections). And, in this foul-weather paranoiac's opinion, BIND and
postfix pose much less of an exposure for a firewall than other service
applications.
For starters, DNS and SMTP potentially involve less direct contact between
untrusted users and the server's file system. (I say ``potentially'' because it's
certainly possible, with badly written or sloppily configured software, to create
extremely insecure DNS and SMTP services.) In addition, both BIND and postfix
have ``chroot'' options and run as unprivileged users, two features that help reduce
the danger of either service being used to somehow gain root access (we'll discuss
both of these options in depth shortly.)
Postfix Architecture: How Does Postfix Work?
To understand how postfix works, it's useful to consider its background. The main
purpose for postfix's existence is sendmail's complexity. Postfix is a full-featured
MTA, and therefore its core functions are the same as any other's. But postfix was
written with unusual attention to:
Linux Journal
● Security. Postfix was designed with security as a fundamental requirement

rather than as an afterthought. It's obvious that Mr. Venema has taken the
lessons of history (as chronicled by CERT, bugtraq, et al.) very much to
heart. For example, the system doesn't trust any data, regardless of its
source. And with least privilege in a chrooted jail (see below), risks are
reduced. Furthermore, protective measures against buffer overflows and
other user-input attacks have been implemented. If something still fails,
postfix's protection mechanism tries to prevent any of the processes under
its control from gaining rights they shouldn't have. Since postfix is
comprised of many different programs that function without a direct
relationship to each other, if something goes wrong, the chance that such a
problem can be exploited by an attacker is minimized. Of course, we all
know that no system is 100% secure; the goal must be to minimize and
manage risks. Postfix is definitely engineered to minimize security risks.
● Simplicity and compatibility. Postfix has been written in such a way that
setting it up ``from scratch'' can take as little as five minutes. When you
want to replace sendmail or other MTAs, it's even better: postfix by default
can use the old configuration files!
● Robustness and stability. Postfix was written with the expectation that
certain components of the mail network (the Local Area Network, the
Internet uplink, the local interfaces, etc.) will occasionally fail. By
anticipating things that can go wrong at either end of any given transaction,
postfix is capable of keeping the server up and running in many (if not
most) circumstances. If, for instance, a message cannot be delivered, it is
scheduled to be delivered later, without immediately initiating a continuous
retry.
A key contributor to the stability and the speed of postfix is the intelligent way in
which it queues mail. Postfix uses four different queues, each one of which is
handled differently (see Figure 1):
● Maildrop queue. Mail that is delivered locally on the system is accepted in

the Maildrop queue. Here, the mail is checked for proper formatting (and
fixed if necessary) before being handed to the Incoming queue.
● Incoming queue. The Incoming queue receives mail from other hosts,
clients or the Maildrop queue. As long as e-mail is still arriving and as long
as postfix hasn't really handled the e-mail, this queue is the place where the
e-mails are kept.
● Active queue. The Active queue is the queue that is used to actually
deliver messages and therefore has the greatest potential risk of something
going wrong. This queue has a limited size, and messages will be accepted
only if there is space for them. That means e-mail in the Incoming and
Deferred queues have to wait until the Active queue can accept them.

Linux Journal
● Deferred queue. E-mail that cannot be delivered is placed in the Deferred

queue. This prevents the system from continuously trying to deliver e-mail
and keeps the Active queue as short as possible in order to give newer
messages priority. This also enhances stability. If the MTA cannot reach a
domain, all the e-mail for that domain is placed in the Deferred queue, so
that those messages will not needlessly monopolize system resources.
Retry is scheduled with an increasing waiting time. When the waiting time
expires, the e-mail is again placed in the Active queue for delivery; the
system keeps track of retry history.
Postfix for the Lazy: A Quick and Dirty Startup Procedure
And now the part you've been waiting for (or have skipped directly to): postfix
setup. Like sendmail, postfix uses a ``.cf'' text file as its primary configuration file
called main.cf. However, ``.cf'' files in postfix use a simple ``parameter=
$value'' syntax. What's more, these files are extremely well commented and use
highly descriptive variable names.
In fact, if your e-mail needs are simple enough, it's probably possible for you to
figure out much of what you need to know by editing main.cf and reading its
comments as you go.
For many users, this is all one needs to do to configure postfix on an SMTP
gateway:
1. Install postfix from a binary package via your local package tool (rpm, etc.)
or by compiling from source and running postfix's INSTALL.sh script.
2. Open /etc/postfix/main.cf with the text editor of your choice.
3. Uncomment and set the parameter myhostname to equal your server's
fully qualified domain name (FQDN), e.g., ``myhostname = buford.
dogpeople.org''.
4. Uncomment and set the parameter mydestination as follows,
assuming this is the e-mail gateway for one's entire domain:

$mydomain
NOTE: Enter the above line verbatim.
1. Save and close main.cf.

2. If desired, add a line to /etc/aliases diverting root's mail to a less-privileged
account, e.g., root: mick. This is also the place to map aliases for users
who are served by internal mail servers (for example, mick.bauer:
mbauer@secretserver.dogpeople.org). When you are done
Linux Journal
editing and/or adding aliases, save the file and enter the command
newaliases to convert it into a hash database.
3. Execute the command postfix start.
What did we just achieve? In only four steps, we installed, configured and started
SMTP services for our machine and its local name-domain. If this machine is a
firewall or an SMTP gateway on a firewall's DMZ network, it can now be used by
local users to route outbound e-mail, and can be pointed to by our domain's ``MX''
DNS record (i.e., it can be advertised to the outside world as a mail server for e-
mail addressed to our domain). We've also told it to directly process (rather than
forward) mail addressed to local hosts. Pretty good return on the investment of
about five minutes' worth of typing, no?
(NOTE: While this may be enough to get postfix working, it is not enough to
secure it. Don't stop reading yet!)
The Quickness and Dirtiness Explained
As cool as that was, it may not have been enough to get postfix to do what needs
to be done for your network. And even if it was, it behooves you to dig a little
deeper: ignorance nearly always leads to bad security. Let's take a closer look at
what we just did, and then move on to even niftier postfix tricks.
First, why did so little information need to be entered in main.cf? The only thing
we added to it was our fully qualified domain name. In fact, depending on how
your machine is configured, it may not have even been necessary to supply that!
This is because postfix uses system calls such as gethostname to glean as

much information as possible directly from your kernel. If given the fully
qualified domain name of your host, it's smart enough to know that everything
past the first ``.'' is your name-domain, and it sets the variable mydomain
accordingly.
You may need to add additional names to mydestination if your server has
more than one FQDN (that is, multiple `À'' records in your domain's DNS). For
example, if your SMTP gateway doubles as your public FTP server, and thus has
the name ``ftp'' associated with it in addition to its normal host name, your
mydestination declaration might look something like this:

ftp://www.$mydomain, $mydomain
It's important that any name by which your server can be legitimately referred to
Linux Journal
is contained in this line.
There were two other interesting things we did in the ``quick and dirty'' procedure.
One was to start postfix with the command postfix start. Just as BIND uses
ndc to control the various processes that comprise BIND, the postfix
command can be used to manage postfix. Like BIND, postfix is actually a suite of
commands, dæmons and scripts rather than a single monolithic program.
The most common invocations of the postfix command are postfix

start, postfix stop and postfix reload. Start and stop are obvious;
reload causes postfix to reload its configuration files without stopping and
restarting. Another handy one is postfix flush, which forces postfix to
immediately attempt to send all queued messages. This is particularly useful after
changing a setting that you think may have been causing problems--in the event
that your change worked, all messages delayed by the problem go out
immediately. They'd go out regardless, but not as quickly.
The other thing we did was to add a line to /etc/aliases to divert root's e-mail to an
unprivileged account. This is good healthy paranoia: we don't want to have to log
in as the superuser for mundane activities such as viewing system reports, which
are sometimes e-mailed to root. Be careful, however: if your unprivileged account
uses a ``.forward'' file to forward your mail to some other system, you may wind
up sending administrative messages over public bandwidth in clear text!
Aliases Revealed
As alluded to in the quick and dirty procedure, aliases are also useful for mapping
e-mail addresses for users who don't actually have accounts on the SMTP
gateway. This practice has two main benefits. First, most users prefer meaningful
e-mail names and short host /domain names, e.g., ``john.smith@acme.com'' rather
than ``jsmith023@mail77.midwest.acme.com''. Second, you probably don't want
your users connecting to and storing mail on a publicly accessible server. Again,
common sense tells us that any server the unwashed masses can commune with
must be kept at arm's length. The greater the separation between public servers
and private servers, the better. (And don't forget, POPmail passwords are
transmitted in clear text!)
Still another use of aliases is the maintenance of mailing lists. An alias can
point to not only an address or comma-separated list of addresses, but also to a
mailing list. This is achieved with the :include:tag--without this, postfix will
append mail to the file specified rather than using the file to obtain recipients.
(This is a feature, not a bug; it's useful sometimes to write certain types of
messages to a text file rather than to a mailbox.)

Linux Journal
Here's part of an example alias file that contains all of these types of mappings:
postmaster: root<\n>
mailer-daemon: root
hostmaster: root
root: bdewinter
mailguys: bdewinter,mick.bauer
mick.bauer: mbauer@biscuit.stpaul.dogpeople.org
clients: :include:/etc/postfix/clientlist.txt
spam-reports: /home/bdewinter/spambucket.txt
One warning: if an alias points to a different mail server, that server must belong
to a domain for which the SMTP gateway is configured to relay mail (i.e., either
that server's FQDN or its domain must be listed in the mydestination
declaration in main.cf).
Don't forget to run either newaliases or, hipper still, postalias /etc/
aliases anytime you edit aliases. The postalias command is hipper because
it can accept any correctly formatted alias file as its input. Both commands
compress the alias file into a database file that can be searched repeatedly and
rapidly each time a destination address is parsed; neither postfix nor sendmail
directly use the text version of aliases.
If you have a large number of users and/or internal mail servers, alias-file updates
lend themselves to automation, especially via Secure Shell (ssh) and Secure Copy
(scp). Using scp with null-passphrase RSA (or DSS/El Gamal) keys, your internal
mail servers can periodically copy their local alias files to the SMTP gateway,
which can then merge them into a new /etc/aliases followed by postalias /
etc/aliases. (Unfortunately, telling you exactly how to use scp/ssh is beyond
the scope of this article.) This practice is especially useful in large organizations
where different people control different mail servers: day-to-day e-mail account
administration can be kept decentralized.
Keeping out Unsolicited Commercial E-mail
Junk mail is one of the most common and annoying types of e-mail abuse. Postfix
offers protection against UCE (Unsolicited Commercial E-mail) via a couple of
settings in main.cf. Some caution is in order, however: there's a fine line between
spam and legitimate dissemination, and it's entirely possible that even modest
UCE controls will cause some legitimate (i.e., desired) mail to be dropped.
Having said that, for most sites this is an acceptable risk (avoidable, too, through
end-user education), and we recommend that at a minimum, you set the following
in main.cf:
Linux Journal
● smtpd_recipient_limit. This setting indicates how many recipients may be

addressed in the header of a single message. Normally, such a number
should not exceed something like 500. It would be extreme to receive an e-
mail that has 500 recipients and was not being sent to a mailing list.
● smtpd_recipient_restricitons. Not every e-mail that arrives at your server
should be accepted. This parameter instructs postfix to check each
message's recipient-address base on one or more criteria. One of the easiest
to maintain is the access database. This file lists domains, hosts,
networks and users who are allowed to receive mail from your server. To
enable it: (1) set check_recipient_access = hash:access; (2)
create /etc/postfix/access (do a man 5 access for format/syntax); and
(3) run postmap hash:/etc/postfix/access to convert the file
into a database. Repeat step (3) each time you edit /etc/postfix/access.
● smtpd_sender_restrictions. By default postfix will accept SMTP
connections from everybody, potentially exposing your server to SMTP
relaying, a method often used for UCE perpetrators who wish to hide their
identities by ``bouncing'' their messages off unsuspecting SMTP relayers.
If this occurs, it's possible and even likely that other servers will reject e-
mail from your domain(s). Other protection mechanisms lie in the fact that
it is always wise to check the sender against DNS. Although this costs
some performance, it makes it harder to send the information from a faulty
sender e-mail address. See the file /etc/postfix/sample-smtpd.cf for a list of
possible list options for this parameter. Note that hash:access is one of
them; the access database can be used not only to allow/disallow
particular recipients, but senders as well. For a complete list of anti-UCE
parameters and their exact syntax see /etc/postfix/sample-smtpd.cf.
Hiding Internal E-mail Addresses by Masquerading
In order to prevent giving out information that serves no purpose to legitimate

external parties, it is wise to set in the main.cf file the parameter
masquerade_domains = $mydomain (remember, ``$mydomain'' refers to
a variable). If you wish to make an exception for mail sent by ``root'' (probably a
good idea), you can set the parameter masquerade_exceptions = root.
This will cause internal host names to be stripped from FQDSes in ``From''
addresses of outbound messages.
Running Postfix in a chroot Jail
Now we come to one of the groovier things we can do to secure postfix: running it
in a ``chroot jail''. chroot is a UNIX command that confines the ``chrooted''
process to a specified directory; that directory becomes ``/'' for that process. This
usually requires you to first create copies of things needed by the process but
Linux Journal
normally kept elsewhere. For example, if the process looks for ``/etc/mydaemon.
conf'' upon startup but is being chrooted to ``/var/mydaemon'', the process will
actually look for ``/var/mydaemon/etc/mydaemon.conf''.
The advantage to chrooting should be obvious: should a chrooted-postfix process

become hijacked somehow, the attacker will find himself in a ``padded cell'' from
which (hopefully) no sensitive or important system files or data can be accessed.
This isn't a panacea, but it signigicantly increases the difficulty of exploiting
postfix.
Happily, the preparations required to chroot postfix are provided in a subdirectory

of the postfix documentation called `èxamples''. These files aren't really shell
scripts: they're suggested sequences of commands.
Better still, some binary distributions of postfix have installation scripts that
automatically make these preparations for you after installing postfix. In SuSE, for
example, the postfix RPM package runs a script that creates a complete directory
tree for postfix to use when chrooted (etc, usr, lib, and so forth) in /var/spool/
postfix, with the appropriate ownerships and permissions.
In addition to ``provisioning'' postfix's chroot jail, you need to edit /etc/postfix/

master.cf to toggle the postfix dæmons you wish to run chrooted (i.e., put a ``y'' in
the ``chroot'' column of each dæmon to be chrooted). Do not, however, do this for
dæmons whose ``command'' column indicates that they are of type ``pipe'' or
``local''. Some binary-package distributions toggle the appropriate dæmons to
chroot automatically during postfix installation (again, SuSE does).
After configuring the chroot jail and editing master.cf, all you need to do is start
postfix the way you normally would: postfix start. Postfix's master process
handles the actual chroot-ing.
Conclusion
That's more than enough information to get you started. May your mail arrive
promptly and the spamming filth stay out!
Resources

Linux Journal
Mick Bauer is security practice lead at the Minneapolis

bureau of ENRGI, a network engineering and consulting
firm. He's been a Linux devotee since 1995 and an
OpenBSD zealot since 1997, taking particular pleasure in
getting these cutting-edge operating systems to run on
obsolete junk. Mick welcomes questions, comments, and
greetings sent to mick@visi.com.
Brenno de Winter, 28, is the Linux-focused president of De

Winter Information Solutions. He started programming at
the age of nine. In his daily routine he is involved in UNIX/
Linux, databases, security, telephony-over-IP
presentations, consulting and training. He's active in the
Polder Linux User Group, has contributed to several GPL
projects, including GnuPG, MySQL and TWIG, and is in
the process of creating a brand-new project himself as
well.

Sys Admin Magazine Online
INSIDE Sys Admin:

HOME | CONTACT US | SUBSCRIBE | ADVERTISE | WRITE FOR US | ABOUT US | CDROM
Root
Current
Archives IBM's Secure Mailer
Downloads
Solaris Corner Kyle Dent
LINUX Rookery
Wietse Venema, probably best known as the developer of SATAN and the TCP Wrapper security tools,
Tool Showcase
has now created Secure Mailer. In December of 1998, IBM released Secure Mailer as open source
Q&A software providing a new, freely available alternative to the nearly universal Sendmail program. The
Resources program, more commonly known in open-source circles as Postfix, attempts to be fast, easy to
Newsletters administer, and secure. One of the primary goals of Postfix is to be widely implemented in order to make
Marketing opps the most significant impact on the performance and security of Internet email overall.
Sendmail by some estimates handles nearly three-quarters of all email on the Internet, but it has had a
bit of a checkered past with a history of security problems. A scan through the CERT Advisories quickly
turned up more than a dozen Sendmail incidents. Although Sendmail developers have made a lot of
progress in bringing it up to date for an environment that was unimaginable when it was originally
created, Postfix offers a solid alternative that is inherently more secure.
Good Breeding and Impeccable Manners
In addition to tighter security, Postfix offers several advantages over Sendmail while maintaining a high
level of compatibility with it. The Postfix Web site claims that it is up to three times faster than its nearest
competitor. (There are several other Sendmail alternatives, such as qmail and various commercial
packages.) It is designed to be robust and behave well under stress. For example, runaway conditions
that might occur during error handling are diminished because the software pauses before sending error
messages or terminating with a fatal error. It operates under a "no thundering herd" policy when
delivering mail to other hosts. Initially, Postfix will make only two simultaneous connections. If the
deliveries succeed, Postfix will slowly increase connections up to a configurable limit. It will also detect
whether the receiving host can no longer handle the load and decrease the number of connections.
In processing its own queue, Postfix implements a few other policies to make it a well-behaved software
package. The queue manager sorts messages by destination and processes deliveries in a round-robin
fashion to hit all destinations in the queue. Postfix will only make simultaneous deliveries to the same
host when it does not have messages for other destinations waiting. If a message cannot be delivered,
the queue manager marks it with a time stamp. With each repeated delivery failure, Postfix will wait
longer each time before wasting resources trying to deliver a message to a host that is not available.
The queue manager also maintains a short-term list of unreachable destinations.
We Can Still Be Friends
Postfix is designed to be compatible with Sendmail to make migration easier, and to make the change
transparent to users. In fact, you can continue to use Sendmail in conjunction with Postfix, allowing the
new mailer to replace specific mail functions as needed. Postfix continues support for /etc/aliases and
delivery to any of the standard mail directories as well as to a specified file or command. It also respects
user.lock files and will obey $HOME/.forward directives. Basically all the aspects of Sendmail are
present except one significant one -- sendmail.cf.
Sendmail makes extensive use of rewriting rules to ensure that addresses are in the correct form and to
select the correct mail delivery agent for a message site. Administrators can also use them to customize
delivery for their networks. The Postfix Web pages say that there is not yet support for rewriting rules;
rather, Postfix uses a rewriting table. In my opinion, Postfix should display this fact as its most prominent
feature and not suggest support for any rewriting rules in the future. Only a handful of sites would ever
need the full power of Sendmail's rewriting rules, and even fewer systems administrators understand the
http://www.subneural.net/postfix-master/samag.200001/9912a.htm (1 of 5)01/16/2005 15:48:16

black art of rewriting rules well enough to make reasonable modifications. If you do in fact modify
Sendmail rewriting rules, Postfix is probably not an option for you. However, you should look at the
address mapping table feature to see whether it can support your requirements.
Defensive Mailing
Overall, Postfix is written to be a highly secure network application. It employs multiple layers of
defense. All of its processes run at a fixed low privilege, and most can be run within a chrooted
environment. Sendmail is the classic monolithic program, and it runs with root privilege. These two facts
are largely the reason for the severity of Sendmail's security problems. If a vulnerability is discovered,
the possibility that it will allow root access is high.
It is quite possible that Postfix has security bugs, but because of its design, whatever vulnerabilities
might exist will be very limited and possibly not even exploitable over a network. Its modularity provides
flexibility and also security. There are various processes that perform specific tasks. There is a separate
process to send mail and receive mail and to deliver mail locally. Systems only run the processes they
need. If a process is not running, it is necessarily not vulnerable. Another side effect is that each
process is insulated, so that, for example, the local delivery agent has no communication with the
network. If a vulnerability is discovered within local delivery, it cannot be exploited from outside that host.
Some additional security aspects are that Postfix programs do not run under a user process, thereby
eliminating exploits that involve signals, open files, the environment, and other process attributes that
might be passed from a parent to a child. Postfix relies on the security notion of trust or lack of it. Postfix
processes do not even trust each other. Contents of queue files or IPC messages might have been
tampered with; therefore, each process tries to use only its own information in taking security-sensitive
actions.
Some other security lessons learned from Sendmail (among others) and incorporated into Postfix are
that there are no setuid programs, no /tmp race conditions, no remote data in shell variables or shell
commands, and no fixed-length string buffers. Memory is allocated dynamically for buffers and strings,
and long lines of messages are broken up into sequences that are reconstructed upon delivery.
Installing Postfix
After you have downloaded Postfix, it is a simple matter to uncompress the bundle and compile it. On
my system, I had to add one option for the compiler, which was easily accomplished by editing a
straightforward make file. The INSTALL file that comes with the distribution lists supported systems.
The normal UNIX platforms are all there. For most systems, compilation should be as simple as going to
the top-level directory and typing make. In my case compilation was less than a minute, and after I
corrected the makefile, reported no errors.
The INSTALL file offers three options for installing Postfix:
1. Send mail only, without changing an existing Sendmail installation.
2. Send and receive mail via a virtual host interface, without changing an existing Sendmail installation.
3. Replace Sendmail altogether.
I opted for the third choice. Documentation is available on the Postfix Web site and also comes with the
distribution as HTML files and man pages. The INSTALL file provides instructions for installing Postfix
after compilation is complete.
You will need root access on the machine where you are installing the package. As root, create a
directory for Postfix.
# mkdir /etc/postfix
Then execute the following commands from the Postfix source directory:

# chmod 755 /etc/postfix

# cp conf/* /etc/postfix
# chmod 644 /etc/postfix/*
# chmod 755 /etc/postfix/postfix-script*
This will create the configuration directory for Postfix. The path /etc/postfix is hardcoded but can be
overridden by setting an environment variable MAIL_CONFIG.
You will also need to create a spool directory for Postfix.
# mkdir /var/spool/postfix
# chmod 755 /var/spool/postfix
Finally, you will need both a commands directory and a daemons directory. These paths are
configurable in /etc/postfix/main.cf. You can place them anywhere that makes sense for your system. I
chose the recommended /usr/sbin for commands and /usr/lib/postfix for daemons. If you are replacing
an existing Sendmail installation, you will want to rename the Sendmail program, because the Postfix
distribution includes a binary called Sendmail. After moving your Sendmail program out of the way (e.g.,
mv /usr/lib/sendmail /usr/lib/sendmail.orig) execute the following from the Postfix source directory:
# cp bin/* /usr/sbin
# mkdir /usr/lib/postfix
# cp libexec/* /usr/lib/postfix
You can copy the included man pages into place or adjust your MANPATH environment variable as
necessary.
Now, you need to replace the previous Sendmail installation. First, you will need to move mailq and
newaliases so that Postfix can assume their functions. Assuming your programs are in /usr/bin,
execute the following:
# mv /usr/bin/mailq /usr/bin/mailq.orig
# mv /usr/bin/newaliases /usr/bin/newaliases.orig
# chmod 755 /usr/bin/newaliases.orig /usr/bin/mailq.orig
# ln -s /usr/sbin/sendmail /usr/bin/mailq
# ln -s /usr/sbin/sendmail /usr/bin/newaliases
Create an account that will own the Postfix queue and most of its processes. The account should be set
up so that no one can log in using the userid, and it should not have a shell. Use your normal tools to
create the account. The /etc/passwd entry should resemble the following:
postfix:*:45128:45128:Postfix Mailer:/dev/null:/dev/null
Next, there are certain mandatory configuration options to set, and you can set any others as
appropriate for your system. Postfix parameters work like environment variables. Edit the file /etc/
postfix/main.cf. The default file is well documented. If you are following the above installation, set each
of the following as shown:
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix
mail_owner = postfix
For myhostname and mydomain name, use your own host and domain names, but be sure to set
them because they are used as the defaults for other configuration options. Also, be sure to select
(uncomment) the correct mydestination line from the default configuration file.
You can get more configuration information from the online documentation or from the HTML directory
in the Postfix source directory. You should certainly familiarize yourself with most of the configuration
options to decide which settings are important for your environment.

In addition to configuration changes, you have the option of running most of the Postfix processes within
a chrooted environment. This is an excellent security measure that will add another layer of protection
from someone trying to penetrate your system. The steps for creating a chroot are a bit tricky, and they
vary from platform to platform. Also, the chroot will depend on how your binaries were compiled. The
Postfix distribution does include some help in the examples/chroot-setup directory, but these are a bit
skimpy and probably do not provide all the information you will need. You will have to investigate the
documentation for your system and experiment. From a security point of view, this is well worth the
effort.
There is another security decision you will have to make regarding Postfix's submission mechanism,
that is, the attributes on directories used for mail spooling. Postfix offers two options. The first uses a
world-writable, sticky (1733) directory for messages. Because it is world-writable there is no need to run
any program with special privileges (setuid or setgid), and the mail files themselves are not world-
writable or otherwise accessible to other users.
There is a possibility that a local user could do some small damage. For example, it would be possible
to create a hard link to a mail file so that it is not removed when Postfix deletes it. Or, a local user could
copy or hard link some system file to the directory to try to have it delivered as mail. Postfix does take
steps to prevent this (remember, trust no one), so the likelihood that this would work is significantly
diminished. However, if you have a lot of local users on the mail system, and your own security policies
would not permit world-write permissions, Postfix offers an alternative. You can set the directory
permissions more restrictively (1730) and install an additional program, called postdrop, provided to run
setgid. You will have to create a special group that has no members and set the mail spool directory's
group to the unique group you created. Postfix will automatically run postdrop when it detects that the
spool directory write permission is restricted.
You will need to copy the correct script into place to enable one of the submission modes. On my
system there are many mail accounts, but very few local users (only administrators), so I chose the first
option. From the /etc/postfix directory, type:
# cp postfix-script-nosgid postfix-script
Once you have selected your submission mechanism and you are satisfied with your configuration, you
can start your Postfix daemons:
# postfix start
The first time you start the application, you will see warning messages as it creates its various
directories. If you make any changes to configuration files, you should reload Postfix:
# postfix reload
Although the distribution does not provide an installation script, handling it manually is quite simple and
perhaps provides a better understanding of the program as a whole. In addition to the configuration
discussed above, there are a number of other options that deal with virtual hosting, antispam, resource
controls, and address manipulation.
One issue that might affect your decision in considering a switch to Postfix is that there is not yet any
commercial support for the product. If you now have support from your system vendor, or if you have
contracted with a third party for Sendmail support, you will probably be on your own for the near future if
you run Postfix. On the other hand, Postfix provides a stable and secure mail system that is easy to set
up, yet provides most of the flexibility of Sendmail. It is a new application that has not had much
experience in the real world, but based on its design and initial performance reports, it is an application
that has tremendous promise and is probably worth an investment of some time to investigate its
potential for your site.
References
http://www.alphaworks.ibm.com/

About the Author

Kyle Dent is the founder and owner of SeaGlass Technologies, Inc. a company specializing in secure
Web hosting/development and Internet/security consulting. He can be reached at: kdent@seaglass.com.
Copyright © 2001 SysAdmin Magazine, SysAdmin Magazine's Privacy Policy,

Comments about the website: webmaster@sysadminmag.com
SDMG Websites: C/C++ Users Journal, Dr. Dobb's Journal, MSDN Magazine, Sys Admin, SD Expo,SD Magazine, Unixreview.
com, Windows Developer's Journal

Postfix Master (Documentation)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Postfix Master (Documentation)

Uploaded by

Copyright:

Available Formats

The Postfix Home Page

The Postfix Home Page

● Postfix China home page.

http://www.subneural.net/postfix-master/non-english.html (1 of 4)01/16/2005 15:45:45

● Postfix documentation by Xavier

● Postfix UCE howto by Istvan

● Postfix Indonesia user group,

http://www.subneural.net/postfix-master/non-english.html (2 of 4)01/16/2005 15:45:45

● Un pinguino per postino (Italian

● Documentation, mailing list and

● Korea Postfix user group.

http://www.subneural.net/postfix-master/non-english.html (3 of 4)01/16/2005 15:45:45

● RPM's, mailing lists, and other

● Postfix howto document by

● Postfix, MySQL, SASL howto by

http://www.subneural.net/postfix-master/non-english.html (4 of 4)01/16/2005 15:45:45

Please choose a Postfix Web

http://www.subneural.net/postfix-master/web-sites.html (1 of 2)01/16/2005 15:45:46

Amsterdam Plains Japan, Tokyo

http://www.subneural.net/postfix-master/web-sites.html (2 of 2)01/16/2005 15:45:46

Please choose a Postfix

http://www.subneural.net/postfix-master/download.html (1 of 2)01/16/2005 15:45:46

Latvia, Riga USA, CA, Bay area Indonesia, Jakarta

Wietse's own site

http://www.subneural.net/postfix-master/download.html (2 of 2)01/16/2005 15:45:46

Postfix Mailing Lists

QUICK LINKS on-line archives | mailing list subscription | non-english

● Send mail to majordomo@postfix.org with content (not

Note: you do not need to specify the [ and ] or the text

● postfix-announce@postfix.org: READ-ONLY list for

Open subscription, no posting.

● postfix-users@postfix.org: General discussions about the

http://www.subneural.net/postfix-master/lists.html (1 of 2)01/16/2005 15:45:47

Open subscription, unmoderated posting by members

● postfix-users-digest@postfix.org: daily mailing of articles

Open subscription, no posting.

● postfix-devel@postfix.org: for people who design,

Open subscription, unmoderated posting by members

● German: Postfixbuch mailing list, for the book by Peer

http://www.subneural.net/postfix-master/lists.html (2 of 2)01/16/2005 15:45:47

Postfix in the Press

● Duane Dunston: "Catching up with Wietse Venema,

● Elinor Abreu: "Behind the Big Blue Wall". The Industry

How the release of Postfix (Secure Mailer) helped IBM to

● Andrew Leonard: "How Big Blue fell for Linux". Salon

http://www.subneural.net/postfix-master/press.html (1 of 3)01/16/2005 15:45:47

This is the first article that recognizes Postfix (Secure

● Cameron Laird and Kathryn Soraiz: "Postfix and Mailman

● Kurt Seifried: "Postfix - the Sendmail replacement". Kurt's

● Kurt Seifried: "Postfix - The Sendmail Replacement, Part

● Cameron Laird: "Venema aims to make network software

● Mark Durham: "Q&A: Wietse Venema". Sendmail.net,

● Gregor Longariva: "Postfix - der Sendmail-Ersatz?

● Mick Bauer and Brenno de Winter: "Using Postfix for

http://www.subneural.net/postfix-master/press.html (2 of 3)01/16/2005 15:45:47

● Kyle Dent: "IBM's Secure Mailer". SysAdmin magazine,

http://www.subneural.net/postfix-master/press.html (3 of 3)01/16/2005 15:45:47

verification ● Cyrus (*)

Add-on Software ● LMTP (*)

Becoming a mirror site Support Other topics

http://www.subneural.net/postfix-master/documentation.html (1 of 2)01/16/2005 15:45:47

(*) These documents will be made available via http://www.postfix.org/ and

http://www.subneural.net/postfix-master/documentation.html (2 of 2)01/16/2005 15:45:47

Postfix Howtos and FAQs