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>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
