On 5 Sep 2014, at 0:57, John Grasty wrote:
Benny and Bill,
Thanks. Mr. Cole, you nailed it. I changed from opensmtpd (which I
love) to postfix, and I went from an outsourced spam filtering to
ASSP, a behemoth of a perl script that is a "transparent" proxy. So
far it has done a great job at filtering, but this certainly seems to
be their problem.
I will do some additional debugging to narrow down which failure it is
(I suspect the former), and try to hound them to fix it.
There are inherently hard problems with transparent SMTP proxies, some
of which can be avoided by carefully harmonizing proxy & MTA settings.
There's probably more hope for making ASSP work than Cisco's knob-free
kludge.
Bill, as you seem to be quite knowledgeable in this arena, what is
your preferred server side spam handling technique? Off list reply is
fine.
[Replying on-list, since it may be useful for MailMate users more
generally ]
CAVEAT: I have made my living for over 2 decades in part by managing
mail servers, have spent some of that time highly focused on spam, and
my primary email address has a remarkable amount of spam (and little
else) directed to it, so my preferences are more than slightly biased by
an immersion that makes me blind to ease-of-use.
I work with multiple MTAs that use different toolsets, with a common
theme of layered spam control: any good MTA can handle some filtering
itself cheaply, policy and content filters hooked into MTAs can do more
complicated things that may be more resource-intensive, and ultimately
some spam/ham discrimination is left to client-side tools and/or human
eyes after delivery.
My favorite server-side tool stack is Postfix, MIMEDefang, and
SpamAssassin. MD is a 'milter' that can also be used with Sendmail and
anything else implementing Sendmail's milter interface. MD loads the SA
modules for content filtering, can interface to other tools such as AV
scanners, has its own mature MIME-based message manipulation functions
(the origin of its name), and is designed to be customized via Perl
functions that are called at the different phases of an SMTP
transaction. While MD itself is useful for custom "policy" filtering,
most of what I use it for is SA scoring. SA has a strong default
configuration but it really shines when adjusted to a specific local
mailstream: rule score adjustments, custom rules, white/black lists,
auto-whitelisting, and some mechanism for feeding its Bayesian database
wisely and regularly. I use the MD+SA combo with Sendmail as well and
manage CommuniGate Pro servers that use SA via its spamd/spamc interface
and a custom "Helper" linkage.
For post-delivery client-side tools, I don't have a single preference
because I don't use any myself. One of the few things that Mail.app
seems to do well is its internal Bayesian(ish) filtering and for
MailMate the obvious choice is SpamSieve.
There are common features one should NOT use in spam filtering:
1. Server-side "SMTP Callback" a.k.a. "Sender Address Verification". I
believe this was on by default in early versions of ASSP but it is
inherently a bad idea: just don't do it.
2. Anything in a client filter that attempts to fake a "bounce" to the
sender of spam, as that really can't be done correctly after delivery,
is unlikely to actually go anywhere useful, and may be treated as spam
itself.
3. Automated "Challenge/Response" auto-replies send to previously to
unknown senders. As with 1 & 2, this sends garbage to impersonated 3rd
parties innocent of the spam prompting it.
4. If your mail server has a "learning" mechanism fed by particular
folders or IMAP keywords, DO NOT let a client-side tool (e.g. SpamSieve)
automatically mimic what a user would do to "mark as spam" or "mark as
non-spam" for training the server's database. Those functions for
Bayesian and similar server-side systems are designed for human-judged
input to reverse misclassifications, not "second opinions" from other
(maybe dumber) software. Really smart providers who offer training
functions have distinctions between the spam judgments of server tools,
client tools, and actual humans.
_______________________________________________
mailmate mailing list
mailmate@lists.freron.com
http://lists.freron.com/listinfo/mailmate
