Les Mikesell wrote:
On Fri, 2006-02-17 at 15:45, Ask Bjørn Hansen wrote:
On Feb 17, 2006, at 9:43 AM, Les Mikesell wrote:
Wouldn't it at some point be simpler to run sendmail as the
front end since it already knows how to do this stuff?
It depends.
I run qmail-smtpd (with TLS and AUTH patches) on the client relays,
but if I had a user database integrated with qpsmtpd already it'd
probably be easier to set it up in qpsmtpd instead. Or if you want
other qpsmtpd plugins running, for example virus filtering on
outgoing mail... (the usual reasons to run qpsmtpd ;-) )
Yes, but MimeDefang does all the same stuff that you can do
in qpsmtpd - or if it doesn't it would be easy to duplicate
there, and it works with sendmail. And the things you can
control in sendmail's access file are handled more effeciently
than you can do it in perl. Qpsmtpd is a neat idea but there
is just a lot of functionality to duplicate to match sendmail
plus a milter.
qpsmtpd catches a lot of spam and phishing at the
protocol stages. It's not just a content filter.
"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.
qpsmtpd can use milters and mimedefang, so neither
of those is worth points in the sendmail column. 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.
Just what does sendmail exclusively have, and show
me its realtime smtp protocol filtering. I know, you
are touting the "efficiency" of a vacuum, of a lack of
protocol filtering?! Must be.
-Bob
