[MlMt] SMTP Timeout

[John Grasty]

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-20120120 at 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 <brad at shub-internet.org>
> LinkedIn Profile: <http://tinyurl.com/y8kpxu>
>
> _______________________________________________
> mailmate mailing list
> mailmate at lists.freron.com
> http://lists.freron.com/listinfo/mailmate