Re: [exim] Is there a way to add/remove headers in user filt…

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.

Bill