Marcin Gryszkalis wrote:
> On Friday of May 22 2009, W B Hacker wrote:
>>> mysql_sms:
>>> driver = redirect
>>> data = ${lookup mysql {SELECT sms FROM user WHERE
>>> username='${quote_mysql:$local_part}'
>>> AND domain='${quote_mysql:$domain}'}{$value}}
>>> headers_add = X-SMS-Gateway-Filter: Yes
>>> address_data = SMS
>>> unseen
>
>> If it is mere presence or absence of the header, not the string it carries,
>> try 'def' instead of 'eq' as in;
>>
>> quarantine:
>> driver = accept
>> transport = quarantine_delivery
>> condition = "${if def:header_X-Junk:{1}{0}}"
>
> good point, though using headers doesn't work in this case - docs say:
>
> (in headers_add)
>
> "Warning 2: If the unseen option is set on the router, all header additions
> are deleted when the address is passed on to subsequent routers."
>
> (in unseen)
> "Warning: Header lines added to the address (or specified for removal) by this
> router or by previous routers affect the “unseen” copy of the message only.
> The clone that continues to be processed by further routers starts with no
> added headers [...]
> Unlike the handling of header modifications, any data that was set by the
> address_data option in the current or previous routers is passed on to
> subsequent routers."
Have to admit that - while using *very* long sets of 'unseen' router structures,
I've not relied on headers in that manner.
The acl_m is more suited to my needs.
But let's see whether you cold use that...
>
>
> I think it should work like this
>
> 0. message[destination] = x@domain1
> 1. message[header_X-SMS:] is not defined
> 2. we get to the mysql_sms router (this is redirect router)
> 3. data = ... returns y@domain2 - this causes creation of the clone:
> message2[destination] = x@domain1
> and sets up new destination for oryginal message
> message[destination] = y@domain2
> 4. headers_add applies to the clone only:
> message2[header_X-SMS:] = Yes
> 5. message (oryginal) is reinjected and starts checking routers again (because
> the router is redirect) but it's not possible to find out what happened
> before reinjection because added headers are wiped out
> 6. message2 (clone) is passed to subsequent routers (because of unseen), it
> doesn't matter if the header is set because it's not the copy we want to
> filter
>
> Is this description right?
>
>
Sounds reasonable - but also points to a solution.
One in which you use the 'unseen' structure differently.
Or perhaps not at all.
>> You may be more predictably served with use of acl_m variables.
>> Simply set up the selective steering parameters in acl's before entering
>> the router/transport sets.
>
> But in acl I wouldn't know if I want to filter a message or not. The only
> place I know what's going on is the redirect+unseen router...
>
> greetings
GIVEN: A 'real' Exim expert can do all this without leaving Exim's own toolset,
or needing SQL at all.
But for those of us who understand SQL better than Exim, a less efficient route
can deliver the same result - sooner.
If you are using SQL at all...as you are ... consider using SQL - AND nothing
else - for all of the decision-making and 'steering'.
Don't onpass 'guidance' in headers - let them be purely 'the product'.
Make the needed SQL call (again..) in *each* router, and their transports as
well, if need be ...and you won't need address_data at all.
Repetitious?
Yes. Exim won't cache SQL returns.
Less efficient of machine resources?
*Definitely so!*
More efficient of 'wetware' resources - eg testing, implementation, debug and
maintenance effort? Your time, IOW.
Ah .. that TOO!
What with anti-looping, multi-pass and 'unseen' rules, one has to get clever to
even 'see', let alone predict what might be in an address_data variable at each
stage of the process. Look at what you have just been through these past few days.
;-)
A 'SELECT', OTOH, is obedient, transparent, predictable, and easily vetted
independently of whatever is going to be using it.
YMMV, but our routers AND transports each make their OWN SQL calls. Sometimes
the very same one just made a few lines earlier. Or nearly so. Or not at all the
same. Whichever suits *their* need.
No need to deal with address_data at all, and headers, where used, are simply to
insure the message (archived) carries end-user-visible debug clues if the call
for analysis comes 2 months after the event and there are no other traces save
for the logs.
HTH,
Bill
