Re: [sa-list] Re: Adding headers on spamassassin ignores?

["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: [sa-list] Re: Adding headers on spamassassin ignores?

[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; }}}