Auteur: W B Hacker Date: À: exim users Sujet: Re: [exim] Problem with 'freeze' command in system filter.
Ben Allen wrote: > On Friday 26 November 2010 19:24:16 W B Hacker wrote:
>> Ben,
>>
>> You might wish to submit that proposed patch via the exim-dev list where
>> developers may see it sooner...
>>
>> Meanwhile - have you considered using 'acl_not_smtp' instead?
>>
>> AFAICS, that would give you a richer set of well-proven tools.
>>
>> 'Rich' enough that I've never needed to use a system filter at all.
>>
>> JM2CW
>>
>> Bill
>>
>
> Hi Bill,
> Cheers for the reply. I'll post the patch on exim-dev.
>
> I'm probably being slow, but I don't see how acl_not_smtp can help.
'Functionally' the acl_not_smtp tool is akin to a DATA phase (only) acl, in that:
There has been no 'connect' or any of the subsequent phases of an smtp
handskake/negotiation. The whole shebang has just been dropped in with headers
and content already present.
So you can't filter on, for example rDNS or HELO - nor would want to do. The
sucker came off your own box via local invocation (leading to) the Exim binary.
Nor would it help IF the message+headers were 'stuffed' directly into the queue,
bypassing all of the 'incoming' Exim run, acl_not_smtp included.
Router/transports are all you have left in that case.
Likewise, 'rejection' of traffic originating off your own box and its daemons or
apps is generally pointless. You'd be trading queue congestion for log
congestion. And perhaps confusion.
So no - a panacea it is not.
OTHERWISE, IF the info you need to make a branching decison can be found in
headers and such, invoing UID, even body or attachment (type), acl_not_smtp
SHOULD be able to carry the needful acl clauses to detect and flag for later
routing.
Appropriately coded it might be useful to control the rate or delay or such
traffic as you are finding problematic.
You WILL still need bespoke routers, but perhaps fewer of them, and with more
pricise control over them.
The advantage acl's have over router/transports (alone) - and 'perhaps' also
system filters, are:
- an acl can have 'many' conditionals, simple and/or complex. A router only
ONE, hence either less flexible 'each', and/or needing more complex logic within
a given conditional, ELSE a longer 'chain' of routers, potentially some of them
'unseen.
- this particular acl set is traversed ONLY when the source IS 'not smtp'.
Thereby adding low/no load for all other externally-sourced traffic.
A router chain, and 'probably' any system filter(s), OTOH is/are potentially
traversed to a high percentage of reach with EVERY message.
- further, an acl can not only read the available Exim variables (not all of
which will be present), but unlike a router, can ALSO write or alter them [1].
Which opens the door to more flexible handling - especially of successive passes.
> As I
> understand it, this is only 'called' when a message is received over a non
> smtp source (e.g. using 'exim -bm' or a local bounce message following
> delivery failure). What I want is something that runs every time a delivery is
> attempted.
To the extent you take the same path to your end goal, yes. To the extent you
can get 'ahead' of that with earlier flagging, if not branching, maybe there is
another path. And it might need fewer resources and create lower hassle.
> This means either a system filter or a router/transport
> combination.(?)
As above, yes.
> A quick test with acl_non_smtp seems to indicate it doesn't
> run at all with an externally source message, neither during receipt, nor
> during subsequent queue routings and delivery attempts.
>
Which is what you wanted, no?
> Thinking about it though, I can probably do exactly what I want with a
> redirect router instead of a system filter. Although I suppose that it still
> runs as a filter, so might have the same problem as before.
>
Similar, maybe.
Identical. Probably not.
Your need, your logic to solve it, so not yet all that predictable fro the cheap
seats.
> I'll see what happens if I run it as a router, but if I've missed something
> obvious please let me know.
>
>
Presuming you are already au fait with repouter sequence sensitivity, 'unseen',
'errors_to' and 'no_verify', and perhaps 'data' in routers, you should be OK...
See also how and when 'headers_add or headers_remove ' are actually actioned,
eg: useful for successivec injection, less so between routers during the same
traversal.
if not, search the archives or the manual...
> Cheers
>
> Ben
>
HTH,
Bill
[1] CAVEAT: I use, but do not generally recomend SQL. With which one CAN 'write
or alter' information in one router that CAN be made available to the next
router in the same traversal run. Or transports.
But that flexibility comes at the price of installing, configuring, and
maintaining forever-after one more system that can break, and a great deal more
admin work. Not to mention CPU cycles et al.
