On Fri, 2006-02-17 at 18:19, Elliot Foster wrote: > I would still like to know what your original point was. That John > should/could run sendmail instead of qmail and qpsmtpd?
I didn't mean to start MTA wars here. My point was that sendmail is already fairly feature-complete and if your reason for using qpsmtpd was for the extra stuff you can glue for spam/virus and similar checks, MimeDefang allows that just as well. So, he probably could run sendmail. I wouldn't go so far as to say he should. Some people don't like sendmail and there is no accounting for taste. > I would agree with you that sendmail has many more options than qpsmtpd, > but as I said in my previous email, I added LDAP functionality (for > authentication and recipient verification) to qpsmtpd in less than an > hour. I would question how long it took to get the same functionality > into sendmail. Probably a long time, but it's already done. > Also, sendmail has been around for a little bit longer > (10+ years?) than qpsmtpd, so it's not suprising to see that it has more > features. :) Yes, but what's the point in duplicating features in free software? > I also wouldn't use 'speed' and 'sendmail' in the same sentence, > either. Maybe you're referring to the v9 rewrite, or maybe I'm biased. :) The only place you can really fault sendmail speed-wise is for the number of DNS lookups it does per message and for defaulting to putting everything in a single queue directory. In both cases it isn't sendmail code that is slow, it is just at the mercy of your DNS server and filesystem code when it looks things up. The part that handles the access database where you can reject based on sender/recipients and an assortment of circumstances happens much faster than anything you can do in perl. -- Les Mikesell [EMAIL PROTECTED]
