Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

The Book of Postfix

Posted by timothy on Wed Jun 29, 2005 03:15 PM
from the danny-boy dept.
danny writes "Do you run a mail server using Postfix? If so, then you should check out the latest addition to my book reviews, a look at Hildebrandt and Koetter's Book of Postfix." Read on for the review.

When The Book of Postfix arrived, I jumped straight to the chapter "Understanding SMTP Authentication", since that was something I wanted to get working. This explains the problem -- how to allow travelling users with unknown IP addresses to send mail through a mail server without opening it up to spammers -- and clearly lays out the options: SMTP-after-POP or -IMAP, SMTP authentication, certificate-based relaying using TLS, or some kind of VPN. "If you want something simple, independent, and secure, SMTP AUTH is probably for you."

The remainder of the chapter explains how to set up a backend for SMTP authentication -- a choice between saslauthd and other options -- and the following chapter then explains how to configure Postfix to use it. This approach is typical of The Book of Postfix, which tackles many topics with paired chapters, the first covering background, theory and any ancillary systems and the second covering the actual Postifx configuration. It also emphasises progressive implementation accompanied by testing, which is most reassuring when modifying production servers.

Other chapters in Part III, "Advanced Configurations", cover running Postfix chrooted, using TLS (two chapters), mail gateways and multiple domains. There's also a chapter that works through building a complete mail system for an organisation. Part IV covers tuning and the appendices cover installing Postfix (for Debian or Redhat Linux, or from source) and troubleshooting.

Moving backwards, the hundred and twenty pages in part II cover content controls. Some basic postmaster background is followed by pairs of chapters on each of message transfer restrictions, built-in content filters, and external content filters. I've been working through these, improving my anti-spam controls, and they're proving really helpful; my next step will be implementing amavisd-new.

Part I explains how to set up a host to run Postfix, with ancillary services such as DNS, NTP and syslog, then how to set up a simple single domain configuration, either on a permanently connected machine or on a dialup machine. It then gives a brief description of Postfix's basic anatomy. Part I is concise -- just fifty pages -- but it offers everything most people will need for a basic setup.

There's no cruft in The Book of Postfix: it's a fairly chunky book, but none of it is padding. Excerpts from configuration files include just the right amount of context and the diagrams (and a very few screenshots) are integrated with the text and tightly focused. Given the scope, it's probably overkill for basic Postfix users, though the first fifty pages would make an excellent "getting started" guide for them.

There are some omissions. There's no general explanation of how the master.cf file works, for example, or of rewriting -- neither "masquerading" nor "canonical" appear in the index or glossary. The "Anatomy of Postfix" chapter could definitely have been more comprehensive.

How does The Book of Postfix compare with the O'Reilly book Postfix: the Definitive Guide ? The Book of Postfix is nearly twice the length and provides much more detailed step-by-step explanations and more on ancillary systems -- it explains how to set up backends for SMTP authentication, for example, rather than just telling you that you need one.

I highly recommend The Book of Postfix to anyone using Postfix and wanting to do more than the basics with it.


Danny Yee has written over 800 other book reviews. You can purchase The Book of Postfix from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • Dumb Question... (Score:5, Interesting)

    by creimer (824291) on Wednesday June 29 2005, @03:18PM (#12944577) Homepage
    Why are mail servers so needlessly complicated? Seems like you have to be a PhD Rocket Scientist to change the most simplest thing.
    • by bizard (691544) on Wednesday June 29 2005, @03:23PM (#12944629)
      Because mail servers are more accurately mail _systems_. Complex interactions between local and remote users, spam and virus filters, strict adherence to standards and allowances for broken implementations of same and most importantly (and hardest to deal with) proper dns configuration and lack of same. Nobody wants to lose any mail, so you have to work with 30 year old mail servers just as easily as last months latest rev.
    • Re:Dumb Question... (Score:5, Informative)

      by toxic666 (529648) on Wednesday June 29 2005, @03:28PM (#12944698)
      Mail servers (I use postfix as a filtering gateway to an Exchange system) are not "needlessly complicated". They are quite easy to set up if all you want are basic, secure mail services.

      However, if you want added functionality, security, filtering, spam / virus control, you need to understand what you are doing if you want to use an open source *nix-compatible mail server.

      If you just want something "easy" (read: click and drool), expose Exchange to the Internet and pay through the nose for security software that is behind the times.

      If you understand how the internals of a richly-functional mail server work, you too may achieve >99.99% spam and virus filtering with 0.0001% false positives. And do it much cheaper.
      • you need to understand what you are doing if you want to use an open source *nix-compatible mail server.

        That's insightful?

        I believe the question was why is it so complicated. You haven't answered it. Why should Open Source or UNIX mail servers be less easier to use than proprietary or non-UNIX systems?
        • Because you can either make it easy (and guess lots of necessary values) and have mediocre to bad performance (overall, not only speed) or you can perform well by asking the user some questions but that kills the "easy".
          • by Nailer (69468) on Thursday June 30 2005, @02:38AM (#12948566)
            You need to justify those statements: why does security and ease of use have to be mutually exclusive?

            People assume these things, and I don't think it's warranted. I think the UI for the security is probably just badly designed. Many people would say Windows sets users up as admins because that's easy, and doing things securely would be hard. But is 'type your admin password to continue' like Fedora or OS X uses really that hard?

    • Re:Dumb Question... (Score:4, Interesting)

      by ZosX (517789) <zosxavius@gmail. c o m> on Wednesday June 29 2005, @03:28PM (#12944704) Homepage
      I'll bite.

      Mailservers are complex that is why. Just take a look at Exim to see what happens when a mailserver gets a bit too complex. In Exim you have this whole transport pipeline that the message must pass through before it gets delivered. Along the way you can change headers, filter for spam, virus check and about a million other things including sender id.

      Thankfully (at least in debian) it comes with a script that will do quite a few basic configurations after asking a few questions. Your e-mail needs may not be as complex as others, but when a site needs a an e-mail server to handle 10,000+ e-mails an hour, streamlining and tweaking the process allows things to be much smoother. I admit I am not anywhere near an expert when it comes to SMTP servers, but I can see the value in wanting to make things run smooth and streamlining the process is a part of that.

      Personally, I've found that postfix is pretty easy to set up and maintain compared to other daemons out there. As far as I am concerned, anything has to be better than configuring Sendmail, though I guess it has become a lot more secure over the years.

      I'm sure others will have a lot more to say on this subject.
        • Basics [postfix.org]
          Standard configs [postfix.org]

          You shouldn't need to really configure much more than that.
          • JFC!!! You're links just proved the parents point.

            Pages and pages of stuff that you already have to understand to understand. I agree, mail servers are needlessly complex. All I want to do is receive mail and send it to 3 users on my machine, and have them be able to send mail via TB to the server without it become a spam relay. Why is this so damn hard.

            Maybe it isn't but they people that document mail servers don't have a clue.

            Why is it so damn hard to have the mail server require a user and passwor
            • Re:Dumb Question... (Score:4, Informative)

              by dodobh (65811) on Wednesday June 29 2005, @04:38PM (#12945411) Homepage
              SMTP AUTH [postfix.org]

              Mail server documentation is written for IT professionals and system administrators who know what they are doing.

              This is not meant for end users.

              And if you had bothered to read those links, they are newbie friendly and actually explain in depth what the changes you are doing do to the mail system.

              Also, MUAs are supposed to submit mail on 587/tcp via SMTP. I recommend you follow that rule.
            • All I want to do is receive mail and send it to 3 users on my machine, and have them be able to send mail via TB to the server without it become a spam relay. Why is this so damn hard.

              The default postfix config that comes with Fedora Core is probably all you need. FC installs sendmail by default, so you need to install postfix and switchmail (and probably dovecot, if you want pop3/imap capability:

              yum -y install postfix dovecot system-switch-mail
              /usr/sbin/system-switch-mail
              rpm --erase sendmail

              A

            • All I want to do is receive mail and send it to 3 users on my machine, and have them be able to send mail via TB to the server without it become a spam relay. Why is this so damn hard.

              Because spammers (read: "the people who shameless use the resources of innocent third parties to shove unwanted advertising down our throat") are getting more clever about finding open relays.

              Yes it sucks, but yes, the moment you're on the net you have to play like the big boys and do everything right.

        • The question is, do they HAVE to be so complex?

          Here's an example: I run a Linux desktop. I have a server that runs a mail server, and use it for sending and receiving email via SMTP and POP3.

          They don't have to be so complex if you're only using it for one or a few users, and especially if you are using it for local delivery only. Postfix is not designed for what you described, so it is a bit of an overkill. Take a look at mailx and TistedMail. There probably others out there as well. I left smail o
    • Why are mail servers so needlessly complicated?

      They're not. If you think they are, this probbaly indicates you have no clue whats involved in running a large mail installation.

      Seems like you have to be a PhD Rocket Scientist to change the most simplest thing.

      Rather ironically I'm currently taking over mail service from a department of Rocket Scientists who no longer have the in house skillset to do it themselves.

    • I supposed it depends on what you mean by "needlessly complicated". Basic mail delivery that works 95% of the time across a reliable Internet is pretty easy.
      • Some complexity is necessary, because mail servers are trying to solve hard problems, like getting the reliability from 95% to 99.999%, detecting failure conditions and responding appropriately, providing various levels of security for the users and for the system, and blocking whatever new trick the spammers came up with this week to get around the
    • When I worked at a webhosting company, I dealt with email extensively (and I still run my own qmail-vpop-courrier-squirrelmail-qmailadmin server). When email would break, and people would call in asking why it took so much effort/time/whatever to fix, we'd have to explain to them:

      1.) Email is the killer application of the internet. Not everyone uses mysql. EVERYONE uses email. Without email, the internet is useless to a large group of netziens.
      2.) Email is the *MOST COMPLICATED* thing that happens on t
    • Just read the Postfix list sometime - people who want to rewrite headers for some virtual domains but not others, then filter those for spam and bounce the spam with a 500-error variant based on the phase of the moon, all the while rejecting 50000-message per minute mail bombs and extracting every 300th incoming spam to convert into a realtime blackhole list, then offering users a choice whether they want TLS or SMTP-after-POP, all the while making sure the CEO doesn't get any spam and that outgoing mail he
    • They aren't. All of the concepts involved with SMTP are complicated, and it takes a complicated system to be able to handle that effectively. Postfix is one of the easiest to configure, but the key here is that you need to know what your goal is. If you don't know what you're trying to do, then sure, any mail system will seem pretty complicated. Setting up any other complicated service with specialized needs (say, a web server, for example) is much the same - you've gotta know what you're trying to do *
  • Great timing (Score:3, Informative)

    by stevey (64018) on Wednesday June 29 2005, @03:23PM (#12944627) Homepage

    I also reviewed The Book Of Postfix [debian-adm...ration.org] this week.

    I also enjoyed it, and recommended it.

  • by DarkFencer (260473) on Wednesday June 29 2005, @03:25PM (#12944656)
    We had been running sendmail as the MTA for our mail gateway (for a medium size university). I had been getting fed-up with sendmail, and have had a collegue raving about postfix for a long time.

    Long story short: This book has let me (in less then a month) not only switch our mail servers over to postfix, but let me do things more efficiently (in terms of stopping spam at the SMTP receive stage) and many other things better then I had with sendmail before.

    I'm not going to make this a sendmail vs. postfix thread, but if you're going to use postfix, this book is a great resource!
    • I tried to setup sendmail a while back and quit in disgust. Postfix on the other hand is straight forward to the point that you can setup all the configuration files without having to copy some strange files that do some magic and actually understand what's going on. Well mostly understand what's going on. :)
      • I must say I'm a little surprised at the strength of the negative opinions on sendmail (in the comments) so far. It's not that bad. I now use postfix or exim as my default mailserver on most machines, but sendmail still has a significant "it's known, it's documented, it's mature, if you can follow the instructions then it should Just Work" advantage. Note that I did say "should". ;-)

        But then I'm usually happiest with Debian's wonderful set-it-all-up-for-me exim-config script :). "Yes, I'm installing a s

  • Grey listing.. (Score:4, Informative)

    by login: (155941) on Wednesday June 29 2005, @03:26PM (#12944673)
    For anyone using Postfix, I would highly recommend setting it up to work with Postgrey http://isg.ee.ethz.ch/tools/postgrey/ [ee.ethz.ch].

    This reduced the spam at our installation by over 80% overnight, and has so far had no complaints of false positive.

    For a detailed explanation of how this works, see here..http://projects.puremagic.com/greylisting/ [puremagic.com]
    • It stopped 99% of my spam overnight when I installed it on my server. And it doesn't peg my CPU with complex content filtering rules like other things. You should keep an eye on it because some mail servers/services don't resend correctly after a 450 code, but you can whitelist those domains if you need to.

      kashani
    • Me too!!!!!!oneone

      greylisting is a beautifully simple concept that works insanely well. I only picked up on it thanks to the recent /. posting about mail filtering at acme.com. Installed postgrey, and my end users have been much happier ever since. ...j
    • Two words: A. Men.

      FWIW, in my experience a 5 minute timeout is every bit as effective as a 4 hour (?!?!?) delay, so don't assume that more is better.

      <plug>More good ideas at Free Software Magazine [freesoftwaremagazine.com].</plug>

  • ...at least its honest and to the point!
    • Come on. A book review is an advertisement? Get a fucking clue. Just because a review endorses a product does not mean that they paid for that endorsement (I realize there are exceptions *cough*Tom's Hardware*cough*) It was a detailed review to boot! In case you didn't know, reviews are there to let people know what a product is like, therefore providing a service to people that may find the information useful.

      If you are looking just to bitch about slashdot, you could easily find better things to complain
      • Perhaps you missed that the individual who submitted the article to slashdot is the author of the review, and owner of the site it is on? If your time is so valuable, why did you bother with the "I somehow believe you think all reviewers are paid endorsers, and I'll be a smart guy by correcting you" post? Grow up, and please worry about your "bandwith" elsewhere.
    • Sorry. I was cranky and quick on the trigger. I'm real sick of all the slashdot whiners and complainers. Please accept my apology. I will now bow my head in shame for a while.
  • by currivan (654314) on Wednesday June 29 2005, @03:28PM (#12944706)
    "You a mail server run Postfix using do?"
  • ..I had hoped that it would be a Hildebrant [brothershildebrandt.com] illustrated guide to Postfix.
  • I am dissapointed. I clicked on this link expecting it to be about Forth or PostScript or HP. Boy was I sadly mistaken.
  • Maybe I am just being picky, but it seems a little strange to crosslist a book on mail server/system/whatever software in the hardware section.

    Let's review:
    hardware = something you can kick when it breaks, or, kick to break it
    software = the little 0's and 1's that live in hardware.

  • by lordsilence (682367) * on Wednesday June 29 2005, @04:05PM (#12945088) Homepage
    irc.freenode.org #postfix

    Say hello to us in irc.
    We're always happy to help.
  • This post is ancillary to the discussion at hand, but I use Postfix for one reason only: to get mail from my favorite email client (mutt) to my ISP's server, which requires authentication and sometimes encryption. And for that purpose alone, it's a pain in the butt. I see how Postfix is a great program for people running servers or routing hundreds of messages of day. I only need it because Mutt's dogmatic adherence to the Unix philosophy (each tool does one trick and one trick only, but interfaces nicel
    • You might also look into apt-getting webmin and webmin-postfix accordingly. Yeah, it's a bit of a hack, but it lays things out fairly logically so you don't have to dive into the config file much.
    • You do know mutt has a mailing list [mutt.org]?

      Try ssmtp [debian.org]. I use it when running mutt on Win32 under Cygwin.

      # .muttrc
      set sendmail="/usr/sbin/ssmtp -audUserName@domain -apSecretPassword"
  • The only reason why I'm even using Postfix at the moment is because Trend Micro went and basically made their whole Interscan Messenging Security Suite co-dependant on it... and since customer wants support, we pretty much have to do what Trend wants in that regard.

    I managed to hack it to work on qmail and qmail-scanner, and it turned out to be much faster than postfix. It's just that Postfix is a safer bet than qmail I guess.

    (DJB, if you are reading this then PLEASE update qmail and try to incorporate ot

  • It is Ralf "Ficken" Hildebrandt!

    Don't mod me down, that is his official name - at least for those who know him.
    • I think by the time most people decide they want to go with Postfix, hence a purchase of this book, they're already pretty knowledgeable with the advantages and disadvantages. Most of the network admins I speak to do all their pre-selection research from more open sources, such as (who'd-a thunk it!) the Internet.

      I can't speak for anyone else, but I usually just skip right past advantages and disadvantages in these such books.

    • Let me put it this way:

      When I read the line in the submission: Do you run a mail server using Postfix? If so, then you should..., I internally finished it with "...blow your head off?".

      ~Will
    • I've been using postfix for quite a few years now, and I wouldn't think of switching to anything else. I'm sure there are published benchmark's out there that compare the system to another, but that isn't what this book is about. This book is about configuring Postfix, why should it spew worthless info about why it is better that MTA X? Essentially this book is assuming, "you bought this book? You're using Postfix".

      One thing that I think really goes unnoticed about Postfix is that it is a drop-in rep
        • Don't challenge me. I'm not the one writing books and getting paid for it. I'm also not a professional editor by any means.

          I stated that I enjoyed the book, and I would recommend it, since I have been running Postfix for quite sometime, I used the book as a backup to the older Richard Blum book. I have not yet had the opportunity to proof-read the entire book. I've only been though parts that has been revised as of the latest few releases of Postfix.

          Yes, I am glad you have posted an errata, as I said