Author: W B Hacker Date: To: exim users Subject: Re: [exim] Is there a way to add/remove headers in user filters?
Sandro Tosi wrote: > Hi,
*trimmed* - portion previously responded to...
> indeed, but why disable headers changes in user filters?
>
As said, I've never needed system OR user filters, so have ignored that portion
of the docs..
that said .. a 'SWAG' ..
To the extent the message is already in the queue, in Exim's usual two-part
storage (headers, acl_m's and other stuff in one file, body & attachments in
another), a 'system' filter would have been able to action header changes for
'all hands', and before a queue-runner onpasses the result to router/transport
sets to effect final delivery. Headers on all copies will be alike, and that is
expected and OK.
A 'user' filter, OTOH, cannot safely alter the one-and-only copy in queue, w/o
(potentially) affecting what will be handed-off to OTHER users.
Router/transports, OTOH, CAN handle per-user header mods, because local
deliveries, moving a *copy* of the message from queue to mailstore, are done one
recipient at a time.
SO 'easy' out is to use a system filter AND limit arrivals to one recipient at a
time - truning it into a de facto 'user' filter. But if one is gong to bend or
break the '100 minimum' RFC, one might as well not bother with a filter, and
JFDI in acl's.
There's another workaround that can avoid that friction w/o limiting arrivals at
all:
At acl_smtp_recpt, *concatenate* the user prefs into one single acl_m variable,
adding each USERID and pref set as each RCPT_TO is traversed.
In your router/transport sets (ELSE a user filter), for each $local_part being
delivered, parse that acl_m picking out the matching user's prefs. And action
accordingly.
NB: IF you are going to run an SQL animal *anyway* it is even easier to
just pull the prefs [again | only] from the DB when traversing router/transport
sets. Neither a system, nor user filter nor even an acl_m needed.
YMMV, but once an SQL engine has been interfaced to Exim, one might as well use it.
