You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Dan Mahoney, System Admin" <da...@prime.gushi.org> on 2010/07/05 08:31:01 UTC
Adding headers on spamassassin ignores?
Hey all,
>From what I've gathered, there's both a recommended way to call
spamassassin/spamd from procmail with a message-size-limit, as well as an
overrideable builtin-default (-s option to spamc).
These both cause the usual spamassasin headers to be missing from
messages.
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
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.
-Dan
(*) with it's brilliant "try 3 times, 1 second apart" retry timer.
--
"If you need web space, give him a hard drive. If you need to do something really heavy, build him a computer."
-Ilzarion, late friday night
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
Re: [sa-list] Re: Adding headers on spamassassin ignores?
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Mon, 2010-07-05 at 13:45 -0400, Dan Mahoney, System Admin wrote:
> On Mon, 5 Jul 2010, Karsten Bräckelmann wrote:
> > > (*) 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.
I guess that's a typo and you meant spamc, no? spamc, the lightweight SA
client, written in C, not Perl.
> It's probably fairly trivial to have spamc add only this header under
It's not that trivial by far to do this consistent with spamd behavior.
spamc does not add any headers, and in fact does not parse the message
at all.
Simply pre-pending an error indicating header would indeed be easy, but
is prone to break badly. Feeding spamc a raw mbox mail with the From_
line immediately comes to mind. Also, to be consistent with spamd,
existing X-Spam headers would need to be handled.
> 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.
On the other hand, instead of re-inventing the wheel -- coding all the
above requirements into your procmailrc *is* rather trivial. [1] Most
of the recipe magic I mentioned in my previous post already. To also
remove any existing X-Spam header, just like spamd does, once again
formail is your friend. '-I X-Spam' does the trick.
Note that the full solution is a mere 2 line procmail recipe. As opposed
to the work necessary to teach spamc how to parse mail...
And no, this is not frequently requested. From memory, you're the first
to ask for it.
guenther
[1] Granted, only if you happen to be quite familiar with procmail. ;)
--
char *t="\10pse\0r\0dtu\0.@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; }}}
Re: [sa-list] Re: Adding headers on spamassassin ignores?
Posted by "Dan Mahoney, System Admin" <da...@prime.gushi.org>.
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
---------------------------
Re: Adding headers on spamassassin ignores?
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
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.
--
char *t="\10pse\0r\0dtu\0.@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; }}}