On 2/21/07, Nico Meijer <[EMAIL PROTECTED]> wrote:
Hey Darren et al,
> IMHO you're trying to find a technical solution to a bigger problem.
He could ask the boss for 'more' hardware. Most problems tend to go away
when thrown adequate amounts of money at them, and timeouts because of
scanning and filtering is probably one of those types of problems.
Problem is, with the overhead that come content filtering imposes
(think Perl on the backend, etc.) even beefy hardware starts to be
impacted under heavy load. Think of how much spam overhead certain
organizations see even if their "legitimate" email load is low; all it
takes is too many of the right (or wrong) peoples' email addresses
harvested and you'll find yourself hit *hard*.
This is why so many solutions end up being "don't scan large files",
which in itself is not a solution, it's an excuse.
So is "our users are too dumb to do things the right way." They'll
continue to be this dumb until IT starts to push back on them. There's
no problem forcing someone to realize that even technology has its
limitations; some organizations do this well, others don't. Don't hate
it till you try it.
> If you're pounded by spam, consider implementing spamd in front of
> your mta (externally) to cut down on the volume that your content
> filters have to process.
The only complaints (about 5 in the last 3 years) I get is that it
sometimes takes 1 to 1,5 hours for messages to arrive.
I've had good success pointing out that email architectures by
themselves are prone to delays (because of the many MTA hops
traversed) and that expecting instant messenger style responsiveness
out of queue and forward is not reasonable. Once people buy into this
the greylisting sell becomes easier, in some cases.
DS
