Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Book of Postfix

Posted by timothy on 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. The Book of Postfix author Ralf Hildebrandt + Patrick Koetter pages 464 publisher No Starch Press rating 9 reviewer Danny Yee ISBN 1593270011 summary understanding and implementing Postfix mail systems

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.

103 comments

  1. Dumb Question... by __aaclcg7560 · · Score: 4, Interesting

    Why are mail servers so needlessly complicated? Seems like you have to be a PhD Rocket Scientist to change the most simplest thing.

    1. Re:Dumb Question... by bizard · · Score: 5, Insightful

      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.

    2. Re:Dumb Question... by toxic666 · · Score: 5, Informative

      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.

    3. Re:Dumb Question... by ZosX · · Score: 3, Interesting

      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.

      --
      zosxavius photography
    4. Re:Dumb Question... by Anonymous Coward · · Score: 0

      If you want to do complicated things, it gets complicated. If not, not.

    5. Re:Dumb Question... by Armadni+General · · Score: 1, Informative

      I would still never trust Sendmail with anything reaching above the level of "joke."

      It has gotten more secure, sure, but that still doesn't stop a large number of attackers from successfully compromising the system.

      And, on top of that, Sendmail is hell to configure.

      Again, much love for Postfix.

    6. Re:Dumb Question... by Anonymous Coward · · Score: 0

      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. I have a few cron jobs that run at night on my desktop. I'd like to get the output of those cron jobs as an email. Why do I have to install a full-fledged, complex mail server and go through all kinds of configurations on my desktop box just to get the output of cron jobs?

    7. Re:Dumb Question... by Anonymous Coward · · Score: 0

      I hear ya, but I don't think that it is the mail server that is needlessly complicated, but rather the documentation.

      Take a look at the Postfix or Exim documentation -- it's like a Debian manual.

    8. Re:Dumb Question... by Rasta+Prefect · · Score: 1
      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.

      --
      Why?
    9. Re:Dumb Question... by Alphabet+Pal · · Score: 1

      Fortunately, according to Charles Fitzgerald, Microsoft is about to put the rocket scientists who do AJAX programming out of work when they release their new AJAX development platform, so there will be plenty looking for Postfix admin jobs.

      --
      Because you can't spell "slaughter" without "laughter"
    10. Re:Dumb Question... by dodobh · · Score: 2, Informative

      Basics
      Standard configs

      You shouldn't need to really configure much more than that.

      --
      I can throw myself at the ground, and miss.
    11. Re:Dumb Question... by Anonymous Coward · · Score: 0

      Try qmail, it's about as simple as a mail server could get, and it's still pretty complicated.

      Postfix has a zillion bizzare options that you don't need all at once, so it seems complicated

    12. Re:Dumb Question... by Anonymous Coward · · Score: 0

      It's not a dumb question. On some level mail servers are so complex because in general the same mail system(s) are intended to be used by folks with 25 or 250k users. There are a few mail servers out there which are designed for a small number of users with a limited set of functionality. In general those systems are relatively simple and a lot of the 'needless complexity' has been filtered out of the system.

      Windows 2003 for example offers the ability to use the IIS SMTP service and a POP3 service to provide a relatively simple mailer to users. There are a number of other products built by smaller companies which fall into this category as well.

      That being said, the "Simple" portion of SMTP refers to the basic interaction of servers when communicating to send mail messages. The fundamental dependencies to allow communication that to happen in the first place are much more complex.

    13. Re:Dumb Question... by Romeozulu · · Score: 2, Interesting

      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 password to send mail though it. I don't want to set up a hole SSL TSL BFD system with certificates and crap.

      Why is the that the same program that receives mail from the outside world is the one that accepts connections from clients. This is silly and contributes to the spam problem. Much like POP3 or IMAP is a separate program, so should the one that accepts mail from a client like TB or Outlook. Then we wouldn't have this will spam problem.

      Mail servers are still stuck in the mainframe days. Time for someone to rethink this mess.

    14. Re:Dumb Question... by dodobh · · Score: 3, Informative

      SMTP AUTH

      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.

      --
      I can throw myself at the ground, and miss.
    15. Re:Dumb Question... by stilwebm · · Score: 1

      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 off the list because it has an unresolved buffer overflow vulnerability, but if that gets fixed it might be perfect for you.

    16. Re:Dumb Question... by zerocool^ · · Score: 1

      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 the internet. More shit happens to an email to get it from person A's outlook to person B's outlook than anything else I can think of. It's dependant on DNS, Firewalls, rbl's, sender white/blacklisting, spam scoring, format checking, forwarding, local user checking, virtual user table matching, queueing, delivery via web/pop3/imap, sending via web/smtp through firewalls with sender verification/temporary IP whitelisting, mailbox sorting, listservs, distribution lists, digesting, etc.

      And that's every server it passes through!

      Email was origionally very simple. telnet 25 helo foo.bar.com mail from rcpt to data . go. Since then, there have been 189218953 extentions and addons to the protocols and standards, and the same number of un-regulated features and whizbangs added, all while trying to keep the end user experience of the "send-recieve all" button the same. Add to that, the worlds most popular, and worst, mail server (sendmail) has come up with a config file and a set of rules/instructions/etc that have spawned a cottege industry of book publishers trying to explain them (I own an *800 page* book on sendmail). There is no worse sentax in the world than a sendmail.cf, perl included.

      So: to answer your question, it's complicated because it's complicated. However, once you get all your stuff installed correctly, managing through something like qmailmgr is pretty easy.

      ~Will

      --
      sig?
    17. Re:Dumb Question... by stilwebm · · Score: 0

      That should read "TwistedMail"

    18. Re:Dumb Question... by hildeb · · Score: 1

      The point is that YOU don't usually need them. But when you do: Postfix: Set them differently qmail: It's Patch time again.

    19. Re:Dumb Question... by Tassach · · Score: 2, Informative
      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
      Assuming you already have your MX record set up and port 25 open to the world, you should then only have to change 3 lines in /etc/postfix/main.cf to be able to send & recieve email from any machine on your LAN to anywhere in the world:
      myhostname = mail.mydomain.tld
      mydomain = mydomain.tld
      mynetworks = 192.168.69.0/24
      The only gotcha is that if you are on a cable modem / dsl, some ISPs (AOL) might not accept your mail based on your IP. In that case you need to make one more change to main.cf:
      relayhost = smtp.myisp.net
      This forces all outbound mail to go through your ISP's official mail server.

      Then all you have to do is (re)start postfix:

      service postfix restart
      It's that easy.

      You can do more tweaking to improve security and set up spam & virus filtering, but those are complicated topics and are therefore complicated to configure. Switching to use maildir delivery (vs the default mbox format) is trivial to do, and is left as an exersize for the reader.

      --
      Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
    20. Re:Dumb Question... by Cal+Paterson · · Score: 1

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

      Correct grammar might help.

    21. Re:Dumb Question... by Nailer · · Score: 1

      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?

    22. Re:Dumb Question... by Taladar · · Score: 1

      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".

      --
      Linux is not Windows
    23. Re:Dumb Question... by Nailer · · Score: 3, Insightful

      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?

    24. Re:Dumb Question... by merlyn · · Score: 1
      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.

      --
    25. Re:Dumb Question... by gothfox · · Score: 1

      Why is the that the same program that receives mail from the outside world is the one that accepts connections from clients. This is silly and contributes to the spam problem.

      Maybe that's because mail delivery from MUA and other MTAs are done (sometimes, not always) over one standard protocol - SMTP?

      I'm sorry, really, but with this level of understanding you have no business whatsoever in configuring mail servers. Ask your sysadmin to do it for you.

    26. Re:Dumb Question... by cloudmaster · · Score: 1

      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 *first*.

      That said, a default postfix install wil work for basic needs, and most user-oriented Linuxes (SuSE, Fedora, not Gentoo, etc) have friendly config tools to make basic changes. :)

    27. Re:Dumb Question... by hildeb · · Score: 1

      Actually, it suffices to use: myhostname = mail.mydomain.tld relayhost = [smtp.myisp.net] since mynetworks is usually correctly derived from the network config, and mydomain is being derived from myhostname.

    28. Re:Dumb Question... by Romeozulu · · Score: 1

      >>I'm sorry, really, but with this level of understanding you have no business whatsoever in configuring mail servers. Ask your sysadmin to do it for you.

      I understand it, I just don't think it needs to be as hard as it is. My server is running just fine.

      Why are IT people such jerks.

    29. Re:Dumb Question... by gothfox · · Score: 1

      I'm sorry for sounding like a jerk in a grandparent post, I've just seen too much horribly misconfigured mail systems, sending shit in HELO and all that. And their beady eyed admins asking me why the fuck is their mail being rejected. Sorry again.

      You see, mail systems require a truckload of flexibility because many mail configurations exist and many tasks must be solved. You don't really think that sendmail's flexibility was just a conspiracy of sysadmins to make their job indispensible, right?

      Mail in general is not trivial, it's a fact of life, get over it. But it's not really a problem, because any (well, maybe except that twisted thing that is qmail) MTA at this time has very sane and reasonable defaults which require just few tweaks to make it work for typical cases (like local system, network system with direct delivery or smarthost configuration).

      If you require advanced functionality - it's there, but you are not required to learn it until you need it. It's not hard. I've seen a 15 year old fucking girl answer three questions of Debian's exim configurator and had her mail working automagically after that. Where is the problem? How easier this can get?

      Now, imagine at some point in time you require additional functionality. For example, transport maps, non-trivial delivery agents, content filters to fight spam and viruses, et cetera. It will be right there in your MTA, waiting for you to read relevant page in documentation and enable it. Isn't it nice?

      If you had your simple basic non-expandable MTA what would you do? Ditch it and start from scratch with more configurable program? Repeat to fade?

      Maybe I didn't understand your original point, I'm not a native speaker, the whole thread was like a month ago, blah blah. But really, the whole thread smells like a non-issue to me.

  2. I already do a lot of that stuff... by platos_beard · · Score: 1

    The only reason I'd read the Book of Postfix is if I actually wanted to understand what the heck I was doin'

    --
    What's a sig?
    1. Re:I already do a lot of that stuff... by jacksonj04 · · Score: 1

      You're a student of the 'Prod and Pray' school then?

      --
      How many people can read hex if only you and dead people can read hex?
    2. Re:I already do a lot of that stuff... by Calyth · · Score: 1

      Wait until you get to clean out thousands (I just cleaned out 3000 and gleaned some useful emails, by hand) and you'll want to know what you are doing.

  3. Great timing by stevey · · Score: 3, Informative

    I also reviewed The Book Of Postfix this week.

    I also enjoyed it, and recommended it.

    1. Re:Great timing by drauh · · Score: 2, Funny
      I also enjoyed it...

      How to tell when it's time for you to read some alt.sysadmin.recovery.

      --
      This is a tautology.
  4. Just picked this book up a month ago by DarkFencer · · Score: 5, Informative

    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!

    1. Re:Just picked this book up a month ago by fjf33 · · Score: 2, Insightful

      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. :)

    2. Re:Just picked this book up a month ago by Pete · · Score: 1

      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 system and no, I don't want to buggerise around setting up email. Just ask one or two simple multi-choice questions (with sensible defaults), then set it up for me. Thank you."

  5. Grey listing.. by login: · · Score: 4, Informative

    For anyone using Postfix, I would highly recommend setting it up to work with Postgrey http://isg.ee.ethz.ch/tools/postgrey/.

    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/

    1. Re:Grey listing.. by Anonymous Coward · · Score: 0

      Indeed. That's why it's being mentioned in the German edition of our book. You know, so much to write, so little time.

    2. Re:Grey listing.. by Anonymous Coward · · Score: 0

      Grey listing is great but I have seen many people abuse it. Either they dont understand it or they go crazy on the time constraints. I think it was earthlink (which uses this process to eliminate spam) who has the craziest listing time at over 4 hours. Trying to keep queue times very low, we have had frequent problems with bounces from them. Its a great too, just keep it sane ;)

    3. Re:Grey listing.. by stevey · · Score: 1

      I concur.

      Greylisting has its drawbacks, and can cause problems in some cases, but it's singlehandedly reduced my incoming SPAM by at least a third.

      The attraction is that it's 100% automatic, and requires no retraining, etc.

    4. Re:Grey listing.. by kashani · · Score: 1

      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

      --
      - Why is the ninja... so deadly?
    5. Re:Grey listing.. by jbrw · · Score: 1

      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

    6. Re:Grey listing.. by Just+Some+Guy · · Score: 1
      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.</plug>

      --
      Dewey, what part of this looks like authorities should be involved?
  6. Slashvertisement, but... by inkdesign · · Score: 1, Funny

    ...at least its honest and to the point!

  7. Shouldn't that be... by currivan · · Score: 3, Funny

    "You a mail server run Postfix using do?"

    1. Re:Shouldn't that be... by dozer · · Score: 1

      Oh, Yoda speaks in postfix? Man, that little guy is elite!

  8. I would tend to disagree a little by Armadni+General · · Score: 0

    I agree that this book is a very useful tool, however, I disagree with the writer of the review. Some of the sections on SMTP protocol and behavior seem entirely superfluous, especially for anyone who even knows what Postfix is.

    However, the book is, overall, a good read, and a great tool. Definitely recommended.

    1. Re:I would tend to disagree a little by hildeb · · Score: 1

      Even Wietse complained and said the SMTP section has to be enhanced when we met him. So, don't keep your fingers crossed - it will get bigger still in the German edition.

  9. Missing: advantages of postfix by powdered+toast+dude · · Score: 1, Offtopic
    I'd consider buying a book about postfix if it clearly and objectively outlined the advantages that postfix offers over other MTAs such as exim and qmail. This book doesn't sound like it offers that kind of information for the potential postfix noob.

    I've run heavy-load MTAs under qmail for some time now, and since djb won't bring it in to the current century, integrating all of the new features necessary for today's SMTP world becomes more and more hacky and patchy. Thankfully, gentoo eases it for me by including all of the most useful patches in its qmail ebuild, but some features remain unintegrated or can't easily be done early in the SMTP conversation.

    I'd love to see a simple, objective, and comprehensive comparison made between postfix, exim, and qmail (include sendmail if you like, although I won't use sendmail for admittedly emotional and historic reasons).

    Once you've made the commitment to go postfix, though, this review makes it sounds like this book might be a good resource.

    $0.02,
    ptd

    --
    I'm an animal lover -- they're delicious!
    1. Re:Missing: advantages of postfix by Gerald · · Score: 1

      ...and since djb won't bring it in to the current century, integrating all of the new features necessary for today's SMTP world becomes more and more hacky and patchy.

      You've outlined an (important IMHO) advantage yourself.

    2. Re:Missing: advantages of postfix by Armadni+General · · Score: 2, Insightful

      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.

    3. Re:Missing: advantages of postfix by zerocool^ · · Score: 1


      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

      --
      sig?
    4. Re:Missing: advantages of postfix by MikeDawg · · Score: 1

      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 replacement for sendmail, you have to admit, that generally (ala in most cases) *nix is built around sendmail as the MTA. Postfix can drop-in and act in any part just like sendmail, keeping current sendmail commands and directories, whilst being secure like it is.

      As far as the book is concerned, my biggest disappointment with the book is the large errata that they have posted on their site. I would have waited until the 2nd publishing of this book if I had any idea that it was going to be published soon, but there are several key mistakes in the book that sort of bothers me. Don't get me wrong, I understand that nothing is perfect, and that all books and published articles have their mistakes, but some of the mistakes that were made in this book stand out. That would be my biggest disappointment with the book. I have printed off the errata and placed it in the book and noted areas that were incorrect.

      --

      YOU'RE WINNER !
      Another lame blog

    5. Re:Missing: advantages of postfix by hildeb · · Score: 1

      What for? It's "The book of Postfix" and not the "Book of I shall convert thee to Postfix". No point in converting people who like to patch their MTAs to make them usable for today's internet.

    6. Re:Missing: advantages of postfix by hildeb · · Score: 1

      So we should have kept the errors secret instead? We're at least honest and report the errors. Have you reported an error yet?

    7. Re:Missing: advantages of postfix by MikeDawg · · Score: 1

      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 in my original post, I have it printed and placed in the book, I also have astrisks noting the mistakes in case I ever use something from the book. Learn to handle some constructive criticism, and make your latter publishings better from them.

      --

      YOU'RE WINNER !
      Another lame blog

    8. Re:Missing: advantages of postfix by hildeb · · Score: 1

      I have yet to see money from the book.... The point is, no matter how careful you and the editor are, there's always errors in a book - fortunately most of them were odd typos in our case - except for the showstopper "maildrop" bug... With the Blum book it was different: I stopped after the first 80 pages, sent the sheer amount of bugs to the publisher. Never SAW errata for that book after that.

  10. From the description by scrow · · Score: 2, Funny

    ..I had hoped that it would be a Hildebrant illustrated guide to Postfix.

    --
    I just type my sig in the reply form...
  11. Dissapointed by CableModemSniper · · Score: 3, Funny

    I am dissapointed. I clicked on this link expecting it to be about Forth or PostScript or HP. Boy was I sadly mistaken.

    --
    Why not fork?
  12. MOD THIS GARBAGE DOWN! by ZosX · · Score: 1, Troll

    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 about. Next time don't waste my bandwith (and time) with your idiotic comments.

    --
    zosxavius photography
    1. Re:MOD THIS GARBAGE DOWN! by inkdesign · · Score: 1

      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.

    2. Re:MOD THIS GARBAGE DOWN! by mabinogi · · Score: 1

      > 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?

      That's how book reviews on Slashdot _always_ work.

      Someone writes a review and submits it to slashdot. They don't submit someone else's review - that would be a copyright issue at best, and plagiarism at worst.
      It just happens that in this case the person who submitted the review also has it on his web site, so he linked to it. That's fair enough if you ask me, and a few reviewers have done that in the past.

      If the concept bugs you, then turn off the review section in your preferences, because pretty much every review will be like that.

      --
      Advanced users are users too!
    3. Re:MOD THIS GARBAGE DOWN! by inkdesign · · Score: 1

      I know man.. Thus the humor in the original comment. The gentleman who replied really didn't seem to get the joke, thus the redundant explanation.

  13. All this for a moribund standard by Urusai · · Score: 0, Troll

    In Korea, only old people use email.

  14. PostFix crosslisted in hardware? by Viltvodlian+Deoderan · · Score: 2, Insightful
    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.

  15. Hmm by pete-classic · · Score: 0, Troll

    Shouldn't it be "The Book Postfix of"?

    -Peter

    1. Re:Hmm by pete-classic · · Score: 1

      Dear Moderator,

      If you don't understand a post, don't moderate it.

      Postfix is an alternative notation to infix. For example 2 + 5 becomes 2 5 +. So "The Book of Postfix" becomes "The Book Postfix of". Maybe it isn't funny after all, but it isn't a troll by any reasonable definition.

      -Peter

  16. over 800 book reviews? by jspectre · · Score: 0, Offtopic

    ok. but can someone please explain to me how someone has all the time to read over 800 books, in-depth, and write a decent review on them all? even at it for a full-time job. hmm...

    --

    abcdefghijklmnopqrstuvwxyz

  17. Fewer Open Relays by shiller · · Score: 1

    It should be obligatory to read such a book for everyone who administrates a mail server, because hopefully it helps to decrease the number of open relays out where.

    1. Re:Fewer Open Relays by jcuervo · · Score: 1

      Postfix is not an open relay out of the box.

      --
      Assume I was drunk when I posted this.
    2. Re:Fewer Open Relays by Kevin+DeGraaf · · Score: 1

      1. Running a mail server without turning it into an open relay doesn't require that one read some silly book. It simply requires that one not be an idiot. For example, in qmail, all that's needed is to ensure that the rcpthosts file exists (and is populated with your domains).

      2. How do you plan to enforce this? Mandatory licensing for sysadmins? No thanks.

      3. "Administrates"? "out where"? "hopefully it helps"?

      --
      We have more to fear from the bungling of the incompetent than from the machinations of the wicked.
  18. Comparisons with Blum? by Anonymous Coward · · Score: 0

    Postfix by Richard Blum was the quintessential guide to Postfix. But, do to newer releases of Postfix, it is now somewhat out of date. I had very much hoped that Richard Blum would revise it but, that does not seem to be in the cards, yet.

    Can anyone who has read both Blum's and this new Postfix book offer any comparisons between the two.

    1. Re:Comparisons with Blum? by hildeb · · Score: 1

      The Blum book was outdated when it came out. I personally found it extremely superficial and also imprecise.

  19. Another source of postfix information :) by lordsilence · · Score: 3, Informative

    irc.freenode.org #postfix

    Say hello to us in irc.
    We're always happy to help.

    1. Re:Another source of postfix information :) by dodobh · · Score: 1

      And your handle is?

      Just call me f3ew

      --
      I can throw myself at the ground, and miss.
    2. Re:Another source of postfix information :) by Anonymous Coward · · Score: 0

      Posting AC (lordsilence here btw) w|edge here at your service. :>

  20. 3000? by Anonymous Coward · · Score: 0

    Thanks to a vacation autoresponder loop this past weekend, I had the pleasure of cleaning up ~1.5 million messages. Took me 10 minutes to write the script and I was out smoking a fag.

  21. qMail by Anonymous Coward · · Score: 0

    Are there any comprehensive documents on getting qMail up and running on a simple network? a starting place for us newbies?

    1. Re:qMail by Anonymous Coward · · Score: 0

      A good place to start is exim.org if you

      1. do not want to use Postfix which runs almost perfectly for small networks in its default installation on many distributions.
      2. want to run a powerfull, MANAGEABLE open-source mailserver

      I strongly advise against using qmail. It is not open-source and may not be redistributed in a changed form. So you have to patch it up yourself if you want to add some features it didn't have at its latest release 1998(!). Furthermore it uses DJBs obscure daemontools which are so unlike init it hurts. It is a nightmare alone to get rid of them.

      Hope this helps.

      ps. Flame me, I know you will. You know who you are.

    2. Re:qMail by DA-MAN · · Score: 1

      http://www.qmailtoaster.com/

      This is an easy and simple way to get Qmail going.

      --
      Can I get an eye poke?
      Dog House Forum
  22. Reliability, Security, Spamblocking are hard by billstewart · · Score: 1
    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 new trick you deployed last week, and fixing the reliability problems that happened because somebody else's mailer didn't get along with the anti-spammer trick you installed the week before.
    • Some complexity is because mail systems used to solve much harder problems (delivery across half a dozen network architectures, such as UUCP, that are mostly less reliable than SMTP over dedicated Internet connections), and they implemented it in highly extensible generalizable ways, like Sendmail config files, which can probably still be used to implement Turing Machines.
    • Some complexity is because of ugly Baroque programming styles - there's no particular need for a mailer config file to implement Turing Machines, when simple pattern-matching table-driven mailers like UPAS did the work without all that ugliness, and there's no need for file formats that not only steal bytes but even bits because the output might occasionally be a bit shorter, like the ASN.1 used in X.509 security certs.
    • Some complexity is because of historical leftovers - splitting MTAs and MUAs really does simplify the MTA, especially when the destination address can follow a single DNS-based addressing standard, instead of arbitrary complexities like mixtures of UUCP, Bitnet, and ARPAnet names. And the early BSD operating system insistence that Port 25 only be listenable by root meant that any mailer running SMTP in that environment needed to run at least with setUID-root privileges, exposing the mail server to lots of security risks, so the mail system had to be much more complex to defend itself against lots of little security hacks that would be much less serious if the mailer ran as a non-root user like uucp and used setgid-mail to deliver mail into mailboxes.
    • Some complexity is because splitting up the MUA and MTA functions means that sometimes the MTA doesn't know as much as it needs, e.g. a firewall email-relay proxy might not have access to the database of valid user names, which makes it harder to do good bouncegrams and good spammer rejection. Furthermore, it frees the MUA and MTA to be produced by different people, which means there's a need for standardization so all of the subtle features work (like user directories and security.) (Just because I said in the previous paragraph that splitting up the MTA and MUA simplified things, that doesn't mean that simplifying things always makes your life simpler....)
    • Some complexity is because Microsoft-adopted file sharing protocols were the closest available standard-like-thing that some little development shop had around, so they built a mail system that used file sharing instead of sockets, without learning from the experience of the UUCP-based mail systems, and they were building it entirely as a LAN-based system without thinking of how it would scale outside a closed environment, and they built mailboxes in a fragile and unmaintainable format, and when the thing suddenly got itself named "Microsoft Mail", it spent a decade growing into a much larger thing that was a cornerstone of an Evil Plan to lock users into Microsoft Office by aggressive use of feature creep and anti-standardization, and while it's really much much more reliable than it used to be, it's still the Mos Eisely of mail systems.
    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  23. Mutt by water-and-sewer · · Score: 1

    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 nicely with other tools) means I need to go through a lot of work to get my mail to the ISP. SUSE made this easy for me, through YAST2, which dealt with all the tricky configuration necessary to get Postfix talking to my server, but I never understood how it worked. When I moved to Kubuntu I was forced to dive into the Postfix config files more deeply than I felt confident doing. I'd love either a mutt patch that provides SMTP-auth capability (whoops, google is my friend: http://www.geocities.com/win32mutt/patches.html - why isn't it used by default?) or a simple DEB package that provides mini-SMTP-auth capability for people like me that only send out 10-20 emails per day, and always to our smarthost.

    --
    If this were Usenet, I'd killfile the lot of you.
    1. Re:Mutt by dacarr · · Score: 1

      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.

      --
      This sig no verb.
    2. Re:Mutt by value_added · · Score: 2, Informative
      You do know mutt has a mailing list?

      Try ssmtp. I use it when running mutt on Win32 under Cygwin.

      # .muttrc
      set sendmail="/usr/sbin/ssmtp -audUserName@domain -apSecretPassword"
    3. Re:Mutt by Anonymous Coward · · Score: 0

      See the "Tiny mail sending agents" section at
      http://www.mutt.blackfish.org.uk/sending/

  24. Because users need needless complexity too by wsanders · · Score: 1

    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 headers are rewritten to obfuscate the originating subdomain based on what floor the email is sent from.

    Postfix is perfect for that kind of stuff.

    --
    Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
  25. yep by jefe7777 · · Score: 1

    "It's a little known fact, but mail servers were the 10th plague that God visited upon the egyptians." -j.d. illiad frazer btw koetter has been a huge help for years with his postfix/cyrus/tls howto on the web.

  26. Rather use qmail, but.... by Neo-Rio-101 · · Score: 1

    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 other people's patches. Your codebase is slowly being patched to hell and is slowly becoming a PITA to administer. Thanks.)

    --
    READY.
    PRINT ""+-0
  27. It's not Ralf Hildebrandt by slashflood · · Score: 1


    It is Ralf "Ficken" Hildebrandt!

    Don't mod me down, that is his official name - at least for those who know him.

  28. An apology by ZosX · · Score: 1

    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.

    --
    zosxavius photography
    1. Re:An apology by inkdesign · · Score: 1

      Wow.. Thanks! :0]

  29. Re:Maybe the problem is that you're fucking braind by Nailer · · Score: 1
    Dear not-particularly-good troll:

    I'm actually quite competant at both Sendmail and Postfix. I wasn't actually talking about myself. You just assumed I was, and made yourself look like a dick as a result.

    Qmail isn't Open Source you fucking idiot.