Postfix 2.1 Released 286
MasTRE writes "After an extended period of polishing and testing, Postfix 2.1 is released. Some highlights: complete documentation rewrite (long overdue!), policy delegation to external code, real-time content filtering _before_ mail is accepted (a top 10 most requested feature in previous versions), major revision of the LDAP/MySQL/PGSQL code. Version 2.2 is in thw works, which promises even more features like client rate limiting and integration of the TLS and IPv6 patches into the official tree. There's never been a better time to migrate from Sendmail (just _had_ to get that in there ;)."
Re:Why does everyone alwasy gotta knock sendmail?? (Score:2, Insightful)
My preference is qmail, only because I haven't used postfix in a production environment yet.
missing step (Score:5, Insightful)
Nowhere did I see:
"-read the changelog notes to see if any of the numerous changes classified as "incompatible" affected me or my users".
SASL, spam, viruses (Score:2, Insightful)
And it looks like content filtering (spam & virus filters) has been improved with version 2.1
Developers?? (Score:3, Insightful)
Great software, bad hardware (Score:1, Insightful)
Re:because it's an ugly, lumbering dinosaur (Score:5, Insightful)
You may or may not be correct in this particular case, but as a general statement, that's just stupid.
Do you really mean that the exact same settings for a little desktop (high priority to input-related tasks, swap only when needed) would work well for a high-load server (high priority to compute-related tasks, swap agressively to make RAM quickly available)? There are a lot of settings on a modern system that just can't be inferred by the system itself. Stating the opposite like it's an obvious fact is ignorant, misleading, or both.
A real-world example: a Usenet spool and an MP3 repository may be the same size, but benefit hugely from tweaked bytes-per-inode or journal settings. In some cases, once the system is running, it's too late to easily change your mind (like bytes-per-inode). In other cases, you can switch at will, but not without unmounting the filesystem (ext3 journaling options). You, as the administrator, make those decisions. Either way, even if the computer were capable of recognizing that you'd made a bad decision, it's not in a position to correct them.
A real-world example: I tuned Sendmail to use delayed sending so that when a client blasted 20,000 copies of a newsletter (yes, opt-in), then it would wait for several minutes so that it could efficiently aggregate recipients by domain. In there situation, telling Sendmail to leave email in the queue for 10 minutes meant a 50% savings in bandwidth. How on earth would you expect a self-tuned MTA to ever make that discovery on its own?
Computers do some things well. Predicting the future usage patterns of their owners without mounds of previous input is not one of them. That's where manual tuning comes in, and why real system administrators still paid decently.
Re:this SMTP server vs Qmail and Sendmail (Score:5, Insightful)
I wonder when people will stop repeating this rubbish. Qt has been GPL'd for years. It is also available under a commercial licence, but that has nothing to do with KDE, it's in case you want to develop a closed-source application with Qt. (And it seems to be an excellent business model.)
As for qmail, you're not allowed to distribute modified versions, and the rules on distributing binaries are rather stringent and almost impossible for distributors to follow. That makes it not quite "free software" (by FSF's definition) or "open source". (However, you're allowed to distribute patches, and even bundle patches with unmodified source in a tarball; you can download one such tarball, called netqmail, from http://www.qmail.org).
Re:Why does everyone alwasy gotta knock sendmail?? (Score:2, Insightful)
Technology like everything else has a life span. Sendmails ended long ago, get over it.
Re:Grudgingly going back to Sendmail. (Score:4, Insightful)
Re:Grudgingly going back to Sendmail. (Score:4, Insightful)
Too bad the rest of us aren't experienced mail administrators like you are.
Re:Why does everyone alwasy gotta knock sendmail?? (Score:4, Insightful)
Why all the MTA anti-sendmail holy wars? (Score:5, Insightful)
I can't quite understand the religous flame wars over MTA choice either. I mean, I can kind of understand the whole emacs vs. vi or gnome vs. KDE. But why fight over MTA's? It seems there is an awful lot of hatred for sendmail, and for no good reason whatsoever. It's just stupid.
I think a lot of it has to do with sendmail having such a long and rich history; anything which has existed for over a decade tends to get a lot of newbie disapproval. Also the configuration can be rather complex, and I think most people who flame about sendmail just don't want to 'fess up to being too dumb to understand it (with my asbestos suit on), and so resort to juvinile name calling.
Also you have to remember that probably 95% or more of the
And about the security-flaw reasoning. That's just an easy way for flammers to badmouth sendmail without really giving true reasons. Any software which has had such a long history and unbiquitous use as sendmail has a history of security flaws. For that matter Unix itself has had an absolutely abismal security record. And yes, someday Postfix will have it's own history to brag about too. But in all cases the flaws were quickly fixed, and the vast majority of flaws required a very specific configuration to even be a problem. Also many security problems result from improper installation; you can run sendmail in a very security setup if you want (just avoid all the FUD about sendmail). You can't compare Postfix and sendmail based solely upon their history of security, because sendmail's history is decades longer than Postfix's. And sendmail has processed perhaps a million trillion times as many email messages as has Postfix over it's lifetime.
Re:Why all the MTA anti-sendmail holy wars? (Score:5, Insightful)
Postfix has several security policies:
1) no process will ever _touch_ user data as root
2) all data is converted into fixed-length records for internal use
3) each program is small and does one task using the least privilege concept
There are others, but I can't think of them right now. Up until V8, sendmail had the monolithic, let's-run-everything-as-root concept. It's not that sendmail has flaws, it's that sendmail is so susceptible to flaws just by its design.
Again, I'm not aware of the improvements done in V9, as I had already switched to Postfix.
Re:Why all the MTA anti-sendmail holy wars? (Score:5, Insightful)
Incorrect. What Postfix does is BREAK UP a message into fixed-length pieces so that a buffer overflow CANNOT occur.
Buffer overflows are a problem when you ASSUME that a field is of X length but it's actually Y. Since Postfix breaks up lines into fixed-length quantities, it prevents lots of potential problems because there is no way that a line could overflow.
Re:this SMTP server vs Qmail and Sendmail (Score:4, Insightful)
Re:Sendmail upgrade? (Score:3, Insightful)
I wrote a Perl-based whitelist program [outshine.com]. My biggest problem in the Exim vs. Postfix wars is that Exim (at the time I wrote the whitelist app) doesn't offer all the status codes that Postfix does. So my ability to bounce email with informative messages is limited in Exim. Postfix, no problem. But since you seem to know all about Exim's features, what can you tell me about the last 18 months of development? Do it offer more in the way of response codes?
parent is so wrong, it's not even funny (Score:5, Insightful)
It is not the MTA's (Mail Transfer Agent) job to put the mail on the filesystem, that's the MDA's (Mail Delivery Agent) job. Sendmail is a Mail Transfer Agent. Sendmail, for as long as I've known, as a pluggable MDA format, where you can put in any MDA you choose. You can easily build your own MDA for Sendmail. Not to mention if you use Milter.
This is rudimentary internet mail handling.
For example, I use Cyrus IMAP's MDA with sendmail; and thus sendmail simply hands the Cyrus MDA my mail once sendmail has figured the mail belongs on this server.
Thus in a way, Sendmail, Postix, and all other MTA are essentially routers.
Re:Grudgingly going back to Sendmail. (Score:2, Insightful)
I thought not. SMTP doesn't work that way. A mail server tries all possible MX servers, in order.
If my primary is, for god know what reason, unreachable, then it wastes a single second of the mail sender's time to check the backup before queueing the mail. That's the entire net effect. You'll get your delayed mail a second later, in theory, which doesn't actually happen because no one runs around setting retry timers that trigger the exact second anyway.
As for relay servers...you need hundreds of those why, exactly? You're operating one of those crazy-ass overloaded networks, apparently, where mail bounces through two or even three SMTP servers both going in and out.
Those networks are brokenly designed. Sorry, but it's true. I understand why you can't fix them at this point, but it doesn't mean they were designed correctly.
There's absolutely no reason not to have a single incoming point (Or even sets of points, via NFS directories.) for each account, where a message comes in and is stored 'locally', and absolutely no reason not to have one outgoing server for each outgoing message, when then sends the message directly to the recepient. (Those can be the same system, or not.) And maybe backup MXs for collecting mail when the system is down. No one has ever explained to me why a mail system needs to be more complicated than that. Anything more complicated than that is probably just historical nonsense laying around.
Re:Grudgingly going back to Sendmail. (Score:2, Insightful)
If you're having an excessively large volume of mail, and want to add more relay servers, the solution is to add more identical servers with round-robin DNS, and possibly a larger pipe.
Having them pass mail among themselves via a shared NFS server isn't going to help anything at all. The ideal solution would be to have most mail in and out in ten seconds.
And, if large amounts of undeliverable mail are piling up, a shared queue just hurts things, not helps them. That just means every server will check every message to see if it's time to deliver it, repeatedly. Over the network.
Now, if he wants to do something sort of like this that actually help, a solution would be what postfix calls a 'fallback relay'...a server where mail that can't get delivered in X time goes. Where you can have some extra sanity checking that will quickly delete mail that can't ever be delivered, but you don't want to run on every message.
Re:this SMTP server vs Qmail and Sendmail (Score:4, Insightful)
I agree myself too. I *like* Qmail better than Postfix... but I realise that Postfix has a gurenteed future so that's what I run.