Mr. Cole and Mr. Knowles,
Thank you so much both of you for your wisdom on this subject. I will
definitely file this away for later. Since ASSP is working so well
currently at filtering spam, I may try to get this one issue debugged.
I've been grepping the logs, and besides the 4-5 times that I have timed
out on port 587 submitting, the only other timeouts have been spam
related.
At some point, I'm sure I'll get antsy and want to try out spam
assassin. I was hesitant as I heard that it can be a resource hog if not
properly tuned.
Thanks,
John Grasty
On 5 Sep 2014, at 13:40, Brad Knowles wrote:
On Sep 5, 2014, at 12:13 PM, Bill Cole
<mmlist-20120...@billmail.scconsult.com> wrote:
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.
The solution to the Cisco problem is to just turn it off, because it
breaks so many things.
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'm in the same boat, having been fairly seriously embedded in the
anti-spam/ASRG/Zorch community for years, starting in the mid-90s when
I was the Sr. Internet Mail Administrator for AOL and my primary
responsibility was building their anti-spam defenses. However, I've
been out of touch from that community for a while now.
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.
Yup.
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.
I haven't looked closely at MIMEDefang, but I have heard good things
about it.
One of the things I'm most proud of is that I was involved in the
postfix community from the days back when Wietse was still calling it
"VMailer", and I've known Ralf Hildebrandt and Patrick Koetter for
years (they're the authors of "The Postfix Book"). I was fortunate
enough to be able to draft them into helping me manage the mail system
for python.org, and I've learned a lot from what I've seen them do.
So, I'm definitely on board with the postfix+SpamAssassin solution,
although I've tended to go with amavisd-new as the interface between
the two. I've liked the fact that amavis integrates with both
anti-spam and anti-virus tools, and that there are a number of
anti-virus tools available for use with it.
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.
I've been using SpamSieve with Mail.app, and I've been much happier
with that configuration than letting Mail.app do the anti-spam stuff
on its own.
I'm still working on what I will need to do to make the switch from
Mail.app to MailMate, part of which may be setting up my own local
IMAP server on my laptop and having the IMAP client talk to it, and
then having the local IMAP server connect out to the various remote
IMAP servers to actually process the mail.
All my custom rules that I've developed for Mail.app is another
hurdle. It would be really nice if I didn't have to re-invent all
those wheels for MailMate.
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.
It was never a good idea, but many people never understood that. If
you do this, you're just turning yourself into the tool of spammers
who will abuse 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.
And if it does actually get back to the spammers, they'll be able to
tell the difference between a fake bounce and a real one, and then all
you will have done is prove to them that the e-mail address is
actually valid and that you're willing to go through some hoops to try
to protect it -- thus making yourself an even more high-value target.
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.
To this day, I still don't communicate with Marshall Kirk McKusick,
for exactly that reason. Ironically, his partner is Eric Allman.
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.
Excellent advice.
Thanks!
--
Brad Knowles <b...@shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>
_______________________________________________
mailmate mailing list
mailmate@lists.freron.com
http://lists.freron.com/listinfo/mailmate
_______________________________________________
mailmate mailing list
mailmate@lists.freron.com
http://lists.freron.com/listinfo/mailmate