On Mon, 5 Jul 2010, Karsten Bräckelmann wrote:
On Mon, 2010-07-05 at 02:31 -0400, Dan Mahoney wrote:
The greater problem is, that if for some reason spamassasin doesn't run
(for example, a spamc timeout(*)) it produces exactly the same effect.
Is there a way to have spamassasin/dspamd not scan messages above a
certain size, but still add headers (i.e. x-spam-status: skipped)? I can
No, SA cannot add headers in case the message size exceeds the spamc
threshold, because in that case spamc does not pass on the message to
spamd at all.
do it in procmail, and add a header that means something to me (and face
the additional problems of communicating this nuance to my users), but it
would be nice if SA had a standard way.
With procmail, the spamc -s option actually should be irrelevant to you,
unless *raising* the limit. Why have procmail pipe the message to a
filter, if we know it will be passed back unhandled?
:0 fw
* < 512000
| spamc
Now there are two ways to add various "skipped" headers. A trivial one
is negating the size condition.
:0 fw
* > 511999
| formail -A "X-Spam-Status: Skipped, too large"
A more fancy variant starts by using the spamc -x option in the above
recipe, disabling the default "safe fallback" of returning an exit code
of 0 regardless. Now errors will result in an actual error exit code,
while the unprocessed message still is passed back. See man spamc.
A procmail recipe to handle this must follow the spamc filter recipe
immediately, and looks like this, using the procmail error flag.
:0 e fw
| formail -A "X-Spam-Status: Error processing mail"
(*) with it's brilliant "try 3 times, 1 second apart" retry timer.
If this is merely about timing issues, where restarting spamd might
cause spamc to give up before the daemon is back, you could simply
adjust these. Both retry times as well as numbers of attempts are
configurable.
To do that globally, without even touching your procmail recipes, you
can use spamc.conf in your sysconfig dir. Again, see man spamc.
I have done so, and that may alleviate some of the problem.
However, while you've given me some procmail-based shortcuts and saved me
a bit of research, my point was that it would be very nice if the messages
and flags you mention were *standard* parts of spamd, and not just coded
into my (and only my) procmailrc.
It's probably fairly trivial to have spamc add only this header under
these conditions, and it would make it more compatible with third-party
tools that are out there, and as a bonus, spamc could keep within the
"principal of least surprise" by requiring an extra command line option to
add these headers, so not as to break existing scripts.
--
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
