On Sunday of May 24 2009, W B Hacker wrote:
> Sounds reasonable - but also points to a solution.
> One in which you use the 'unseen' structure differently.
> Or perhaps not at all.
Sounds heretic ;)
> GIVEN: A 'real' Exim expert can do all this without leaving Exim's own
> toolset, or needing SQL at all.
I strongly believe in that - that's why I posted the question to the list :)
> 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'.
That's very interesing idea - though tt requires rewriting 1000 line long exim
config, I'm a bit afraid of such total change. A year has passed since I
switched from postfix and I never looked back but still sometimes small bugs
in config take long minutes to be found...
> Repetitious?
> Yes. Exim won't cache SQL returns.
At least the database has the cache and with proper settings 99% queries will
be served from cache.
> 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.
> ;-)
Thrilling ;) Rewriting exim in SQL....
> 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.
Wondering why exim doesn't have generic variable system, where I could define
arbitrary variables, assign anything I want to them etc...
> HTH,
It helped in the way I looked at the processing from different angles :)
Anyway, what else I tried:
1. First attempt was to use accept router and autoreply transport (instead of
redirect). It partially worked - the mail was copied to sms address but the
body was empty.
mysql_sms:
driver = accept
no_verify
no_expn
condition = ${lookup mysql {SELECT if(sms is null or sms='','no','yes') as c
FROM user WHERE username='${quote_mysql:$local_part}' AND
domain='${quote_mysql:$domain}'}{$value}fail}
transport = sms
unseen
sms:
driver = autoreply
transport_filter = /exim/sms-filter.pl
headers_add = "X-SMS-Gateway-Filter: Yes"
reply_to = "postmaster@${domain}"
to = ${lookup mysql {SELECT sms FROM user WHERE username='${quote_mysql:
$local_part}' AND domain='${quote_mysql:$domain}'}{$value}}
As I found in docs transport_filter applies only to body of message that I can
attach to the message via return_message option - that's not what I need.
2. In the meantime I thought about pipe transport with filter reinjecting the
mail into exim, but didn't tried it yet
3. Other thing that come to my mind was rewriting autoreply trasnport - it
must not be THAT hard, right? ;)
4. But I realized that it's great opportunity to check built-in perl
subroutines (as the filter was already written in perl). So I did
driver = autoreply
text = ${perl{sms_filter}{$message_body}}
subject = ${perl{sms_filter}{$h_subject:}}
And it works with one minor inconvenience - I cannot limit size of filtered
subject + body - I know I could send size of subject as param to perl
function while filtering body but... who cares ;)
greetings
--
Marcin Gryszkalis, PGP 0x9F183FA3
jabber jid:mg@???, gg:2532994
http://the.fork.pl
