Hello,
John Goerzen writes in <http://bugs.debian.org/297915>
> Spamassassin is giving me trouble, using 40+ minutes of CPU time to
> process some messages, but I would think that exim4 should be more
> resilient in the face of this.
Of course Spamassassin *should* _not_ take that long on any decently sized
message, however being complicated software it can be buggy. Therefore
it'd be nice if it was possible set a maximum time spent on invocations
of spamassassin in exim, e.g. _something_[1] like this:
spam = nobody:true/timeout=1m/timeoutaction=defer
thanks for considering, cu andreas
[1] You might consider "timeoutaction" creeping featurism and choose
to handle "failure triggered by specified timeout" the same way as
other spam errors, i.e. causing DEFER unless defer_ok is specified.
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
http://downhill.aus.cc/
John Goerzen writes in <http://bugs.debian.org/297915>
> Spamassassin is giving me trouble, using 40+ minutes of CPU time to
> process some messages, but I would think that exim4 should be more
> resilient in the face of this.
Of course Spamassassin *should* _not_ take that long on any decently sized
message, however being complicated software it can be buggy. Therefore
it'd be nice if it was possible set a maximum time spent on invocations
of spamassassin in exim, e.g. _something_[1] like this:
spam = nobody:true/timeout=1m/timeoutaction=defer
thanks for considering, cu andreas
[1] You might consider "timeoutaction" creeping featurism and choose
to handle "failure triggered by specified timeout" the same way as
other spam errors, i.e. causing DEFER unless defer_ok is specified.
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
http://downhill.aus.cc/