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 = "postmas...@${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:m...@fork.pl, gg:2532994 http://the.fork.pl -- ## 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/