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:$user@$domain prefs=<something> :
>
> will add new to what was in already acl_m4 from the prevous pass,
> producing:
>
>
> uid=$user1@$domain prefs=<something1> : uid=$user2@$domain
> 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/
>
