[exim] Replacing subject header when spam scanning: new idea…

(Apologies if this has been discussed on the list recently; I'm afraid
I'm struggling to keep up to date with it at the moment)

In the past, my preference when spam scanning has been not to fiddle
with existing headers (in particular Subject). However, a circumstance
has arisen where I regrettably need to do that, using Tom's content
scanning extensions.

Now, the method suggested in the spec (using warn = Subject: whatever)
is OK, but results in two Subject headers which is a bit nasty. So I
started thinking about an improved way, and stumbled across FAQ Q0905
(http://www.exim.org/exim-html-4.50/doc/html/FAQ_9.html#TOC288), which
says:

"You can only do this in a round about way, using filter commands like
this:
headers add "New-Subject: SPAM: $h_subject:"
headers remove subject
neaders add "Subject: $h_new-subject:"
headers remove new-subject
This trick works only in system filters, where the commands are obeyed
in order, and affect the master list of headers that apply to the whole
message. You cannot do this with the headers_add and headers_remove
options on drivers."

However, using Exim 4.52, I thought I'd give the following trick a go:

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. 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?

Suitably inspired, I thought I'd also play around with doing this
conditionally according to whether the recipient wants header munging
or not, to prevent users with sane MUAs that can filter on arbitrary
headers from having to deal with nasty munged messages. In the first
instance, I had thought I'd have to do the usual messing around with
temprejecting recipients at SMTP time according to their rewriting
preferences. But with the above method which is done at routing time,
it occurred to me that as a bonus, it doesn't require any messing with
SMTP. So I tried this (apologies for poor formatting):

DATA ACL as before.
ROUTER:
  headers_remove = Subject
  headers_add = ${if and{ {eq{$h_X-Spam-Flag:}{YES}}
                         {eq{
                           ${lookup{$local_part@$domain}lsearch*
                            {TABLEDIR/spam-replace-subject}}
                            }{1}
                          } 
                         }
                         {Subject: *****SPAM***** $h_Subject:}
                         {Subject: $h_Subject:}
                  }

where TABLEDIR/spam-replace-subject contains stuff like:

foo@???:0
*:1

and 1/0 indicate whether header munging is on/off respectively.

Again, a quick test shows this working nicely. Two recipients in one
SMTP session, one which has munging set to 1, one with it set to 0.
Message that exceeds SA spam threshold. Result: two deliveries, one with
munged Subject (one header only), one without. Nice.

So, again: any obvious downsides to this approach? If not, could this
be a useful addition/note to the FAQ? (if so, I'll also put a note on
the wiki, and also do a long-needed update to my S&V scanning HOWTO).

Any input welcome.

Thanks,


Tim