On Wed, 2010-07-21 at 01:12 -0700, Ted Mittelstaedt wrote:
> On 7/20/2010 11:55 PM, Daniel Lemke wrote:
> > To hijack the thread: Does anyone know an optimum for message size limit?
> > Ours is set to 2MB at the moment, but we have problems when receiving large
> > text mails (e.g. more than 1MB) as the message check will become REALLY time
> > consuming. This leads to a curious situation where our Exchange (or maybe
> > it's the external mail server, not sure of that) sends the message again
> > after ~55 seconds, so the next child begins checking the mail... And there
> > we've got a loop (until the server runs out of memory)...
So *why* does Exchange re-try after less than a minute?
> > I set the --timeout-child of spamd to 45 secs now, what's working as a
> > workaround for now, but there may exist a more solid solution, is that
> > correct?
That's a rather low timeout-child value. And it isn't clear if that 45
secs is a raised or lowered timeout, compared to what you had before.
If it was even lower before, then that seems to be the issue. And might
even explain the impatient Exchange. If, however, it was higher before,
and you lowered it to timeout faster than Exchange forcefully re-trying
a mail that's still being processed -- you should look after Exchange.
FWIW, the default is 300 secs. And yes, processing might occasionally
take longer than 55 secs.
> We use the stock default which is 250k and it's fine. I would not go
The default is 500 kB. Has been for a while now.
> over 1M, frankly. Consider that in the time a spammer can send a 2MB
> spam, they can send 64 64k messages, and even 64k is a huge bit of text
> to get your hair tonic message across. A single typed page is
> around 4k.
Just a gut feeling, but I probably wouldn't raise the threshold above
1M, either. Mostly using the default. I have seen spam larger than 500k,
and even larger than 1M, but these are rare.
Ultimately, it also depends on your mail flow, as your description shows
eloquently. If your ham > 500k usually means a binary attachment, you
hardly will notice any difference. But if you frequently receive ham
with large text parts, CPU intensive processing time is likely to go up.
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
