Quoting Andre M. V. ([EMAIL PROTECTED]): > Your other response is the same exactly last year, and > I have responded to them appropriately. Have noticed > too from this thread that you responded when you can > defend your position and just keep silent if someone > refutes you like Rick's mentioning that your reference > benchmarks are old.
In fairness, practically _all_ benchmarks one sees cited turn out to be old. ;-> And I trust to the intelligence of admins to take this recurring problem into account. As I said earlier, people tend to get much too worked up about all this. An additional note: There's a fifth choice that should be considered alongside Postfix/Qmail and Exim/Sendmail: Courier, http://www.courier-mta.org/ . I really don't know much about it. It was started by someone trying to work around limitations in procmail and Qmail, and also to design better webmail and IMAP/LDAP support, starting in 1997. Project history and rationale are here: http://www.courier-mta.org/history.html The author has some interesting observations about Qmail: Around the same time I was becoming slowly dissatisfied with Qmail. It was a raw, efficient, mail relay, but it lacked a lot of features, in fact besides raw SMTP delivery, it had very little else to show for itself. It couldn't do much more than deliver a single message, to a single recipient, on a single remote mail server, in a single connection. It was not capable of batching all recipient for the same domain in the same delivery. When it had a message with 100 recipients at domain.com, it would dutifully open a connection to domain.com's server, send a single message to a single recipient, close the connection, then lather, rinse, and repeat 99 more times. It would do all of these deliveries in parallel, true, up to the outbound concurrency limit, but it was still wasted a lot of bandwidth and time. Qmail could not open a single connection, and send just one message addressed to all 100 recipients. Qmail did not support delivery status notifications, and did not properly handle 8bit MIME mail -- it would send 8bit MIME mail to a mail server even if it did not advertise support for 8bit MIME mail. Additionally, Qmail's design forced the server to accept all mail for any recipient with a local domain address, and bounce mail for nonexistent local recipients internally. Qmail was not capable of rejecting mail addressed to nonexistent local mailboxes. I wrote some patches to fix that, but that was merely another hack. Additionally, DJB didn't seem to be actively developing Qmail anymore. There were occasional mentions of the next version of Qmail, over the course of a couple of years, but very little to show for it. There were also some licensing issues with Qmail that some people did not like. There's got to be a better way. Fans of Qmail would probably reply that the relatively sparse feature set and simple delivery mode are the price one has to pay for secure, auditable code that behaves in predictable ways. Feature-itis tends to create security risks and unintended interaction effects. -- Cheers, "Why is the alphabet in that order? Is it because of that song?" Rick Moen -- Steven Wright [EMAIL PROTECTED] _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
