On Wed, 2005-11-30 at 22:38, Gavin Carr wrote: > > > > Yes, it is so far wrong and has licensing that prevents others from > > fixing it that there is a project to completely replace the front > > end component: http://smtpd.develooper.com/. > > Hmmm, that's not quite how it happened. qpsmtpd was written by people who > _like_ qmail but wanted to be able to do some funky things at smtp time > that were never going to work shoehorned into qmail-smtpd. But I second > the recommendation. In code with more reasonable licensing, they could have reused the existing code, adding what they wanted and fixing the broken parts. Since it's qmail, they had to replace an entire component. > qpsmtpd also has a vanilla smtp-forward mode so you use it in front > of any standard mta. The nice thing qpsmtpd brings to the table (as > opposed to things like amavisd, MailScanner, etc.) is the ability to > identify and refuse spam at smtp time, often even before the mail data > itself has been received, which translates to much lower load. Why > accept spam at all to just bounce later? Sendmail has that ability when you add suitable processing through the milter interface. The milter(s) run concurrently and can respond at each phase of the smtp conversation so you can reject based on content. MimeDefang is a particularly handy milter because it lets you control all of the things you might want to do (spamassassin, virus scan, network checks, etc.) in one place with a small snippet of perl, and it doesn't affect anything sendmail already handles. For example, why waste the CPU on the spamassassin scan if your access rules already block the sender? And if the original poster is still reading, there are commercial versions (Canit and Canit Pro) that have additional features like a web interface for individual users to control their spam handling. http://www.mimedefang.org http://www.roaringpenguin.com/ -- Les Mikesell lesmikesell at gmail.com