[Pkg-exim4-users] spamassassin headers

[Andreas Metzler]

On 2006-04-21 Chris <nws at cevnet.mine.nu> wrote:
> 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".

Strange, seems to work for me.
[...]
>> 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?
[...]

I do not know. But I guess because it fits better into exim. - Acls
only decide what to accept and how to tag it. There'll also be
implementation issues.

> 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.
[...]

The documentation could spell out louder that
any alterations spamassassin or that a virus-scanner made to the
message are discarded, as it acts only on a temporary copy. It
currently says:

| All the content-scanning facilites work on a MBOX copy of the message
| that is temporarily created in a file called:
| <spool_directory>/scan/<message_id>/<message_id>.eml
| 
| The .eml extension is a friendly hint to virus scanners that they can
| expect an MBOX-like structure inside that file. The file is created
| when the first content scanning facility is called. Subsequent calls
| to content scanning conditions open the same file again. The directory
| is recursively removed when the acl_smtp_data ACL has finished
| running, unless
| 
| control = no_mbox_unspool
| 
| has been encountered. 
cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde