On Sat, 2006-02-18 at 02:15, Bob Dodds wrote: > qpsmtpd catches a lot of spam and phishing at the > protocol stages. It's not just a content filter.
Agreed, but so does mimedefang. It gives you hooks to every part of the smtp operation. > "More efficiently" is troll bait, considering how much > inefficiency is due to spam, phish, and worm load and > how much "access" is determined by lookup calls to > the same other tools by either qpsmtpd or sendmail. The 'access' in question is a dbm style database and sendmail does matches against it in c code. I know there are valid arguments about perl code being as fast as c sometimes, but sendmail does this pretty quickly. My point was simply that if you can reject based on this before the message even gets to the slower network tests or content scans it will be more efficient. For example, if you normally relay to an internal server and a lot of mail still comes addressed to an ex-user, rather than doing the remote smtp check for every message you can put: To:[EMAIL PROTECTED] ERROR:550 user unknown in the access database on the outside machine to bounce it without going any farther. > qpsmtpd can use milters and mimedefang, so neither > of those is worth points in the sendmail column. This would be more convincing if you verified that someone has done it. I apologize for bringing it up and not actually making it work. Mimedefang appears to exercise most of the possibilities of the milter interface so I'll be surprised if it works on the first attempt. Some things may turn out to be fairly intimate with sendmail like the way you would pass, whether the connection was using a TLS certification or was authenticated through the milter interface. > And > I just implied in the previous column, ldap and sql > are not worth points in the sendmail column, since > qpsmtpd can use any lookup and auth method that > sendmail can. Of course - it is possible to write just about anything in perl. But most things people need have already been done when you combine the features of sendmail and mimedefang. I notice there is still work in progress getting remote smtp recipient verification to work before accepting a message to rely. Mimedefang has had that for some time although it doesn't have to perform the relay operation because that's built into sendmail. > Just what does sendmail exclusively have, and show > me its realtime smtp protocol filtering. It already has the ability to listen for smtp/smtps/submission at the same time without losing the relay IP address as you do with stunnel and can process starttls. It can use PAM based authentication (maybe it needs sasl for that..). It understands relatively complex schemes of virtual users, aliases, .forward files and the necessary recursive expansions to process them. > I know, you > are touting the "efficiency" of a vacuum, of a lack of > protocol filtering?! Must be. Mimedefang does the realtime protocol filtering part. You can filter based on the relay address, the envelope sender - actually any of the ESMTP arguments can be accessed during filter_sender(), the recipient, or you can add custom code. For example you can call md_check_against_smtp_server() inside filter_recipient to reject unknown users early if you are going to relay to another machine for final delivery. If you continue on to content filtering, mimedefang breaks out the attachments in temporary files so you can efficiently run your choice of scanners before the SMTP accept happens. If, in fact mimedefang will work with the qpsmtpd milter interface, none of this part would be exclusive to sendmail. -- Les Mikesell [EMAIL PROTECTED]
