Martijn Grendelman wrote:
> So, still believing my configuration isn't all that weird ;-) my
> question remains: how can $spam_score_int be set during sender
> verification from the rcpt ACL?
Ok, now I get it.
There's a better way to do it without collateral spam described in a
guide somewhere, but what you have is working for you so .. yeah.
Anyway, what's happening ..
spam_score_int is a global variable declared in globals.c, initially as
NULL. The only time it is changed off that value is when the spam ACL is
called resulting in the code in spam.c being called. There, only after
spamassassin has returned with a successfully matched header - either
good or bad - it is pointed to a static buffer (uschar
spam_score_int_buffer[16];) declared at the top of spam.c. This variable
.... seems to persist for the entire connection? Maybe? I can't see
where it would be wiped - both where it's pointed to and the variable
itself are globally scoped.
It's not allocated from either memory store but will get wiped when the
receive process terminates.
Assuming I'm correct (ha!), if an email comes in and is spam scanned and
then on the same connection another email comes in, the following email
will inherit the previous emails spam scores. If you always use the same
user for spam scanning, it will not even attempt to scan the next or
subsequent messages.
Bug? Or feature! :) If one connection is sending that much spam, you
can be pretty sure that it's all spam.
Anyone else feel like verifying my evil conclusions?
--
The Exim Manual
http://www.exim.org/docs.html
http://www.exim.org/exim-html-current/doc/html/spec_html/index.html
