Pablo Alsina wrote:
> Hi
>
> I'm having some troubles on a high-traffic MTA. The mailserver runs
> sendmail and maildrop, configured to scan messages during the local
> delivery, using spamc, against a different server running spamd.
>
> I wish to have all local mail scanned, but if there is a problem with
> SA, or SA is taking too long, have the message delivered locally
> without being scanned. I do not want maildrop to exit with a
> EX_TEMPFAIL when SA fails.
>
> So spamc is invoked from maildrop with:
> xfilter "/usr/bin/spamc -d 1.1.1.1 -f -t15 -s150000"
> (-f to continue if something fails, and -t15 to wait 15sec max.)
>
> On the SA server, I have spamd running with:
> spamd -d -u spamd -i -s local4 -m15 -x -r
> /var/run/spamassassin/spamd.pid
>
> It all works great, unless we have a spike on the amount of mails/sec
> handled, which usually happens once or twice a day. When the load goes
> up, I get a large "queue" of spamc processes (around 140 this
> afternoon), all waiting to be scanned by spamd. During that time, some
> of them takes more than 5 minutes, and then maildrop cancels and exits
> with a EX_TEMPFAIL error. This causes sendmail to queue the message
> for around 30 minutes, and then try local delivery again:
>
> Mar 15 12:45:58 vmail-av1 sendmail[7232]: k2FFhvrA007204: timeout
> waiting for input from local during Draining Input
> Mar 15 12:48:58 vmail-av1 sendmail[7232]: k2FFhvrA007204:
> to=<[EMAIL PROTECTED]>, delay=00:05:01, xdelay=00:05:01, mailer=local,
> pri=36466, relay=example.com, dsn=4.0.0, stat=Deferred: local mailer
> (/usr/bin/maildrop) exited with EX_TEMPFAIL
>
> (note the xdelay=00:05:01).
>
> So it seems like spamc is not honouring the "-t 15" flag when invoked
> from maildrop.
>
> But when that happens, I tried to to a manual scan of a message from a
> file, using -t1 for example, and then spamc exits outputting the
> messages without being scanned, just like I would like it to behave
> from maildrop.
>
> I'm using SA 3.0.5 on a CentOS system. I saw the release notes for SA
> 3.1.1, which includes the resolution for bug ID 3710, related to the
> -t flag, but I'm not having the problem described on that bug. From my
> experience, SA seems to honour the -t flag when invoked from command
> line.
>
> Any clue? Should I invoke spamc differently? Should I upgrade to
> 3.1.1?
Try putting an exception block around the call.
exception {
xfilter "/usr/bin/spamc -d 1.1.1.1 -f -t15 -s150000"
}
This way, maildrop will continue the delivery even if the command fails.
Of course, this assumes that maildrop will continue to read the script and
not just kill the entire delivery process when it times out.
--
Bowie
