[ILUG] Spam and more spam

[Philip Reynolds]

Rick Moen <rick at linuxmafia.com> 38 lines of wisdom included:
> Unfortunately, these miss 95% of the advantage of Marc's approach, 
> e.g., allowing none of sa-exim's callback capabilities.  
> 
> Essentially, Marc is leveraging what in any other circumstance would be
> considered a significant _disadvantage_ of the Exim architecture -- its
> non-modular nature:  All of his processing is conducted integral to the
> single Exim monolithic process. 
> 
> If you disagree, then please show me the Postfix configuration that 
> makes it selectively 45x teergrube, on a real-time decision basis, any
> delivering MTA whose SMTP stream is showing a SpamAssassin spamicity
> index of 10 or greater based on analysis of the full message body text
> (not just headers).  I'm not saying that's impossible in Postfix (though
> it may be, given its modularity), only that nobody's figured that out
> today, and that a great deal of work would be required to duplicate 
> sa-exim's functionality.

1) Providing this kind of functionality at SMTP level with Postfix
means leaving your server far more susceptible to DoS attack.

Consider an ever increasing volume of mail from time X to time Y.
Under normal circumstances, Postfix simply accepts the mail and
stores it in the queue. Processing is done *AFTER* postfix has
safely accepted the mail, written to disk and the remote client has
safely disconnected. This is the most common way it is done, because
it is the proper way to do it. Postfix doesn't take up much CPU
time, simply accepting a message, so even if it has trouble scanning
all messages, they are accepted and acknowledged as being accepted
to the remote server.

Now consider a large influx of mail where virus/spam scanning is
done in real-time. The more and more processes that get held up, the
more time it's going to take to respond to the remote server. This
*WILL* (this isn't a question of if, but of when) end up in mail not
being accepted due to delays.

2) Saying all of that, it is still possible to do this via the smtpd
policy daemon in the new snapshots. Although, currently, I'm unaware
of any implementations.

It wouldn't be too hard to create something based on the actual
example in SMTPD_POLICY_README that comes with Postfix, which is a
greylisting policy server.

Once again though, I must stress that if you run production level
servers for clients/customers who pay for their service, providing
real-time virus and spam scanning is asking for trouble. This should
not be done at the SMTP level.

Regards,
-- 
Philip Reynolds                      | RFC Networks Ltd.
philip.reynolds at rfc-networks.ie      | +353 (0)1 8832063
http://people.rfc-networks.ie/~phil/ | www.rfc-networks.ie