On 30 Oct 2006, at 20:23, W B Hacker wrote: > Online4You wrote: >> Hi, >> >> We're trying to setup some extra routers in our Debian exim4 >> config to check >> for per-mailbox anti-spam settings. Some of these routers just >> check the >> mySQL database for the customer setting in the "condition" and >> then add a >> mail header so it is marked for later on. Then after several >> checks, the >> mail is checked for these marks and should be acted on accordingly.
You cant do this in the data acl ? >> >> Now I've just found out that adding and removing headers isn't the >> way to >> exchange information between routers because those are not >> effective until a >> transport is reached. Your router is NOT calling a transport ? Can you do this by calling an external program (pipe transport?) >> >> How can I pass on information between routers so the next router >> can check >> for something set in the previous router? Can you give an example. The purpose of a router is to decide if a transport should handle a message or not. They don't realy do any processing - do they? so where would you get data from to set the variable ? >> >> I'm looking for something like the $acl_m0 - $acl_m9 facility in >> the ACL but >> then for use in routers. >> >> Thanks for helping out on this! >> >> Martijn >> >> > > You are in luck. Maybe. All the acl_m(x) variable 'final state', > i.e. on > leaving acl_smtp_data, are stored in the queue with the message > headers & body. > > Even though any given 'label' for a variable, 'acl_m4', for > example, will have > been re-used, perhaps hundreds of times, by other child processes > or later > arrivals, those that were in effect at the time acl_smtp_data > completed can > still be called on by a router or transport and by the same label > they had when > stored, e.g. acl_m4, (for that message) etc. > > That's the good news, and if all you need is per-message, not per- > recipient, > then you are home free. Read no further. > > > The 'maybe' is the case where you DO want per-recipient information. > > Just as headers added in acl_smtp_data are per-message, not per- > recipient, so > too are the acl_m(x) values. TANSTAAFL. > > Headers added in router/transport code OTOH, are per-delivery - i.e > per > recipient for on-box delivery, per connection for remote_smtp, so > don't overlook > their value. > > There is a kludge with aclM(x) variables, wherein it is easy to > *store* > per-recipient information into an acl_m variable, because you can > build a string > of arbitrary format by successive concatenation during the > acl_smtp_rcpt phase. > > Ex: > > acl_m4 = acl_m4 uid:[EMAIL PROTECTED] prefs=<something> : > > will add new to what was in already acl_m4 from the prevous pass, > producing: > > > [EMAIL PROTECTED] prefs=<something1> : [EMAIL PROTECTED] > prefs=<something2> > > Getting specific information back *out* of the structure you have > built, on the > other hand, may requires either some form of 'calculated' lookup, > BFBI, or a > for-next loop or 'do while'. > > The first is provided for by certain of the lookup tools and by > 'extract'. > How you tell a router where to look, when, why, and whether to do > it more than > once, is harder. > > The BFBI way is a massive chain of successive routers, each looking > for a field > one step further to the right than its predecessor. Works fine for > small batches. > > ;-) > > OR - a more clever equivalent where router A takes a look, passes > to router B, > B takes a step to the right and looks, B hands back to A set to > look one step > further right, until 'all gone' and off to the races with the results. > > Complex rules rules apply to prevent loops. Discarding prior router > data or > headers is one of these. > > Finally, calling for some sort of *external* step-by-step iterative > routine that > walks the records *within* a process, takes what it needs, passes on. > > Other than clever routing pass and 'goto' directives, Exim does not > provide a > lot of 'for-next' looping tools where we can easily tap them, so a > call to > external tools might be easiest. > > OTOH, once you are into the router/transports, the submitting host > has gone > away, and there is more time to do these things. > > But rest assured - you *can* store the information with Exim's > built-ins. > > Now ... If someone will get the lights, there will probably be an > SQLLite > tutorial shortly.... > > HTH, > > Bill > > > > > -- > ## List details at http://www.exim.org/mailman/listinfo/exim-users > ## Exim details at http://www.exim.org/ > ## Please use the Wiki with this list - http://www.exim.org/eximwiki/ > -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
