[Pkg-exim4-users] spamassassin headers

[Chris]

On Thu, 2006-04-20 at 19:36 +0200, Andreas Metzler wrote: 
> On 2006-04-20 Chris <nws at cevnet.mine.nu> wrote:

> You are claiming that
> > ACL: 
> > 	warn
> > 	spam = Debian-exim
> > 	message =  X-Spam_score: $spam_score\n\
> >         X-Spam_score_int: $spam_score_int\n\
> >         X-Spam_bar: $spam_bar\n\
> >         X-Spam-Flag: YES\n\
> >         X-Spam_report: $spam_report
> 
> results in X-ACL-Warn: X-Spam-Flag: YES?
Close, I actually used:

warn 
spam = Debian-exim
 message = X-Spam-Flag: YES\n\
 X-Spam_score: $spam_score\n\
 x-Spam_score_int: $spam_score_int\n\
 X-Spam_bar: $spam_bar\n\
 X-Spam_report: $spam_report

but the result indeed was "X-ACL-Warn: X-Spam-Flag: YES".

> or are you using
> 
> > ACL: 
> > 	warn
> > 	spam = Debian-exim
> > 	message =  X-Spam_score: $spam_score\n\
> >         X-Spam_score_int: $spam_score_int\n\
> >         X-Spam_bar: $spam_bar\n\
> >         X-Spam_report: $spam_report
> >         X-Spam-Flag: YES\n\
> 
> which should result in a syntax error.
I checked: it does. No I didn't use that.


>Michael Sprague <mfs at saneinc.net>
> I'm not sure if you can add multiple headers that way.

It is (commented) in debian's exim4-config_4.61-1 
/etc/exim4/conf.d/acl/40_exim4-config_check_data.
I merely uncommented it. I thought I could add to that, but now I
understand this is the only info saved from SA and thus the only X-Spam
headers available for this acl.

I set the X-Spam-Flag now by adding this acl:

warn                                                                                                
  spam = Debian-exim/defer_ok                                                                   
  message = X-Spam-Flag: YES                                                                    

It works fine.

> > Negatives get no X-Spam headers at all by default, which is confusing
> > since it took a trip to /var/log/syslog (or /var/log/mail.info) to find
> > out that spamd actually processed the message.
> 
> That is how you configured it. You told exim to check whether the
> message was spam (spam = Debian-exim) and *if* this was true to add
> some headers.
> It is documented. ;-) 

:-)

I understand the *if* but I counted on SA's config for adding the
headers, not on exim discarding them in order for me to have to add them
manually.

As my understanding grows I can see more logic into the way exim is
handling it, BUT: coming from a setup with routers-transport I kinda
expected more or less the same behaviour.

Changing over from exim-light to heavy caused me to loose control over
SpamAssassin, which does a perfectly fine job adding headers to both
pos' and negs, and I can also fine-tune those in SA's config files. Why
change that and make me loose info about the scan, loose control over
SA's way of spam-reporting in headers? (on which clients base
filtering), and even worse:

>Michael Sprague <mfs at saneinc.net>
>Note that I have the report as a header and I think you want it as an
>attachment in the body?  If so, I'm not sure how to do that. :(

No, I want the report in the body and the spam attached, as I declare
in /etc/spamassassin/local.cf:
# Save spam messages as a message/rfc822 MIME attachment instead 
# of modifying the original message (0: off, 2: use text/plain
# instead)                              
report_safe 1 

This is not at all what I expected from exim4-daemon-heavy. Should I go
back to *-light and do the content scanning with router-transport? or
add a router-transport combo to get proper spam reporting?

The way I see it is that the trade off for smtp-time scanning right now
is a buggy way of handling spam. I can't believe this is what it should
do. I understand from the reactions that my config is correct and that
this behaviour is indeed not a bug :-( 

Maybe it could be added to the README.documentation that SA's
body/headers are discarded and that *if* you want headers and a
"X-SPAM-flag: YES" for spam uncommenting and adding these lines is
necessary. Leaving the fact that you have no longer a choice in the way
spam is reported.

What is the benefit of the above to SA's original treatment?

I think this could be improved. I also think there should be a
meta-package for exim/clamav/spamassassin, so that after Debconf there
is a working setup. 

Input appreciated!

Thanks,
-- 
Chris <nws at cevnet.mine.nu>