Slashdot Mirror
Postfix
Fortunately, my first needs were simple and I came to realise that Postfix was a much easier system to install and maintain. Now that my needs are more complex, I was glad when this book hit my desk at exactly the same time as I started upgrading the corporate servers from Mac OS 9 to OS X Server.
Postfix: The Definitive Guide seems to fit the bill. It is a well-written and well-constructed guide to mail systems in general and Postfix in particular. (Oh, and speaking of definitive, could someone at O'Reilly provide a definitive answer to both reviewers and their own editors as to that colon? This is the second 'Definitive Guide' I've reviewed in as many months, and they are sprinkled with instances of each book's title, sometimes including that colon, sometimes leaving it out.)
The book starts with a good overview of the underlying technology in Chapters 1 and 2. I can't blame Dent for my slight confusion in the section on addresses and headers - having RFC822 superseded by RFC2822 was just a little too much coincidence for this particular "bear of little brain." He then follows it with a chapter discussing Postfix's architecture, important since Postfix uses a much more modular approach than the sendmail monolith, with each part of the mail handling process a different executable and the single queue turned into five.
Once the background is well covered, Dent then gets onto the nitty-gritty of configuring and administering Postfix. He has certainly covered everything I needed, including spam handling, multiple domains, relaying, SASL authentication and using LDAP. Once I'd finished grokking all that, and getting it integrated into my servers, I had a corporate email system up in three sites that replaced and improved upon a couple of thousand dollars worth of proprietary dreck. Happy is an understatement.
Dent's writing is sometimes a little patchy, though never bad. The technical detail does seem overpowering in places, though, and I occasionally found myself reading a section through more than once with a configuration file open in front of me. There are certainly spots where a little more hand holding and care with the writing would have been appreciated. (If you are a little more cognizant of the interstices of mail systems then you may not have the same problem.)
I did, however, appreciate the appendices enormously. The four appendices cover configuration parameters, Postfix commands, installation, and an FAQ. My system came with Postfix compiled and installed just as I required it so I didn't get a chance to thoroughly test out Dent's installation procedure (though it looks good); the other three continue to be useful.
If you want to have a look for yourself, then the usual O'Reilly page is complete with a table of contents and index, but this time no example chapter is provided (how come, O'Reilly?). You can also get an expanded version of the FAQ in Appendix 4 from Dent's website. A better example of Dent's writing style is an excellent article on troubleshooting with Postfix logs at O'Reilly's Onlamp.com.
This is an excellent book, Dent has explained the underlying methodology and use of Postfix well, taken the reader through all aspects of this MTA system and explained both the why and the how. I would recommend this book (and, as a result Postfix) to anyone looking for an MTA and a guide to configuring and running it.
You can purchase Postfix: The Definitive Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Mac OS X users can find a cool, donation-ware (read: non-crippleware) GUI for the buil-in postfix server, Postfix Enabler. It allows some advanced configuration of the postfix server.
It has some handy instructions for setting up Mac OS X's Mail.app to interface with the Postfix server as well.
I had but a simple dream, to destroy all humans.
Check out this article....
p x
http://techie.org/Projects/TNMailServer-Full.as
It has no impossible-to-understand langauge, the options have reasonable names, they do what they suggest... it just works.
Didn't google very well did you?
t m
here you go:
http://www.geekly.com/entries/archives/00000155.h
Good luck.
master.cf: /usr/bin/procmail -p
mailbox_command =
main.cf:
smtp inet n - n - - smtpd -o content_filter=spamfilter
spamfilter unix - n n - - pipe flags=Rq user=spam argv=/usr/local/sbin/spamfilter.sh -f ${sender} -- ${recipient}
Both of which are documented in files linked to from http://www.postfix.org/docs.html
I used this article as the basis for my smtp gateway and it works fairly well:
http://lawmonkey.org/anti-spam.html
So not enabled by default, but easily remedied if you absolutely MUST have procmail. You can also enable it on a per-user basis by leaving those lines commented, and then using a
As for playing with spamassassin or other 3rd party programs, no problem. A quick check of the Documentation page at www.postfix.org reveals all kinds of good info. The consensus on postfix-users is to use amavisd-new, and then call antivirus and/or spam filters from there.
Good luck!
Yup...was very new to setting up an email server. I found this thread very helpful for setting up a simple home email system. Also way down in the thread is help and links for using spamassasin and other heuristic spam filters...
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
You can also use amavisd. In addition to running your mail through spamassassin, this approach also lets you throw a virus scanner into the mix.
here's a link
Technology Consulting & Free Downloads
in master.cf:
# add at beginning
smtp inet n - n - - smtpd
-o content_filter=filter:dummy
# add at end
filter unix - n n - - pipe
flags=R user=filter argv=/usr/local/bin/postfix-filter.sh -f ${sender} -- ${recipient}
#
# filter shell looks somthing like:
FILTER=yourfilter
cat > inp.$$ $FILTER < inp.$$ > msg.$$
exec $POSTFIX "$@" <
Disclaimer: My buddy works at bookpool (but their prices really are great!)
I've been using this book to migrate our existing sendmail gobbilygook mailsystem to a sane well documented postfix system and I've found the book to be a great help as I've had to do a one to one comparision between sendmail and postfix for configuration stuff.
Plus Dent's writing style is excellent and the book is well laid out.
Yes Francis, the world has gone crazy.
I agree. There is a world of difference between the Postfix and Sendmail. /etc/whatever" kind of guy whenever a service needed to be configured or tweaked. As I've got older I've learned to appreciate good tools for the system administration. One of the best (IMHO) is the Webmin. It has an awesome Postfix configuration module and it takes 10 minutes to have (non-trivial) mail-server up and running. But even with the Webmin Sendmail is still a bitch to configure.
Many years ago I was "vi
Darwin doesn't use the FreeBSD kernel. It has its own (open source) kernel based on Mach, so it has nothing to contribute back to the FreeBSD kernel.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
It says "mod this up" in tree format. At every fork, process the left branch, then the right, then the node at the fork itself. When you reach a leaf, use that letter. Later, rinse, recurse.
Performing post order tree traversal on this tree yeilds:
modthisup
For those of you too long out out CS class, just remember: left, right, root.
-- Fighting mediocrity one bad post at a time.
Richard Blum wrote one - it's now quite outdated.
Ralf Hildebrandt & someone else (sorry, forgot who) are working on another very current Postfix book as well. Keep an eye on Amazon.com for it.
I've also read the O'Reilly Postfix book and found it to contain a lot of information. It's nice to have around.
I'm a real big fan of Security Sage's postfix configuration. The cover pretty much everything interesting regarding Postfix except LDAP. Jason
Jason Wohlford
http://netbsd.org/gallery/products.html#darwin
FreeBSD or NetBSD is more than the kernel alone. Contributing to either doesn't have to be in the form of changes to
Now "some useful changes" might be a man page type correction... I don't know. You're welcome to scan Net's cvsweb.
I ran sendmail for nearly a decade at various jobs and on various systems. I switched to Postfix a few months ago after trying out SuSE 8.1 Linux (love it, btw) and I'm hooked! I now run Postfix as an Internet-to-interior "smtp firewall" between the Internet and my internal Lotus Domino servers, and the pcre body_checks filters that became available in the first couple days of the MyDoom virus storm proved to be invaluable in keeping about a thousand viruses per hour from being relayed thru my SuSE Linux/Postfix "smtp firewall" and hammering away at the Trend Scanmail antivirus on my Domino server.
Postfix seems ok, I'd recommend it for folks setting up straightforward machines who didn't know sendmail
But people whine that "sendmail is too complex" and at the same time they WANT complex things to happen.
I had a guy come up to me at an event and shout:
Guy: Sendmail is too hard.
ok
Guy: and is there any way to make it only send large (> 1MB) messages out after 7PM when my ISDN rates are lower?
sure. 5 lines in your m4 file.
Sendmail.cf is a binary. It is intended to be read and parsed quickly by a binary. Sendmail still runs on 4MB Sun 3 machines. You don't edit /bin/ls to effect a change there, you edit "ls.c". .mc file to effect a change in the .cf.
Similarly, you edit the
More, when sendmail changes major revisions (eg. you fianlly move from Sendmail 8.8 to 8.12), you regen your .cf and, barring some minor changes to remove defunct features or take advantage of new ones, you have a new working .cf file. You can't just move a 8.8 cf file to an 8.12 machine and expect it to work well and use new features.
Having worked on HUNDREDS or THOUSANDS of config files (one set went onto 10,000 machines at a site), there's NOTHING you can do in the .cf that can't be done in the .mc.
That said, the rule language is painfully ... complex? No, just the opposite. It's painfully simple. My experience with 6502 assm and a BASIC that had neither ELSE nor AND/OR options helped to make me really good at writing sendmail rules.
Dealing with booleans (just to ruleset^Wsubroutine saving buffer, put time in buffer.
Is message less than 1MB? then return
is time after 1900 hrs? Yes? return dsmtp.
Is time < 700 hrs? Yes? return dsmtp.
Otherwise just return.
In calling routine, look for return value and if it's dsmtp, put the saved buffer to the dsmtp mailer. Otherwise continue with the saved buffer.
Hard? No, not really.
Painful? You betcha. I'd love to have variables and ANDs and ELSEs. I've taken to putting complex logic in a perl milter at the RCPT TO phase and calling it a day.
sub choosemailer {
if ((($time > 1900) || ($time < 700)) && $size > 1MB) THEN $mailer=dsmtp
}
But the rulesets are just read by a parser. It's not rocket science (just computer science).
It would be nice to have (perl) regex's and such built in.
And that's where Postfix starts to have an advantage. I can live without UUCP for that. I'd just hope that new sendmail versions might rethink the whole language for processing mail. It's good to have competition. (qmail2 also looks promising to raise the envelope).
But lets just recall that's its not about Sendmail vs postfix vs exim vs qmail.
It's any of these VS Exchange/Notes/Gropewise. And we're losing.
While a lot of the comments here (at least those +3 and above) mention Postfix's ease of management vs. that of Sendmail, one point that hasn't received a lot of attention is how the two compare in terms of efficiency. My experience with Sendmail in a high-load environment tells me it's a monolithic, bloated, resource pig. But that was when I was still somewhat new to the admin game, so I'm sure with some expertise it can be tuned.
Postfix, on the other hand, 'out of the box' was wonderful, (not to mention easy to use) and when I learned to tune things like filesystem parameters, optimal disk subsystem layout, and such it only got better. Our Postfix installation where I work continues to amaze me with how much mail it processes each day, with little or no maintenance, even under heavy load (1M+ incoming messages/day between 5 dual-CPU, 2-disk SCSI PIII-class machines). My gut feeling is that with some beefier boxes, and a pile of disks I could get that down to 2 machines handling the same amount of traffic.
Another plus for Postfix is its flexibility, and, if you need to get so deep, its hackability. The code is extremely clean, modular, and easy to work with.
If you wanna spend a couple of bucks, try cpanel. Its webmin on steriods.
Selling software wont make you money, selling a service will.
I agree, the original comment about why I had the time to review all those books *was* funny.
The comment I was replying to was the one accusing me of being a "paid shill".
Tony
One better... :)
:) )
I had also known Sendmail was a little tedious to learn. My main job is software development, but we are a small company so I multi task as system admin for about 10 systems, mostly Linux with a couple of internal windows systems.
None of the email systems are REAL painful to get working, even Sendmail. I can learn and understand these types of things easily with the years of experience I have. The thing is in a small company I have to squeeze every minute I can out of a day because my time means a lot. If I can spend half the time learning the ins and outs of a particular server app I am doing a good thing. So when I had to set up our first non shared systems in a data hosting facility I was very happy.
I decided QMail had enough of a popular following and a reasonable enough featureset and great security track record that we could live with QMail. So I installed QMail, read books, tweaked and eventually installed. Got everything working: SMTP+POP3 with selective relaying based on who had just popped. Worked great. Then it came time to set QMail up on a different server as we were shuffling services around to free up the server we currently used for mail. I was not looking forward to doing QMail again. I didn't like managing it the way we had it set up and didn't really feel I had the time to mess around with it, so I looked for alternatives.
I found Postfix. I downloaded it, compiled it, installed it and read through all of the configs and docs.Within an hour I was so amazed at the simplicity of Postfix and how much sense the configs made, I was in shock. Then I read a little more and searched around and found how easy IMAP was to get working as well. I then found an IMAP server that supported MySQL and found that Postfix also supported MySQL for domains/user configurations. That is all it took for me to be completely sold. I would have preferred more options for the RDBMS, but I wasn't going to complain much.. MySQL isn't to resource hungry. Performance wasn't a concern as I only needed mail for a pretty small group of people. As it is this setup is very READ heavy with the data being almost static (just needing a nice easy programmatic way to be updated when required) so it plays nicely into MySQLs performance forte.
In one day of configuration and code writing I had Postfix doing all of our SMTP, Courier IMAP (which includes POP3) all on the same backend. I had web mail setup and working. All of our mail storage was now centralized which only makes it easier given some of us travel around a lot and still need our mail.The best part, I wrote a web based management tool to manage domains, accounts, and aliases for our mail system. No more unix command line, log onto the application fill in a form or two and its done. Setup a new domain for email? Fill in a few forms and voila it's all done. I think it was one of the most pleasant experiences setting up a network service I administer I have ever had. (I realize that I am a programmer and not everyone will have the knowledge to hammer out a management tool in a small timeframe like that, but for us it simply works).
Thats my story for Postfix!
(P.S. we just have our system send a welcome email and the Maildir folders automaticaly get created after the first incoming message. Postfix handles this for you.
Jeremy
...Postfix.
.forward etc etc).
.forward) to forward to SpamAssassin and finally deliver mail to the user.
http://cr.yp.to/maildisasters/postfix.html
http://cr.yp.to/qmail/venema.html
And after reading and realizing how some of the fundamental issues with Postfix were neither acknowledged nor understood by the author of Postfix (at first), I'm not sure if I really trust its security.
I have nothing against Mr Venema, infact, I've used TCP Wrapper for a long time now.
On the subject of Sendmail vs. the world, I think after 7 yrs of using Sendmail I feel quite comfortable with it. One thing I wish Sendmail was better at was the use of resources like Postfix and specially qmail.
I keep thinking about making the switch to qmail or postfix but I can never find the time to learn any new stuff these days. I would have to learn it well too so I can do all the things I currently can with Sendmail e.g. virtual hosting, mailing lists, RBLs, SpamAssasin interface via
My current mail server setup is:
smptd (www.obtuse.com, small, fast, secure) for the front end (listening on port 25) which uses sendmail for the delivery, which in turn uses procmail (via
Postfix is very good and not crippled by stupid DJB style "licenses" like qmail. I'm using in on all my boxes (FreeBSD, Linux) and one of them delivers large amounts of mail. Very fast delivery, supports all kinds of stuff (maildirs, MySQL, LDAP, delivery to Cyrus, etc.) has some builtin unsolicited bulk email controls and some resource controls and it doesn't require 1e13 users on the system like qmail does. I'm surprised people still use Sendmail (and argue that it's somehow "better"). Very cool piece of software. I'd like to thank Wietse Venema and IBM for it.
Some would argue about the license (especially BSD people who also argue about GPL being not liberal enough) but it's OSI approved so most arguments are vapour.
here is a fine guide to build a Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC.
You can follow the steps and build it with Linux too. This entire procedure has been developed with security as a primary focus. These are the main tools it shows:
Mac OS X users could alternatively safe the money and read a description of how to enable postfix on OS X for free in ten minutes. In Panther, it's just one or two lines in configuration files, essentially. If you want SASL authentication and other things, the nicely-designed GUI of Postfix Enabler is probably worth a few bucks!