This is not a dbmail issue perse. You're simple getting what you're
asking for :-) i.e. trouble.
First off, I'm assuming your spamc version supports the -s switch, and
is therefore defaulting to maxsize 256k, so messages larger than that
are not evaluated for spam probability.
Next I would advise investigating the resource throttling capabilities
for your MTA. Postfix simply lets you specify a maxproc value for you
local deliveries. Just set that value to something reasonably low. I
would guess that a value of perhaps 10 or 20 concurrent local deliveries
would do nicely unless you're chumming away massive amounts of email for
a large user community. In that case a 'reasonably powerful' machine
won't do anyhow.
If you want to manage resources more precisely you could split the
spamc/dbmail route to a seperate delivery transport. If you are using
postfix, just add a new transport in master.cf, i.e.:
spamfilter unix - n n - 10 pipe
user=nobody argv=/usr/local/sbin/spamfilter ${recipient}
where spamfilter could read like (straight from FILTER_README in postfix):
#!/bin/sh
# Localize these.
DBMAIL="/usr/sbin/dbmail-smtp -u"
# Exit codes from <sysexits.h>
EX_TEMPFAIL=75
EX_UNAVAILABLE=69
cat | spamc | $DBMAIL "$@" || \
{ echo Message content rejected; exit EX_UNAVAILABLE;}
exit $?
Philip Warner wrote:
We have a slightly unusual setup in that we pipe messages via
SpamAssassin just before delivery using the aliases:
| smapc -u <username> | dbmail-smtp -u <username>
but I think the problem we have found will occur with any locally piped
message.
We recently had a single message that was about 10MB in size and it was
delivered to 50 or so users. The way forward.c functions in the case of
a pipe is to open one pipe for each recipient, then read the input
stream and write it to each pipe. In this case it opens up 50 spamc and
50 dbmail-smtp processes. In processing the 10MB message, the machine (a
reasonably powerful one) almost died.
Limiting max recipient and/or limiting message size is not really an
option, so we are looking for other solutions. Especially solutions that
are likely to be included in the dbmail code, so we do not have to
maintain a patch.
What we are thinking of is either writing the message to a temporary
file, then sending to the pipes sequentially, or writing to a temp table
in the database, and doing the same.
We would appreciate any suggestions as to the best approach, and the
approach most likely to be incorporated in dbmail.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
