[EMAIL PROTECTED] 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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
