Eli wrote:
> 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.
>
>
Thank you Eli!
Just saved me a ton of grief.... (1700 line configure file... *many* legacy
'message = ..' used where add_header could/should be..
;-)
Bill
