Mailing List SIMS@mail.stalker.com Message #14958
From: Bill Cole <listbill@scconsult.com>
Subject: Re: [OT] Alternate MTAs [was Blacklist Setting]
Date: Tue, 19 Apr 2005 12:51:22 -0400
To: SIMS Discussions <SIMS@mail.stalker.com>
At 10:04 AM -0500 4/19/05, Joe Laffey  imposed structure on a stream of electrons, yielding:
On Tue, 19 Apr 2005, Dave Pooser wrote:

On the other hand, I'm just a bit of free time away from migrating
off of SIMS, and I expect that Tiger will make that simpler by having
a more current version of Postfix than Panther.

I'm currently using CGPro, and hang out on this list only because it's where
I learned 90% of what I know about SMTP and anti-spam techniques. (Probably
80% of what I know about SMTP and anti-spam techniques came courtesy of one
Bill Cole, incidentally, and I hope you'll hang out here even after you move
on to another email program.)

That said, I'm looking at handing off SMTP duties to Exim; I looked at
Postfix but I thought Exim's ACLs made it a better choice because there are
more opportunities to reject spam vs. accept and then bounce/bitbucket/other
sub-optimal solution. Is there a reason that you're looking at Postfix over
Exim?

Been using Postfix for years here. It provides some pretty in-depth spam control, with chances to reject/accept, etc. at many stages along the way. Also, there are a number of reasons you would not actually want to reject the message until the whole thing is received (see the postfix mailing list archivers for this).

I'm aware that for some time Wietse Venema resisted synchronous filters with some well-considered operational arguments, but modern filtering needs in conjunction with a need for transparency has trumped that in the latest versions of Postfix. The model of accepting mail and queuing it for a filter operating  on the body rather than passing it to that filter and letting it decide the proper response to the second step of the DATA command leaves you in a bad spot in regards to mail that a potentially imperfect filter identifies as unwanted. The 'correct' action when that second layer rejects mail would be to construct a  bounce message addressed to the envelope sender of the original. However, most spam and malware mail these days carries forged senders in resolvable domains, so doing that with most of the mail a filter deems to be spam or malware means sending bounces to addresses that either do not exist or belong to forgery victims. If you don't bounce such mail, then any false positives are silent. The result is a situation with no suitable action that can be taken without certainty of causing problems.

Venema's objections to the synchronous filter model were essentially that it makes the MTA dependent on the filter, which is likely to be slower than the MTA and can fail independently of the MTA. With an asynchronous queue between the SMTA and filter, the MTA can accept mail at full speed as needed and let the filter catch up  during slower periods, but if the MTA has to wait for the filter before queuing it may be stalling other work. That's a real concern, but the risk is less for some sites than the certain dilemma caused by asynch filtering.


--
Bill Cole                                  bill@scconsult.com

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster