Marcin Gryszkalis wrote:
> 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 ;)
With my surname you expected conventional?
>
>> 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...
>
*TILT*
- I have them over three thousand lines long - but that is NOT what I mean
here. Not at all.
I meant 'just for the routers and transports that need to do weird stuff'
That adds perhaps 4 lines to each of perhaps 5 or 6 routers and their matching
transports so they can pull directly from the DB and not rely on a semi-local,
sei-global, neither, both, sometimes, variable.
One transport ordinarily may be called by more than one router.
Conventionally, one router is expected to call one, and only one, transport -
but doesn't mean it cannot 'choose' *which* of several.
>
>> 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....
>
No no .. one could DO that, but it is not a good direction - not for what Exim
is best at.
Look at DB Mail or PowerMail (the mTa, not the mUa).
>> 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...
>
It does. In acl_c and acl_m. You can grant yourself 'many' more than the
default in the build configure.
Not yet in router/transports, though. I've suggested acl_r for those, but so far
no takers.
Not all that hard to add. Exim has very clean and well documented source code.
JFWIW, it is possible to not even use router/transports. Or the queue. But I
digress..
>> 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}}
>
Yo might want to employ a 'LIMIT 1' in those...
>
> 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
You can limit size with an acl in acl_smtp_data.
You can even map the message to more terse text.
Look, for example, at all the things SpamAssassin does (or CAN do) during the
DATA phase while the session is still in-process.
But ignoreth ye not the workload perl can add....
I'd be tempted to off-load it to a customized Ecartis instance instead.
Bill
