Stephen Gran wrote:
> On Thu, Oct 19, 2006 at 07:13:06AM +0800, W B Hacker said:
>
>>Folks,
>>
>>Aside from externals, pipes, etc...
>>
>>Does anyone have a(ny) kludge(s) for routers to:
>>
>>A) Support more than one 'condition', or simulate such, per router?
>
>
> Conditions can be and'ed and or'ed, as in any programming language. Am
> I not getting what you want to do?
ACK. So doing.
Would prefer to build a 'case of...' structure with less hassle.
>
>
>>B) Emulate a set of variables we could use but do not have, i.e. 'rtr_r(x)',
>>dlvr_d(x) as we have for acl_c(x) and acl_m(x)?
>
>
> Stuff something in $data, and extract it later?
>
Hmm... substring extraction, record-separators... ?
I still have Richard Pick's book around somewhere..
>
>>C) Define or derive, then also later be able to select between/among multiple
>>'data' calls in a router or transport?
>
>
> Not sure what you mean here.
$data1, $data2, $data3 .... $data(n(
>
>
>>D) Use a router that does NOT call any form of transport, merely makes a test or
>>lookup, and passes results, flags, variables on to subsequent routers?
>
>
> Use driver=redirect and do something with data, again.
>
Of course. Thanks - that helps!
>
>>E) Defeat/work around the stripping of headers_add / headers-remove when going
>>through an 'unseen'?
>
>
> I'm not sure what you are trying to do here. Why are you munging
> headers before you want to examine the unmunged message?
>
The message, akin to a 'Xerox master' is already fully 'examined' and in storage
with all information resulting from the many examations that any of one or many
recipients would need to be able to determine if and how to mark
it up, modify it, or route it they way that *each said recipient* would wish.
Their preferences are in a DB.
Session and message information information is in acl_m variables, not headers
for use by the routers, is successively compared against each individual
recipient's wishes to determine modifications and routing.
NB: We have been doing this with headers added in acl's that are then stripped
at delivery-time, but conditionals and nesting are *ugly*.
Ex: a *message* itself scores 4.5 spam points, stored in acl_m9 as int 45.
Recipient 'A' wants no filtering or added headers, gets her copy 'bare'.
Recipient 'B' wants anything over 2.0 to have an X-Spam-bars header, and
anything over 4.0 to have '*SPAM* munged into a 'prefixed' Subject:' header,
but all of it dropped into 'Inbox'.
Recipient 'C' wants no headers or Subject: munging, but wants anything over 3.8
points to be delvered to a 'Suspect' folder, and anything over 7.0 delivered to
a 'Toilet' folder, and all traffic archived.
Not to mention the flags and scores being carried for rDNS fail, MIME errors,
etc. - which is where the complexity start to get uglier yet.
- did I mention 'corporate' and 'virtual hosting'?
;-)
Previous configure has router/transport sets taking up 435 lines of code, vs
1042 for acl's.
Main (with notes) Lines 0 - 252
Authenticators' Lines 253 - 310
acl's Lines 311 - 1352
routers Lines 1353 - 1545
transports Lines 1546 - 1788
retry Lines 1789 - 1811
- no filters or rewrites ...
This shifts the other way for the revised model, as more complexity has moved
from acl's into routers to provide finer-granularity in per-user/recipient
settings. Still full of debug code, but looking to find router decision
structures that look more like a 'case' construct.
>
>>F) Used a transort to not only deliver headers-only, but to create a dirtree or
>>zero-length file only (I have done that, but in a rather ugly manner..)
>
>
> This sounds like a job for an external program to me.
>
">>Aside from externals, pipes, etc..." - which, of coure are essentially
unlimited, but cn be avoided, and have been so far..
>
>> - or interest in a 'fork' that removes current router/transport sets in favor
>>of an acl-like 'case of..' structure with the same syntax, methodology, and
>>functionality as now used in acl's? (granted the flow is not the same..)
>>
>>E.G. where 'delivery time' vs smpt-time:
>
>
> You can already specify different routers for delivery and smtp-time
> handling with the no_verify and verify_only directives, as well as jumps
> between routers using pass_router and redirect_router - you could
> conceivably have a no_verify router that jumps over all the verification
> routers to the real set of routers below a no_more staement, allowing
> completely different routing at delivery time than at smtp (although why
> you would want the duplication of effrot I can't imagine).
>
Because - as-is it is the last bastion of spaghetti-code left in Exim, and I
*do* mean spaghetti-code. Just as you now described.
;-)
acl's, by comparison *ordinarily* just flow sequentially (as do 'simple'
routers, but only the simple ones...)
I could even wish for antique HP MPE-3000 structured BASIC:
do
if.... then
do...
...
...
doend
elseif ... then
do
...
...
doend
endif
doend
(relying overly much on 1974-84 memories of 50,000+ lines coded of such...)
> Is Perkel rubbing off?
LOL! 'au contraire'
There is nothing new or 'special' in *doing* per-user delivery/format prefs with
Exim. Until recently per-domain (dead easy, as messages arrive 'packaged' that
way) were usually good enough.
But we now need 'per-role' or 'per-department' differentiation such that
'public-facing' (hey - caught that missing 'ell' this time...) sales/marketing
staff have lower risk of false-positive loss than is the case for HQ-branch
intra-office traffic, where few 'ousiders' are in the flow.
So - I'm essentially looking to de-uglify my code.
Chuck Moore or Ray Duncan's influence resurfacing, perhaps, not Marc's.
IOW - it isn't functionality that is missing.
It is 'visible' self-documenting tools - as in acl's - to contruct an easily
human-readable orthogonal flow structure I can pass on to someone else w/o
eye-logic confusion.
Note how much easier it is for us to sort out what someone else's acl does from
a mere fragment, than to sort routers without the entire chain in front of us.
Best example of what is 'wished for' is probably an ADA or Forth case structure...
case of
condition a action a
case of
...
...
endcase
condition b action b
condition c action c
endcase
endcases
Thanks for the hints :-) .. and confirmations :-(
Bill
