Postfix

Andy Murren contributed this review of Richard Blum's Postfix. Powering mail delivery may not be as sexy as programming in exotic new languages, but it sure is important -- Andy gives you the scoop here on how well Postfix (and Postfix) do at the task.

Postfix
author	Richard Blun
pages	542
publisher	Sams
rating	8
reviewer	Andy Murren
ISBN	0-672-32114-9
summary	Guide to setting up and running Postfix as your MTA.

Postfix is a complete Mail Transfer Agent (MTA) that is meant to be a replacement for Sendmail. Wietse Venema, who works at the IBM Watson Research Center, wrote the program and released it under the IBM Public License. Richard Blum has targeted this book at Intermediate to Advanced users, but he has enough basic information so that even an MS Exchange administrator with no Unix background can get Postfix running quickly.

The book is broken into three sections:

1. Introduction to E-Mail Services and Postfix
2. Installing and Configuring Postfix
3. Advanced Postfix Server Topics

Part I is a nice overview of email, how to use Postfix, how Postfix works and a comparison of Postfix and Sendmail. In chapter 3 'Server Requirements for Postfix' an overview of Unix and Unix commands are covered along with an introduction to bash, gcc and make to bring the non-Unix user up to speed with the tools that they will need.

The chapter on DNS starts by covering the origins of DNS and the basics of how it works. Blum then gives us an explanation of DNS records and how to set them up, including the all-important MX (Mail Exchanger) record. He then gives a brief discussion on how to set up the resolv.conf, hosts and hosts.conf files. The chapter concludes with a quick look at the host, nslookup and dig programs. This chapter serves as a quick reference on getting DNS up and running on a Unix box.

Part II is a detailed section that is the heart of the book. How to set up Postfix is laid out in detail from how to install (both from an RPM file and from source), to configuring it, to logging and blocking UCE/UBE.

One of the sections of the book I was drawn to was on how to set up Postfix as an internal and external mail server for the Small Office environment. This could be for branch offices of a large company (such as insurance offices) or for a Small Office / Home Office (SOHO) that does not have a full time Internet connection. Blum explains how to set up the server for dial-up to send and retrieve mail, and how to run the mail server on the same box as your firewall.

The chapter 'Migrating from Sendmail to Postfix' is a short step-by-step on how and what to convert from Sendmail to Postfix. Since Postfix was designed to do this easily the chapter is shorter than might be expected (only 20 pages).

Rounding out Part II is a chapter on the Maildir mailbox format and a chapter on using an external MDA. The chapter on using an external MDA is a good example of why I like this book. Here is the full Table of Contents for the chapter:

1. Using MDA Programs with Postfix

1. What is a Mail Delivery Agent

1. Automatic Mail Filtering

1. Automatic Mail Replying

1. Automatic Program Initialization by Mail

1. Using an External MDA Program with Postfix

1. Configuring the main.cf file

1. Watching MDA Programs in the Postfix Log

1. The procmail MDA Program

1. Installing procmail

1. The procmail Command Line

1. User-Defined procmail Actions

1. Summary

In this chapter Blum gives a nice quick How-To on procmail. While it is not a full treatment of procmail it has enough information to download, compile, install, configure and run procmail. Coupled with the brief lessons on Unix, gcc, make and bash in the first section, an MS Exchange administrator on their first attempt in the Unix world is provided enough information to get procmail working as the MDA for their new Postfix MTA.

Section III covers advanced server topics including using MySQL, OpenLDAP and Majordomo with Postfix. Like the section on procmail, Blum covers installing and configuring each of these applications and how to make Postfix work with them. Chapter 20 covers POP3 and IMAP, which then leads nicely into the next chapter on SqWebMail. The final chapters are on performance tuning and troubleshooting.

Overall I have found this to be a well-written book that addressed several questions that I had about configuring and using Postfix (such as the SOHO section). It is clear, direct and covers each topic to a level that I found comfortable. For some people this book will be too advanced but that should not be anyone who has a working knowledge of mail servers or of Unix. I would recommend this book for someone who has started to use or wants to migrate to using Postfix.

My major complaint about this book is the price, $49.99. As much as I liked this book, 'Practical UNIX and Internet Security' was more densely packed with information and only cost $39.95.

Table of Contents

1. Introduction

Introduction to E-Mail Services and Postfix

1. E-Mail Services
2. Postfix Services
3. Server Requirements for Postfix
4. DNS and Postfix
5. SMTP and Postfix

Installing and Configuring Postfix

1. Installing Postfix
2. The master.cf Configuration File
3. The main.cf Configuration File
4. Postfix Lookup Tables
5. Using Postfix
6. Using Postfix as an ISP Mail Server
7. Using Postfix as an Office Mail Server
8. Postfix Server Administration
9. Migrating from Sendmail to Postfix
10. Using the Maildir Mailbox Format
11. Using MDA Programs with Postfix

Advanced Postfix Server Topics

1. Using MySQL with Postfix
2. Using OpenLDAP with Postfix
3. Using Majordomo with Postfix
4. Using POP3 and IMAP with Postfix
5. Using SqWebMail with Postfix
6. Performance Tuning Postfix
7. Common Postfix Problems

---

You can purchase this book at Fatbrain.

Re:Does Postfix support Maildir like Exim or Qmail

[Dom2]

Actually, postfix only really supports Maildirs in your home directory (unless you use a .forward file). However, I have a patch to postfix which will allow you to send to Maildir's in the spool much more easily.

Mail me if you want it.

-Dom

Where's the SPAM?

[Sturm]

You know? None of these books ever seem to include sections devoted to blocking SPAM. As a sysadmin, this is one of the most important topics I think could be covered. Maybe they leave it out intentionally so they can send you spam and try to get you to buy their book :)

Speed, Maybehaps?

[Christopher B. Brown]

If you're running a personal server, it's not vitally important, but if the mail server is processing thousands of messages a day, it can be significant.

I personally like Postfix because:

• It's pretty easy to configure.

  If your needs are simple, and you need only set up a DMsomehost.to.forward.to entry for Sendmail, Sendmail's easy to configure, but things instantly get a whole lot hairier.

  And I've never had good success with EXIM, and every time I've configured qmail it has been a hassle.

• Like qmail, it supports Maildir, which is presently handy since mail is, at the moment, being delivered to an NFS-mounted directory. Sendmail wouldn't be happy, but Postfix is.
• Postfix should be more resistant to hackers than Sendmail or Exim.

  It seems dangerous to compare Postfix to qmail; spectacular flame wars have broken out between the respective authors...

Re:Speed, Maybehaps?

[WWWWolf]

Postfix should be more resistant to hackers than Sendmail or Exim.

Yeah, you know, Sendmail's configuration format is very, very, hairy and the "hackers" will find that a worthy challenge. You Know You Are A True Guru If You Can Make Sense Of Sendmail.cf! And the design is ancient, ancient, ancient and probably fitted to run on more and more systems. A true example of cross-UNIX development. (I'm guessing here, but since I haven't heard of UNIX system that wouldn't be able to run Sendmail, I guess this is true.)

Postfix, then on the other hand, is much more boring. Configure, make it run, it runs. Bleah. Boooooriiiing!

(yeah, I know you meant "crackers" =)

Exim?

[Ed Avis]

Why Postfix rather than Exim? (Assuming sendmail (security holes, cruft) and qmail (non-free) are ruled out.)

Re:Where's the SPAM?

[willfe]

True. Many of the features are overkill. However, that postfix makes those features available (many not enabled by default; only the no-relaying feature is enabled out-of-the-box) and very easy to configure was the point of my post.

If you turn on absolutely every feature on the list, you're going to have a very unfriendly mail server. Some admins think that's a good thing (I'm one of them, although I tend not to implement the more draconian features :), since a misconfigured mail server has no business being on the internet, and calling attention to that misconfiguration by refusing to service it until it's fixed is a great way to get things fixed eventually.

The surest way to properly nuke spam is to set up aggressive procmail filters *and* use a mail server that's unfriendly. Certainly, refusing mail from known spamming domains and relays is acceptable, and quite effective. You let the mail server deal with known spammers, and your procmail deal with whatever slips through the cracks.

It can't be fully automated. It's just impossible. However, by letting the mail server deal with the grunt work (you don't really want to try to make procmail handle the RBL stuff, do you? Okay, fine, many of us more geeky types are quite willing to do that, but still, the argument is reasonably valid :), you can focus on the more incidious spammers and work aggressively to shut them down. You can better spend your time if your mail server is helping, even a little, in keeping spam out of your inbox.

Re:Best MTA -- QMAIL

[willfe]

[chomp] Mmmm... flamebait.

Most of these links seem to rather argue with your assertion that the best is qmail. First we've got a somewhat biased comparison (the "Life with qmail" document is probably not the best source for honest comparison) that still doesn't really claim one being better than the others.

Next up we've got another MTA comparison that claims postfix is nearly three times faster than qmail. Heh. Whoops.

Then we've a comparison between mbox (standard Unix mailbox format) and mailbox, qmail's format. This is a nice comparison, but doesn't help the argument much since postfix groks the mailbox format as well.

Finally we've a complaint from the author of qmail about how postfix handles the mail spool. Of course qmail's author's behavior is, unfortunately, a factor you must consider when choosing which MTA you want to use. There's a bit too much attitude there for my taste. I've never liked dealing with authors (or products) who have to prop up their work by tearing down others. It's one thing to say "I think my tool is the best" and quite another to say "My tool is the best because the others suck."

Additionally, the gaping hole described can be closed by runtime configuration. You don't have to run with world-writable mailboxes. It's also worth noting that if you're running a "closed" mail system (where users never log in directly to check their mail, but instead use IMAP or POP3), it's not a security risk at all (since only root or other privileged (and hopefully trusted) users would be granted access in the first place).

Re:Best MTA -- QMAIL

[willfe]

Obviously the most subjective part of this whole discussion is the behavior of the author(s) involved. That's something each individual administrator has to decide on. I don't quite feel comfortable putting my mail system in the hands of someone who gets so riled up about his product. I get the impression he's perfectly willing to put his users unwittingly in the line of fire to prove his point. It's just my opinion; you'll undoubtedly feel the need to offer corrections to it, but my perception of qmail's author just brings to mind one of the Things I Will (not) Do when I am an Evil Overlord ("I will never utter the phrase 'what? How can this be? I'm invincible!!!' as it will almost certainly be immediately followed by my horrific destruction").

Yes, I've heard of this "root hole in POP3 or IMAP" concept before. Funny thing is I don't recall any particular MTA being the cause. A qmail system is just as vulnerable to such exploits as a postfix system is when the actual exploit involves Cyrus IMAP, for example. Both MTAs will happily sit there and do absolutely nothing, since accessing one's mail once it's been delivered is a task neither MTA cares about.

Let's go over your other points.

I counter that postfix is also quite good:

1. Easy configuration - read README (ships with postfix)
2. Easy administration - read README (ships with postfix)
3. Security - it's odd, but I don't see any entries in the vulnerability database at Security Focus (bugtraq) [securityfocus.com] for postfix either. I never suggested postfix was inpenetrable or flawless; my counterpoint here is that just because nobody's found and publicly complained about an exploit in qmail doesn't mean one doesn't exist. Organizations and authors, big and small, have walked away red-faced from such assumptions many times. I find it a bit worrying that qmail's author is so cocky about his product. Whether that concern is unfounded or valid isn't your place to decide. It's every single person's choice when they're deciding whether to install a particular system or not. It seems both postfix and qmail have had their share of problems, and those get fixed and updates are released to give those fixes to the world. Where's the problem with either system on this count?
4. Fast - Yup, I've heard about qmail running on Hotmail and/or the other big free web sites. I also can't shake my read of the comparison you referenced that throws that "three times faster than qmail" figure around. Yes, they discuss that they can't duplicate the performance, but that it's still faster than qmail. This comparison doesn't matter too much anyway; qmail and postfix both scream, and they've both met the goals they set out to achieve -- they're faster than sendmail. That's been widely acknowledged by everyone involved.
5. Great support - postfix is remarkably well documented and has plenty of FAQs and examples around. Your qualifier for qmail's support implies that if you dare ask a newbie question, you're going to be given yet another reason why you shouldn't have chosen qmail in the first place. I can't stand elitism; it especially has no place with a product such as an MTA. As the author of an MTA, it's in your best interest to tolerate newbies, and guide them to configuring your MTA properly so your product isn't helping to putting yet another badly behaved, misconfigured server on the internet.
6. Maildir - drat, typos in the wrong place. I did mean "maildir" instead of "mailbox". Postfix supports maildir as well. I am well aware of its NFS-friendly design, and it is quite a good one.

I am afforded an equal amount of good sleep by postfix; hasn't flaked on me yet, and I don't expect it to.

We're comparing very similar systems here. They're both setting out to do the same things, and it looks to me like they're both accomplishing what they've set out to accomplish. Bickering over each system's choice of implementation is a waste of time. If an implementation proves inappropriate, it will over time be fixed or abandoned.

Holy wars suck anyway; perhaps your time would be better spent away from embarking on one here. If you're game for an attempt at an objective discussion of the merits of the individual systems, then great, I'll carry one on as well. But if we're going to jump into a nasty flamewar (that the qmail & postfix communities have seen far too many of anyway), I'll respectully bow out here.

Re:Best MTA -- QMAIL

[willfe]

No, I'm not making him out to be a monster. I'm pointing out that his behavior towards the uninitiated is an important factor in deciding whether to try qmail or not.

I agree that mailing lists aren't the best place for newbie questions, but I detest those who are completely intolerant of idiotic questions. I'm the senior system administrator at my office, and I get my share of stupid questions from people. My first response isn't to just blast the questioner for daring not to know some little detail, or even overlooking instructions clearly given about how to accomplish what they're trying to do (it's my second response ;).

A mailing list is no different. If you get the same question asked over and over, stick it in a FAQ. Then when it's asked again, politely refer the questioner to the FAQ. You don't abuse somebody just because they don't know the answers you have. You lose users that way, and foster plenty of negativity towards the product.

I've had my share of frustration with users. I've been sorely tempted to blast the morons out of my lowly cubicle with a scalding assault on their brainpower and family heritage. Guess what? I hold back. In the case of work, I know better than to blow up at somebody; it's an excuse for them to complain, an excuse for my boss to write me up, and a reason for the office culture to shift enough that my skills & experience aren't sought anymore. In the free software world, all you've got is the support of your users. Alienate them, and you're toast.

By the way, cool lcd project...worthless but cool.

Thanks! :)

Re:Where's the SPAM?

[willfe]

Um:

Part II is a detailed section that is the heart of the book. How to set up Postfix is laid out in detail from how to install (both from an RPM file and from source), to configuring it, to logging and blocking UCE/UBE.

Devoting an entire chapter of a book to blocking spam sounds like a nice idea, but one of the many things postfix gets right is its ability to effectively and easily block spam for you. With only a few configuration directives in /etc/postfix/main.cf, you can make postfix:

• Reject inbound mail if it's coming from a known spammer, known relay, or known dialup IP addy (the blackhole, relays, and dialups lists at the RBL)
• Reject inbound mail from any system that presents an invalid (i.e. not strictly DNS-compliant) hostname
• Reject inbound mail from any system whose IP address cannot be resolved to a name
• Reject "inbound" mail whose real destination is any domain that the postfix installation doesn't directly service (by delivering the mail itself or by relaying to a defined external system); this is a default feature, incidentally
• Limit the number of recipients a single message can have
• Limit the number of messages a single system can send to the server over a specific duration
• Limit (or completely inhibit) clients' ability to use the VRFY command to harvest addresses

I bet there's more that I've forgotten about (or not discovered yet). Every single item in this list can be implemented with one directive in /etc/postfix/main.cf; postfix is very easy in this regard.

I would think, given postfix's very easy means of setting all this stuff up (and the in-depth documentation that it ships with), that it would be a waste to devote more than a few pages to spam blocking when discussing this mail system. It won't relay by default (so there goes the most commonly used gaping hole for spammers right there), and by turning on features that limit DoS-type attacks and spamming runs, you catch all the clueless spammers. By including the RBL, you catch the more sophisticated ones. Sure, spam's gonna get through no matter what you do, but it won't be postfix's fault.

This book looks to be a clear, concise discussion of postfix's other, more interesting features. I'm glad to see a whole section devoted to getting postfix working with OpenLDAP, for example. Honestly, I think that sort of thing is more important than spam catching in the first place; sure, a user might have to delete a few spams if you haven't spent all the time you should on spam catching, but you might well have more free time if you manage to integrate all your authentication and account management into an LDAP directory that postfix can directly use for its users and configuration.

Just some random thoughts from a humble system administrator :)

Re:Postfix vs Postfix

[SpaFF]

Well if you'll notice, not only is the software package named Postfix, but so the title of the book is Postfix as well.

Re:qmail vs postfix vs sendmail vs ms

[thogard]

If you look at the sendmail exploits they almost all involve handing mail off to external programs and mailers. Postfix, Qmail,etc do not do anything that prevents the same sort of configuraion problem.

Also any program the delivers mail will be running with high privliages. You must be root to bind to port 25 therefor you must run as root to bind to port 25. To drop mail into the system mailboxes you must have privliges that allow you to do that too. Some systems you can simply be the member of the mail group and on others you must be root.

Re:Some errors in the book

[dodobh]

It wasn't the entirety, just the relevant portion. /. removed about half that post also.

[OT]Re:Some errors in the book

[dodobh]

I don't know about you, but I have been doing this for the past three years, and the people just need to learn to RTFM. I'm close to burnout, I need a vacation, and I have two NT machines to secure properly, where smb *must* be available. I have been trying to get the local MCSE to learn to use Linux, and they will not learn unless I read out each line of the manual, grep through the two relevant man pages for what they need, and then have them abuse me for taking so long to show them exactly what to do.
They want to install X and VNC to admin a Linux machine, want telnet and will not use ssh. I have tried not to be a BOFH, but now I am going to be one.
Yes, I need a life, and I am going to get it.
Your sarcasm is deserved in the comment, and I am sorry for the whining, but I really can't help it right now.
I have had a bad week, fixing those NT boxen, and I really mind the customer support division tossing customers to me when I am trying to fix problems.

and to the AC who flamed me for not posting a link, I copied from my mailbox, something whichI will not provide a link to.

Re:qmail vs postfix vs sendmail vs ms

[dodobh]

For sendmail, the program that deals with the user is the same as that hands off to the any other external program and the same that delivers to user mailboxes.
For postfix and qmail, these are separate programs which don't trust their input.
The Postfix delivery agent does not deal with the external world except through the smtpd process.
This modularization makes for a greater extent of security than for sendmail, where the interactions are possibly more complex.

Re:qmail vs postfix vs sendmail vs ms

[dodobh]

It depends on what you need.
Essentially:
Sendmail: A single bulk monolithic program that runs as root, has a history of cruft and security holes. Has a very complex config file, which you can easily mess up and turn to an open relay.
Earlier versions used to have relaying turned on, the newer versions are far more secure.

Qmail: A very paranoid MTA. Designed to be secure.
Very much in line with the authors preferences. Mainly delivers to maildir formats, will send single recipient mails. Wastes bandwidth, and since that is expensive, I don't use it.

Postfix: As paranoid as Qmail, unde active development, and doesn't waste all that bandwidth.

MS: I have no idea.

Re:Does Postfix support Maildir like Exim or Qmail

[dodobh]

They aren't the default, but all you have to do to enable them is to add a / at the end of your spool directory.

/var/mail -- mbox format.
/var/mail/ -- Maildir

Some errors in the book

[dodobh]

There have been a few reviews on the Postfix mailing list of the book. The overall recommendation is: The book is not as good as the mailing list, but better than the docs. It doesn't maintain consistency throughout, and has a few typos.
Search the mailing list archives for details.
(Yes, I know I should be posting links, but I have now decided to get people to RTFM and learn to search. I am tired of spoon feeding lusers, and need a break).

Quoting Ralf Hildebrandt:
Today "The" book arrived. I flew over the first 11 chapters and found
the following errors/omissions:

b) p 48: What is the "spawn" program?

c) p 32, table 2.2: mail is NOT a queue. It's the mailspool, or a mbox
file, but not a queue.

d) p 31, listing 2.3: column chroot() shows "never" instead of the
default "yes" that I know.

Quoting Jeffrey Taylor:
It is more tutorial than reference. However, it repeats running
postmap everytime a new map is introduced and telnet sessions for most
forms of sender/relay/spam restrictions. THis makes in a reference
where you may not have read the previous examples. It gets tedious in
a tutorial that is read cover to cover.

IMHO: It is worthwhile, I'm not unhappy I bought the book. It feels
padded (see above). It is beginner thru intermediate, not much
advanced or tricky. I found it more useful than the docs and less
useful (and less over my head) than this e-mail list. I have a small
system, 200-300 messages per day and the chapters on MySQL and LDAP
only served to convince me I don't need them.

e) p 29, figure 2.2 is wrong: Lookup tables interact with the "utility
programs" (e.g. postmap, postalias!)

f) p 97 lists non-RFC conformal command syntax ("RCPT TO:haley"
instead of the correct "RCPT TO: ")

g) p 97ff list lots of bizarre SMTP commands, but the text never
actually tells the read if Postfix implements those. Lots of
bla-bla.

h) p 108 says for "The AUTH command": "The administrator must maintain a
separate username and password database that allows authentication of
remote SMTP clients."
This is not true, it can use any PAM authentication method!

i) p 171 The text for relay_host fails to mention that [] prevents a
MX Lookup of the address/hostname in the brackets!

j) p 174, table 8.1: append_at_myorigin appends (obviously) $myorigin,
not $mydomain

k) p 204, table 9.6 fails to list an all numeric LHS being equivalent
to "OK"

l) p 214 table 9.8 "virtual domain record types" fails to list the
form "@domain @otherdomain"

Re:Exim?

[Nailer]

because Postfix is more secure, with a `master' application running a series of `bitches' (erm, `slave applications) that don't trust each other. The only one of these programs that run as root is the one that binds to a low port, IIRC. Postfix is also easy to configure and scales well, supports maildir, and has good Sendmail compatibility.

Re:Security, Outlook Transmitted Diseases's, etc..

[Nailer]

The book covers lookup tables which can be used to reject messages based on their content, which handles much of what Procmail would do, with the advanatage of not actually accepting the message.

Re:Some errors in the book

[CodeMunch]

The book is not as good as the mailing list, but better than the docs. It doesn't maintain consistency throughout, and has a few typos.

Please point me to your mailing list with consistently correct responses and perfect spelling.

Thank you

;)

--Clay

Does Postfix support Maildir like Exim or Qmail??

[Raptor-X]

Does Postfix support the Maildir delivery format similar to Exim or Qmail? If so are there sections in this book which outine the configuration etc?

It would be interesting to see some benchmarks between the different opensource MTAs w/ comparison of the available features for each major MTA (ie. Sendmail, Postfix, Exim, Qmail etc).

There's a lot in there besides Postfix

[brassman]

At $50, I really hesitated to buy this puppy, but it has a heck of a lot of content on issues surrounding mail delivery, plus information that I just couldn't tease out of the Postfix docs. (Yeah, yeah, I know: Use the Source. I'll do that in my copious free time, which will be life after next at this rate.)

Sorry to hear it didn't have Venema's blessing, and it could do without the holy-roller dedication page, but bottom line I don't regret the "buy" decision.

--

Postfix's own documentation is fine

[null-und-eins]

I am running Postfix [www.postfix] on my machines for two years now and never wanted to use any other MTA. Its documentation is very complete so chances are good that you don't need this book. The FAQ covers most aspects and the rest can be deduced from the manual pages. If you are running sendmail do yourself a favour and take a look at Postfix.

Re:Exim?

[SquadBoy]

I have found that Postfix is easier to configure and at least on the machines I run *much* faster then Exim. YMMV but on Debian it is several times faster than Exim. This is why I use it.

Re:Exim?

[SquadBoy]

You might also find this interesting. http://www.debianplanet.org/debianplanet/article.p hp?thold=0&mode=nested&order=0&sid=249

Re:Where's the SPAM?

[SquadBoy]

Your later point get close. The simple fact is that spam is a social and economic problem not a technical one. Now of course all mail servers out there should be secured well but that is not about spam but rather just about good general security procedures. The reason blocking it at the server is not the best idea is because at that point it has already done it's worst damage it has already used up bandwidth storage space cycles etc. Blocking it at the server just reduces the irriation factor. Granted that is why I use procmail but what it comes down to is that blocking on the server is an ugly and bad solution to the problem. It can help but it is *not* the solution. The solution is legal, social, and economic. And of course the MTA is *not* the tool to block spam with in any case.

Re:Where's the SPAM?

[SquadBoy]

Because the mail server is a bad place to block spam. It has to be done before that. And because an MTA is a bad tool for blocking spam. Now assuming that we are going to block spam on the server (gawd knows I and everybody I know does even though it is *not* the best solution it is at least part of an ok solution) the tool that you should be using is procmail. Now comes the plug. The Debian packages of postfix uses procmail by default and a *good* spamfilter that works with procmail is only a apt-get install away. So a book on an MTA would not be the right place to talk about it. Go forth and search on procmail.

Using it!!!!

[Vantage]

We are currently using Postfix. It was pretty easy to set up and once we got over a small DNS issue it work smooth and fast. Looking forward to getting my hands on a book though. The literature available for it on the web is limited to rehashes of the .conf file. A real hardcopy text will be nice to have.

Re:Where's the SPAM?

[Coz]

*sigh*

When will I learn to put in smileys?

Spam will happen until it's unprofitable. While your response is the "right thing" there are too many people out there who only care about what's right for them, and don't care what they're subjecting the rest of us to.

Yeah, a lot of the cost has happened already - but the only way spam won't get sent is if it doesn't get seen. Granted, the economics are still heavily in "their" favor - sending 1000 scattershot emails over a "free trial" Juno account for a .1% reply rate still makes profit.

It's not just that it reduces the irritation factor - the only way people will ever stop sending UCE is if it doesn't make it through to end-users. Period. Yes, the farther upstream it can be blocked, the better for all downstream... but unless and until there's a way to drive these idiots off the net entirely, it's going to happen.

*sigh* I got serious again - Obviously, I'm not filtering my mail correctly :-)

Re:Where's the SPAM?

[Coz]

Spam must be blocked BEFORE the mail server?

So I need to be blocking it further up the line... procmail's obviously not a sufficient solution either....

Maybe what's needed is a way to have spam rejected before it gets sent... have the originating mail server bounce it... no, not strong enough... have the originating mail client bounce it... no, not strong enough either...

How's about this: when a spammer hits "SEND", a pair of robotic arms reaches out of the keyboard and chops off their hands at the wrists! That'll stop Spam, won't it?

Maybe that's not far enough upstream, either. Maybe hands are too low... aim higher maybe? Decapitation, anyone?

Re:Where's the SPAM?

[codeguy007]

Some of those features are overkill. Sure they stop spam but they will also stop legitimate email from being received if the dns setup is wrong or somebody is sending mail from there linux box without a DNS address.

Also limiting the amount of email any one machine can send you over a period of time can cause problems for legitimate mailinglists if setup wrong.

Sure spam is a problem but these agressive filtering methods just introduce more problems. Users have to learn to stop giving out their email address everywhere and placing them on their website for crawlers to steal.

Postfix vs Postfix

[wrinkledshirt]

Andy gives you the scoop here on how well Postfix (and Postfix) do at the task.

Okay, it's too damned early in the morning to be getting repetitive and surreal in your opinions. What the hell is with "Postfix (and Postfix)"?

Security, Outlook Transmitted Diseases's, etc...

[Xibby]

I just skimmed things a bit, but somewhat suprised not to see topics like ssl and smtp-auth. I know I would have loved to see something like "your mail server is your first line of defence for Outlook Transmitted Diseases," but since it's mostly a procmail thing maybe it's mentioned. I encourage ever e-mail administrator to at least look at Email Security through Procmail [freshmeat.net]. By using this, I've managed to keep my network OTD free. :)

Blum never contacted Venema

[nirvdrum]

I think it should be noted as well that Richard Blum never once got in touch with Wietse Venema, the creator and maintainer of Postfix. I am willing to bet there are a number of bugs in the book that could have been avoided. Likewise, some of the more esoteric issues, such as DNS issues are completely cut out. For these, the postfix-users mailing list has to be used. Personally, I'd save my money and wait until the book with Wietse's blessing is released (and there is apparently one author working with him now -- though no other info has been released).

Re:Best MTA -- QMAIL

[AX.25]

I read the opposite, has far as postfix being 3 times faster, I saw no supporting evidence at the site to prove that postfix was any faster. As far as DJB's behavior, I see no attitude, only truth and well thought out opinion. He doesn't just come out and say something sucks, he says it and proves it. Ever heard of a root hole in POP3 or IMAP? Yes. I figured you had.

Qmail is the best.
1. Easy configuration - Read LWQ
2. Easy administration - Read LWQ
3. Security. qmail doesn't seem have any root holes per bugtraq.
4. Fast, proven by many large sites.
5. Great support for those who ask well researched questions.
6. Maildir (not mailbox) format much better than mbox. Usuable over NFS, non-blocking.

I don't worry about my qmail servers. I sleep well at night knowing that they aren't going to break.

Re:Postfix's own documentation is fine

[neves]

Postfix users mail list is also very good. Wietse Venema himself answers a lot of questions. I'm using postfix for years and never needed a book.

Re:Where's the SPAM?

[jaiteend]

/to logging and blocking UCE/UBE. /

looks to me like he does...

exotic languages and sexiness

[m08593]

Powering mail delivery may not be as sexy as programming in exotic new languages

You're right: what can compare with the thrill of writing software in a language in which every string manipulation or memory deallocation potentially opens up security holes. And nothing can compare with the dazzling display of software artistry in a language where every data structure has to be handcrafted over and over again.

Using a language that is just a tad more modern than the nearly 30 year old C programming language clearly couldn't compete with that kind of thrill. But maybe using something more modern would result in a program that's less than 100kloc and that more people can contribute to and modify safely.