On Sun, 6 Nov 2005, Tim Jackson wrote:
> IN DATA ACL (normal kind of stuff):
> warn message = X-Spam-Flag: YES
> spam = someuser
>
> IN APPROPRIATE ROUTERn:
> headers_remove = Subject
> headers_add = ${if {eq{$h_X-Spam-Flag:}{YES}}
> {Subject: *****SPAM***** $h_Subject:}
> {Subject: $h_Subject:}
> }
>
> Superficially, this appears to work.
It works because, at the moment, all the header modifications that are
specified in ACLs are saved up, and implemented later. Partly this is so
that they can be specified in ACLs such as RCPT, when the original set
of header lines has not yet been read.
> Am I missing some obvious downside to this method? Is there something
> about the processing of headers_add and headers_remove that means that
> you might somehow end up losing the Subject altogether in some
> circumstance?
There are several Wish List items, which I haven't had time to develop
further, that call for a re-think about the way header manipulations are
done in ACLs. The problem some people have is that if you "add" a new
header in an ACL, you can't "see" it at that time. But if a new
implementation changed to an "immediate action" scheme, the trick you
use above will not longer work (though the filter-style trick would now
work).
Another Wish List item calls for a way of rewriting a single header.
> ROUTER:
> headers_remove = Subject
> headers_add = ${if and{ {eq{$h_X-Spam-Flag:}{YES}}
<snip>
> So, again: any obvious downsides to this approach?
This again works because the actual action is saved up for transport
time, though the expansion happens (and is documented to happen) at
routing time. This is unlikely to change.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
