Slashdot Mirror
Postfix
Postfix is a complete Mail Transfer Agent (MTA) that is meant to be a replacement for Sendmail. Wietse Venema, who works at the IBM Watson Research Center, wrote the program and released it under the IBM Public License. Richard Blum has targeted this book at Intermediate to Advanced users, but he has enough basic information so that even an MS Exchange administrator with no Unix background can get Postfix running quickly.
The book is broken into three sections:
- Introduction to E-Mail Services and Postfix
- Installing and Configuring Postfix
- Advanced Postfix Server Topics
Part I is a nice overview of email, how to use Postfix, how Postfix
works and a comparison of Postfix and Sendmail. In chapter 3 'Server
Requirements for Postfix' an overview of Unix and Unix commands are
covered along with an introduction to bash,
gcc and make to bring the non-Unix user up
to speed with the tools that they will need.
The chapter on DNS starts by covering the origins of DNS and the
basics of how it works. Blum then gives us an explanation of DNS
records and how to set them up, including the all-important MX (Mail
Exchanger) record. He then gives a brief discussion on how to set up
the resolv.conf, hosts and
hosts.conf files. The chapter concludes with a quick
look at the host, nslookup and
dig programs. This chapter serves as a quick reference
on getting DNS up and running on a Unix box.
Part II is a detailed section that is the heart of the book. How to set up Postfix is laid out in detail from how to install (both from an RPM file and from source), to configuring it, to logging and blocking UCE/UBE.
One of the sections of the book I was drawn to was on how to set up Postfix as an internal and external mail server for the Small Office environment. This could be for branch offices of a large company (such as insurance offices) or for a Small Office / Home Office (SOHO) that does not have a full time Internet connection. Blum explains how to set up the server for dial-up to send and retrieve mail, and how to run the mail server on the same box as your firewall.
The chapter 'Migrating from Sendmail to Postfix' is a short step-by-step on how and what to convert from Sendmail to Postfix. Since Postfix was designed to do this easily the chapter is shorter than might be expected (only 20 pages).
Rounding out Part II is a chapter on the Maildir mailbox format and a chapter on using an external MDA. The chapter on using an external MDA is a good example of why I like this book. Here is the full Table of Contents for the chapter:
- Using MDA Programs with Postfix
- What is a Mail Delivery Agent
- Automatic Mail Filtering
- Automatic Mail Replying
- Automatic Program Initialization by Mail
- Using an External MDA Program with Postfix
- Configuring the
main.cffile
- Watching MDA Programs in the Postfix Log
- The
procmailMDA Program
- Installing
procmail
- The
procmailCommand Line
- User-Defined
procmailActions
- Summary
In this chapter Blum gives a nice quick How-To on
procmail. While it is not a full treatment of procmail it
has enough information to download, compile, install, configure and
run procmail. Coupled with the brief lessons on Unix,
gcc, make and bash in the first
section, an MS Exchange administrator on their first attempt in the
Unix world is provided enough information to get procmail
working as the MDA for their new Postfix MTA.
Section III covers advanced server topics including using MySQL,
OpenLDAP and Majordomo with Postfix. Like the section on
procmail, Blum covers installing and configuring each of
these applications and how to make Postfix work with them. Chapter 20
covers POP3 and IMAP, which then leads nicely into the next chapter on
SqWebMail. The final chapters are on performance tuning and
troubleshooting.
Overall I have found this to be a well-written book that addressed several questions that I had about configuring and using Postfix (such as the SOHO section). It is clear, direct and covers each topic to a level that I found comfortable. For some people this book will be too advanced but that should not be anyone who has a working knowledge of mail servers or of Unix. I would recommend this book for someone who has started to use or wants to migrate to using Postfix.
My major complaint about this book is the price, $49.99. As much as I liked this book, 'Practical UNIX and Internet Security' was more densely packed with information and only cost $39.95.
Table of Contents- Introduction
Introduction to E-Mail Services and Postfix
- E-Mail Services
- Postfix Services
- Server Requirements for Postfix
- DNS and Postfix
- SMTP and Postfix
Installing and Configuring Postfix
- Installing Postfix
- The
master.cfConfiguration File - The
main.cfConfiguration File - Postfix Lookup Tables
- Using Postfix
- Using Postfix as an ISP Mail Server
- Using Postfix as an Office Mail Server
- Postfix Server Administration
- Migrating from Sendmail to Postfix
- Using the Maildir Mailbox Format
- Using MDA Programs with Postfix
Advanced Postfix Server Topics
- Using MySQL with Postfix
- Using OpenLDAP with Postfix
- Using Majordomo with Postfix
- Using POP3 and IMAP with Postfix
- Using SqWebMail with Postfix
- Performance Tuning Postfix
- Common Postfix Problems
You can purchase this book at Fatbrain.
Actually, postfix only really supports Maildirs in your home directory (unless you use a .forward file). However, I have a patch to postfix which will allow you to send to Maildir's in the spool much more easily.
Mail me if you want it.
-Dom
You know? None of these books ever seem to include sections devoted to blocking SPAM. As a sysadmin, this is one of the most important topics I think could be covered. Maybe they leave it out intentionally so they can send you spam and try to get you to buy their book :)
I personally like Postfix because:
If your needs are simple, and you need only set up a DMsomehost.to.forward.to entry for Sendmail, Sendmail's easy to configure, but things instantly get a whole lot hairier.
And I've never had good success with EXIM, and every time I've configured qmail it has been a hassle.
It seems dangerous to compare Postfix to qmail; spectacular flame wars have broken out between the respective authors...
If you're not part of the solution, you're part of the precipitate.
Why Postfix rather than Exim? (Assuming sendmail (security holes, cruft) and qmail (non-free) are ruled out.)
-- Ed Avis ed@membled.com
[chomp] Mmmm... flamebait.
Most of these links seem to rather argue with your assertion that the best is qmail. First we've got a somewhat biased comparison (the "Life with qmail" document is probably not the best source for honest comparison) that still doesn't really claim one being better than the others.
Next up we've got another MTA comparison that claims postfix is nearly three times faster than qmail. Heh. Whoops.
Then we've a comparison between mbox (standard Unix mailbox format) and mailbox, qmail's format. This is a nice comparison, but doesn't help the argument much since postfix groks the mailbox format as well.
Finally we've a complaint from the author of qmail about how postfix handles the mail spool. Of course qmail's author's behavior is, unfortunately, a factor you must consider when choosing which MTA you want to use. There's a bit too much attitude there for my taste. I've never liked dealing with authors (or products) who have to prop up their work by tearing down others. It's one thing to say "I think my tool is the best" and quite another to say "My tool is the best because the others suck."
Additionally, the gaping hole described can be closed by runtime configuration. You don't have to run with world-writable mailboxes. It's also worth noting that if you're running a "closed" mail system (where users never log in directly to check their mail, but instead use IMAP or POP3), it's not a security risk at all (since only root or other privileged (and hopefully trusted) users would be granted access in the first place).
Read my stuff.
Obviously the most subjective part of this whole discussion is the behavior of the author(s) involved. That's something each individual administrator has to decide on. I don't quite feel comfortable putting my mail system in the hands of someone who gets so riled up about his product. I get the impression he's perfectly willing to put his users unwittingly in the line of fire to prove his point. It's just my opinion; you'll undoubtedly feel the need to offer corrections to it, but my perception of qmail's author just brings to mind one of the Things I Will (not) Do when I am an Evil Overlord ("I will never utter the phrase 'what? How can this be? I'm invincible!!!' as it will almost certainly be immediately followed by my horrific destruction").
Yes, I've heard of this "root hole in POP3 or IMAP" concept before. Funny thing is I don't recall any particular MTA being the cause. A qmail system is just as vulnerable to such exploits as a postfix system is when the actual exploit involves Cyrus IMAP, for example. Both MTAs will happily sit there and do absolutely nothing, since accessing one's mail once it's been delivered is a task neither MTA cares about.
Let's go over your other points.
I counter that postfix is also quite good:I am afforded an equal amount of good sleep by postfix; hasn't flaked on me yet, and I don't expect it to.
We're comparing very similar systems here. They're both setting out to do the same things, and it looks to me like they're both accomplishing what they've set out to accomplish. Bickering over each system's choice of implementation is a waste of time. If an implementation proves inappropriate, it will over time be fixed or abandoned.
Holy wars suck anyway; perhaps your time would be better spent away from embarking on one here. If you're game for an attempt at an objective discussion of the merits of the individual systems, then great, I'll carry one on as well. But if we're going to jump into a nasty flamewar (that the qmail & postfix communities have seen far too many of anyway), I'll respectully bow out here.
Read my stuff.
No, I'm not making him out to be a monster. I'm pointing out that his behavior towards the uninitiated is an important factor in deciding whether to try qmail or not.
I agree that mailing lists aren't the best place for newbie questions, but I detest those who are completely intolerant of idiotic questions. I'm the senior system administrator at my office, and I get my share of stupid questions from people. My first response isn't to just blast the questioner for daring not to know some little detail, or even overlooking instructions clearly given about how to accomplish what they're trying to do (it's my second response ;).
A mailing list is no different. If you get the same question asked over and over, stick it in a FAQ. Then when it's asked again, politely refer the questioner to the FAQ. You don't abuse somebody just because they don't know the answers you have. You lose users that way, and foster plenty of negativity towards the product.
I've had my share of frustration with users. I've been sorely tempted to blast the morons out of my lowly cubicle with a scalding assault on their brainpower and family heritage. Guess what? I hold back. In the case of work, I know better than to blow up at somebody; it's an excuse for them to complain, an excuse for my boss to write me up, and a reason for the office culture to shift enough that my skills & experience aren't sought anymore. In the free software world, all you've got is the support of your users. Alienate them, and you're toast.
By the way, cool lcd project...worthless but cool.
Thanks! :)
Read my stuff.
Well if you'll notice, not only is the software package named Postfix, but so the title of the book is Postfix as well.
-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d? s: a-- C++++ UL++++ P++ L+++ E- W++ N o-- K- w--- O- M+ V PS+ P
If you look at the sendmail exploits they almost all involve handing mail off to external programs and mailers. Postfix, Qmail,etc do not do anything that prevents the same sort of configuraion problem.
Also any program the delivers mail will be running with high privliages. You must be root to bind to port 25 therefor you must run as root to bind to port 25. To drop mail into the system mailboxes you must have privliges that allow you to do that too. Some systems you can simply be the member of the mail group and on others you must be root.
It wasn't the entirety, just the relevant portion. /. removed about half that post also.
I can throw myself at the ground, and miss.
I don't know about you, but I have been doing this for the past three years, and the people just need to learn to RTFM. I'm close to burnout, I need a vacation, and I have two NT machines to secure properly, where smb *must* be available. I have been trying to get the local MCSE to learn to use Linux, and they will not learn unless I read out each line of the manual, grep through the two relevant man pages for what they need, and then have them abuse me for taking so long to show them exactly what to do.
They want to install X and VNC to admin a Linux machine, want telnet and will not use ssh. I have tried not to be a BOFH, but now I am going to be one.
Yes, I need a life, and I am going to get it.
Your sarcasm is deserved in the comment, and I am sorry for the whining, but I really can't help it right now.
I have had a bad week, fixing those NT boxen, and I really mind the customer support division tossing customers to me when I am trying to fix problems.
and to the AC who flamed me for not posting a link, I copied from my mailbox, something whichI will not provide a link to.
I can throw myself at the ground, and miss.
For sendmail, the program that deals with the user is the same as that hands off to the any other external program and the same that delivers to user mailboxes.
For postfix and qmail, these are separate programs which don't trust their input.
The Postfix delivery agent does not deal with the external world except through the smtpd process.
This modularization makes for a greater extent of security than for sendmail, where the interactions are possibly more complex.
I can throw myself at the ground, and miss.
It depends on what you need.
Essentially:
Sendmail: A single bulk monolithic program that runs as root, has a history of cruft and security holes. Has a very complex config file, which you can easily mess up and turn to an open relay.
Earlier versions used to have relaying turned on, the newer versions are far more secure.
Qmail: A very paranoid MTA. Designed to be secure.
Very much in line with the authors preferences. Mainly delivers to maildir formats, will send single recipient mails. Wastes bandwidth, and since that is expensive, I don't use it.
Postfix: As paranoid as Qmail, unde active development, and doesn't waste all that bandwidth.
MS: I have no idea.
I can throw myself at the ground, and miss.
They aren't the default, but all you have to do to enable them is to add a / at the end of your spool directory.
/var/mail -- mbox format.
/var/mail/ -- Maildir
I can throw myself at the ground, and miss.
There have been a few reviews on the Postfix mailing list of the book. The overall recommendation is: The book is not as good as the mailing list, but better than the docs. It doesn't maintain consistency throughout, and has a few typos.
Search the mailing list archives for details.
(Yes, I know I should be posting links, but I have now decided to get people to RTFM and learn to search. I am tired of spoon feeding lusers, and need a break).
Quoting Ralf Hildebrandt:
Today "The" book arrived. I flew over the first 11 chapters and found
the following errors/omissions:
b) p 48: What is the "spawn" program?
c) p 32, table 2.2: mail is NOT a queue. It's the mailspool, or a mbox
file, but not a queue.
d) p 31, listing 2.3: column chroot() shows "never" instead of the
default "yes" that I know.
Quoting Jeffrey Taylor:
It is more tutorial than reference. However, it repeats running
postmap everytime a new map is introduced and telnet sessions for most
forms of sender/relay/spam restrictions. THis makes in a reference
where you may not have read the previous examples. It gets tedious in
a tutorial that is read cover to cover.
IMHO: It is worthwhile, I'm not unhappy I bought the book. It feels
padded (see above). It is beginner thru intermediate, not much
advanced or tricky. I found it more useful than the docs and less
useful (and less over my head) than this e-mail list. I have a small
system, 200-300 messages per day and the chapters on MySQL and LDAP
only served to convince me I don't need them.
e) p 29, figure 2.2 is wrong: Lookup tables interact with the "utility
programs" (e.g. postmap, postalias!)
f) p 97 lists non-RFC conformal command syntax ("RCPT TO:haley"
instead of the correct "RCPT TO: ")
g) p 97ff list lots of bizarre SMTP commands, but the text never
actually tells the read if Postfix implements those. Lots of
bla-bla.
h) p 108 says for "The AUTH command": "The administrator must maintain a
separate username and password database that allows authentication of
remote SMTP clients."
This is not true, it can use any PAM authentication method!
i) p 171 The text for relay_host fails to mention that [] prevents a
MX Lookup of the address/hostname in the brackets!
j) p 174, table 8.1: append_at_myorigin appends (obviously) $myorigin,
not $mydomain
k) p 204, table 9.6 fails to list an all numeric LHS being equivalent
to "OK"
l) p 214 table 9.8 "virtual domain record types" fails to list the
form "@domain @otherdomain"
I can throw myself at the ground, and miss.
The book covers lookup tables which can be used to reject messages based on their content, which handles much of what Procmail would do, with the advanatage of not actually accepting the message.
It would be interesting to see some benchmarks between the different opensource MTAs w/ comparison of the available features for each major MTA (ie. Sendmail, Postfix, Exim, Qmail etc).
Sorry to hear it didn't have Venema's blessing, and it could do without the holy-roller dedication page, but bottom line I don't regret the "buy" decision.
--
"Ain't no right way to do a wrong thing."
I am running Postfix on my machines for two years now and never wanted to use any other MTA. Its documentation is very complete so chances are good that you don't need this book. The FAQ covers most aspects and the rest can be deduced from the manual pages. If you are running sendmail do yourself a favour and take a look at Postfix.
At the beginning was at.
We are currently using Postfix. It was pretty easy to set up and once we got over a small DNS issue it work smooth and fast. Looking forward to getting my hands on a book though. The literature available for it on the web is limited to rehashes of the .conf file. A real hardcopy text will be nice to have.
Okay, it's too damned early in the morning to be getting repetitive and surreal in your opinions. What the hell is with "Postfix (and Postfix)"?
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
I just skimmed things a bit, but somewhat suprised not to see topics like ssl and smtp-auth. I know I would have loved to see something like "your mail server is your first line of defence for Outlook Transmitted Diseases," but since it's mostly a procmail thing maybe it's mentioned. I encourage ever e-mail administrator to at least look at Email Security through Procmail. By using this, I've managed to keep my network OTD free. :)
I'm going to go back in my box and will think within the limits of my box: MS Sucks Linux Good I read too much Slashdot.
I think it should be noted as well that Richard Blum never once got in touch with Wietse Venema, the creator and maintainer of Postfix. I am willing to bet there are a number of bugs in the book that could have been avoided. Likewise, some of the more esoteric issues, such as DNS issues are completely cut out. For these, the postfix-users mailing list has to be used. Personally, I'd save my money and wait until the book with Wietse's blessing is released (and there is apparently one author working with him now -- though no other info has been released).
If there was a "-1 Not Funny", that'd be my most used mod.
I read the opposite, has far as postfix being 3 times faster, I saw no supporting evidence at the site to prove that postfix was any faster. As far as DJB's behavior, I see no attitude, only truth and well thought out opinion. He doesn't just come out and say something sucks, he says it and proves it. Ever heard of a root hole in POP3 or IMAP? Yes. I figured you had.
Qmail is the best.
1. Easy configuration - Read LWQ
2. Easy administration - Read LWQ
3. Security. qmail doesn't seem have any root holes per bugtraq.
4. Fast, proven by many large sites.
5. Great support for those who ask well researched questions.
6. Maildir (not mailbox) format much better than mbox. Usuable over NFS, non-blocking.
I don't worry about my qmail servers. I sleep well at night knowing that they aren't going to break.
What is pirate software? Software for inventory of stolen treasure?
You're right: what can compare with the thrill of writing software in a language in which every string manipulation or memory deallocation potentially opens up security holes. And nothing can compare with the dazzling display of software artistry in a language where every data structure has to be handcrafted over and over again.
Using a language that is just a tad more modern than the nearly 30 year old C programming language clearly couldn't compete with that kind of thrill. But maybe using something more modern would result in a program that's less than 100kloc and that more people can contribute to and modify safely.