Aaron Stone wrote:
I've been thinking about supporting the virustest/spamtest Sieve
extensions by way of linking to other popular open source virus and spam
testing libraries. It's a bit of a ways off, and it means tieing things
into Sieve rather than the MTA -> LMTP (...) -> DBMail-LMTP delivery
chain, which if not easier to set up is at least discrete parts that are
individually maintained.
Like many things in the email world, there's a place for both ;-)
My opinion is to keep things highly segregated and simple where you can.
Plug them together to make better applications.
Just like unix pipe (|).
I think it's great that dbmail does one conceptual function (MDA) and does it
well. To start adding MTA features to it muddies the picture. Adding spam and
virus functions to it also muddies the picture.
With spam and virus checking a lot of people use many different approaches
depending on what they feel is important. If dbmail can't address all of these
then you have an installation of dbmail that has a lot of features turned off.
An example of these arguments might be:
using clamav on a remote machine that filters all mail -- inbound & outbound for
larger companies with many clueless users who will gladly mail I_LOVE_YOU to
everything they know. dbmail can't manage outbound virus scanning.
using spam filtering applications that are also on remote machines to handle the
additional load or to concentrate all the spam filtering from many mail proxies
into one group of spam filtering servers.
using spam filtering as a pre-queue filter instead of a post-queue or
pre-delivery. There is an increasing number of applications being developed
that sit in front of the MTA to filter for spam. Some instances are postfix
with content_filter or standalone applications that monitor port 25. These are
different from the content_filter variants for postfix (Amavis) which are
considered post_queue. The spam filtering advantage of these is the email is
rejected rather than every being accepted by the MTA.
putting spam filtering or virus scanning into dbmail might be able to address
some of these. But it can not address the pre-queue or pre-delivery spam
filtering mechanisms. So you run the risk of developing and maintaining a block
of code that a lot of people may never use may also consider to be bloat.
A personal opinion about amavis and spamassassin is that the number of options
that they now present are unwieldy and makes getting the installation correct
and logistical nightmare. Sure, you might be able to get things running with
only 5 configuration entries -- but there's another 100 to administer if you
want to fine tune things. It's a kitchen sink set of applications and one of
it's biggest complaints that I hear these days is that it is relatively slow and
bloated.
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
