[exim] use of add_header - not an *exact* drop-in replacemen…

Top Page
Delete this message
Reply to this message
Author: Eli
Date:  
To: exim-users
Subject: [exim] use of add_header - not an *exact* drop-in replacement for message?
I just upgraded to 4.63 the other day, and figured since the "official"
configure file had switched to using add_header (and the bug(s) for
add_header were fixed), that I'd switch as well.

So, I went through and replaced a dozen or so "messages = ..." with
"add_header = ...". Most of my ACL lines were something like this:

  warn add_header      = X-Spam-Scan: YES
       spam            = nobody:true
       set acl_m1      = 1


and...

  warn add_header      = Date: $tod_full
       authenticated   = *
       condition       = ${if !def:h_Date: {yes}{no}}


once I was done. I figured everything was good - started up the new Exim
build and checked to make sure no errors popped up (none did) and that was
it. I check my email this morning and had a ton of spam, which I thought
odd - I checked the headers and saw something bizzare... *ALL* possible
headers were being added to the message?! That just wasn't supposed to be
possible!

Turns out I had 2 problems, 1) spamd had stopped working and needed to be
restarted, and 2) the "add_header" control works like "logwrite" - it runs
*as soon as* it's hit in the config file, EVEN if the condition for that
entire part ultimately fails.

Anyhow, I've gone in and rewritten all of my ACLs to put "add_header" after
any variable conditions - it reads easier this way as well, though I just
figured I'd let anyone else on the list be aware of this difference in case
they were going to switch as well (and have ACLs similarly structured to
mine). Perhaps a little note in the documentation may help as well, since
it only says that the header will be added if the message is accepted,
thought it would make sense to *not* add the header if a dependant condition
failed - right? :)

Eli.