Re: [exim] Ha: Re: How many times does router run for multip…

vitas1@??? wrote:
> Bill, thanks for your comprehensive answer. Here is a simplified version
> of what I want to do:
>
> If message contains word "cat" AND user1, user2 are listed in rcpt to
> command
> THEN message should be delivered ONLY to them (all other possible
> recipients should be dropped).
>
> If it also contains word "dog" AND user3 is listed in rcpt to command THEN
> message should be delivered only to user1, user2, user3, etc.
>
> So I try to build a dynamic whitelist of recipients mostly based on the
> contents of a message. Whitelist is stored in acl_m variable (BTW is it a
> bad idea?).
>
> I don't want to generate backscatters, so non-whitelsited recipients
> should be just silently dropped.
>
> As I know this could be achieved only at router stage - but I can't
> understand how it works with multiple recipients....
>

> Regards,
>
> Vitas,
>
>

In effect, a separate router walk is run for *each* local delivery until
the recipent list (stored in the queue) is 'used up'. At that point the
queue's equivalent of a 'xerox master' message copy is destroyed, and so
are the acl_m's and such (stored separately, BTW).

'Decison' making can be, and often should be, mostly done in
acl_smtp_rcpt and acl_smtp_data, but still needs custom router/transports.

NB: Whether acl_m or X-Headers, you'll need a means to 'trigger'
different router/transports on different criteria, either within a
numerical encoding in an acl_m (odd/even, GT/LT, AND/OR, modula
remainder, int value of a real .. etc. Math is generally cheaper for a
CPU than string handling.)

... or on string/substring parsing for either acl_m or X-headers,

... OR by use of multiple acl_m or X-headers.

Router sequence will be important, and 'unseen' may be of use.

Examples that can be adapted abound in list archives as wel las the docs.

CAVEATS:

1) You cannot write to or alter an acl_m in router/transports, only read it.

2) You *can* add or remove and replace headers, BUT there are
significant limits on this also. Basically, you are 'marking' them for
action that will take place once, and at a later stage, hence not always
useful for sensing changes *between* stages.

3) There is a very limited set of variables available within the
router/tranport process. These too, have restrictions on when and how
they can be altered, what they do or do not preserve, and at what point
changes may be read back by a subsequent step. Somewhere in 'wishlist'
are 'acl_r' variables to make this easier.


W/R '...silently dropped':

Keeping in mind the 'moral' and pragmatic, as well as RFC and BCP
imperative that one *actually deliver* (somewhere) whatever one sends a
'250 OK' acceptance of, it makes life easier if you use ONLY IMAP (no
POP), as we have done now for many years.

This because instead of 'blackhole' routing, you can easily have
router/transport sets that create special 'folders' (dirtrees) into
which Exim may segregate all manner of things - good, bad, or merely
specialized (per project, per client, per subject, etc.).

It is then up to the recipient in MUA config as to what they do with
those folders. Including never subscribing them.


'Page Two' - don't forget the MUA is more powerful than the MTA:

The more complex the filter conditions, the better off one is using
per-user dedicated workstation CPU, memory, and storage to apply them in
the MUA instead of using the MTA's shared server resources.

The other side of that coin is that the MTA-resident filters will be be
more consistent across all users. Even if you personally config the
*initial* MUA installs, folks will play. Or travel and borrow other
machines.

As to pros and cons of *how* you onpass signals for what is to be done
to router/transport sets:

An acl_m read is clean as it self-destructs after last use and can be
more efficient than an X-header string parse. Unless, of course the
acl_m is itelf used for a lengthy string instead of a boolean or int flag.

But an acl_m leaves 'tracks' only in the log, and only then if the
logging is turned-up to record it.

Using an X-header, OTOH, has the advantage of leaving potentially useful
'evidence' for debugging days, weeks, or months later.

CAVEAT: If/as/when one selectively strips no-longer needed X-headers as
part of the delivery process, 'Catch 22' - we may have lost that debug
trail.

One solution is 'unseen' routers with transports that do NOT strip
headers in the 'archive' copies, but DO strip (many of) them in the
other delivery transports.

Balance all that to suit *your* needs, but I wouldn't 'blackhole' in the
first few months of operation. Sweat the 'gotcha's' out first.

Bill