Chris wrote regarding 'Re: [SLE] sendmail vs postfix.' on Fri, Sep 10 at 09:46: [...]
I'm not arguing against any MTAs here (I do have qmail running on 1 server), but the reason you'd use sendmail is the flexibility.
Lemme counter a few of these, just FYI:
Sendmail lets me: Keep multiple queues and filter messages into these queues based on destination and delivery attempts, this lets sendmail spend time delivering messages it knows will go through and leaving the slow ones for when there aren't more important messages waiting.
Postfix does that out of the box, with one queue.
It lets me queue before delivery when someone decides to mail the 10000 people on their mailing list, which allows me to determine what load the server will be under (because not all servers are strictly mail servers).
This one I can't rebuff because it's not totally clear to me. You want messages sent to a list distribution address to be deferred until you specifically release them from the queue? You can do that with postfix. If something else, I'm not sure. There's a delivery concurrency setting in postfix where you set the maximum number of simultaneous connections to individual remote servers, and there's now a daemon that limits the maximum number of incoming messages from any remote server (called "anvil" if you're looking for docs). In addition, you can limit the amount of CPU postfix takes.
Scan for viruses and spam with as little overhead as possible with Milter.
This used to be an advantage, as the "solution" under postfix was to run a pair of mail servers with one delivering to a script that then delivered to the second mail server. That's a kludge if I ever saw one. :) But the newer versions of Postfix do have arbitrary filter support, both through shells scripts or using some built-in parsers.
It lets me reject spam and viruses even before I accept them for delivery thanks to Milter. This prevents my mail server from having to deal with bouncing back messages to non-existant hosts.
But it slows down delivery and costs memory - and if something happens before the delivery stage the message is just lost. You also don't save any bandwidth, since you need to get the whole message in order to check it. Granted, I do this too, but it's not a perfect solution. BTW, I do it with postfix and spam assassin. :)
It lets me setup mail servers that deliver only in specific time frames to take advantage of lower Internet charges.
Again, you can do this with postfix (but I think you might also need cron to flush those messages - I don't remember off the top of my head).
Security problems are for the most part a problem of the past, and considering it's been around since the 80's, it obviously has a long "past". A number of security problems were the result of insecure setup more than anything. It's also actively maintained and has an excellent track record of promptly responding to all kinds of bugs.
Postfix was designed from the ground up to maximize security. That's one of the reasons behind having a bunch of small programs that just do one part of the delivery process each, rather than a huge process that does it all. Most of the sub-tasks don't require any elevated priviledges, so they run without them. Postfix is good about dropping privs as soon as it can. While modern sendmails are definately more secure than they used to be, the track recod left a bad taste in the mouths of many. It is also real easy to break a sendmail install in such a way as to make it insecure, whereas postfix is more resistant to that kind of thing. If you know what you're doing with sendmail, though, sendmail can handle a lot and can do a lot. It's a mature program with a huge installed base. Then again, so is bind, and it's constantly breaking - but I still run it. :) I'm not arguing that sendmail should be abandoned, but if anyone is running it exclusively for the above reasons, they might go check out postfix.org and see how a more efficient, more secure MTA could be of help. Readable config files are reason enough, IMHO. :) The site is pretty well done, and the program's well documented with a very active mailing list. --Danny