Dean Bishop wrote:
> Hey Bill,
>
> A great question. Sadly not one that I have an answer to. Half of
> this battle is trying to sift through cPanel's stock exim.conf which
> is extraordinarily convoluted (at least to me). I know that there
> are a thousand config combinations and permutations available in
> cPanel so I expect that something buried in there is the root reason
> for it not rejecting traffic using the acl.
>
> I wish I knew but I think that even if I did, it wouldn't help as I
> have to thread changes into their rats nest.
>
> My 2c in return; keep the change :)
>
> Later, dean
I can't be bothered with CPanel or Sputniks when a text-editor gives me
less backtalk.
'Conventionally' The acl code is a one-liner:
require_verify = recipient
CAVEAT: What this does is a 'router walk', asking each router in turn
that does NOT have the 'no_verify' flag set if it COULD deliver that
message IF asked. Sort of a show of hands - not a real delivery.
The caveat is that you must not have a promiscuous or 'leaky' router -
one that is willing to drop trou and take anything and everything poked
at it.
A 'blackhole' router (bad practice anyway) and SOME types of ALIAS
routers can be just that sort of 'leak', and you may WANT it to
participate in verification. Catch 22.
If/as/when that is problematic, I use an SQL call instead and don't look
at the router chain at all.
But .. one THEN has to make sure that EVERYONE, even aliases and
'postmaster@' exist in the DB.
- Downside is the overhead of an SQL engine.
- Upside is editing of ALL users in one place, and with separate privs
from Exim. IOW - can be compartmentalized with the DB's rights control
toolset and handed-off to one or more outsiders who are restricted to
managing only ther own sub-clan, and cannot touch Exim itself.
===
Otherwise...
Pragmatically, I tend to use negated tests, as I am more accustomed to
'stacking' the conditionals, so my code is of the form:
deny
!verify = recipient
...or IF one has not ALREADY done an 'accept' to exempt your own
user-group, who are not sending to ONLY local destinations, then:
===
deny
!authenticated = *
!verify = recipient
===
Functional flow is like this:
Deny
but not if the caller is authenticated
if you got this far, and the recipient cannot be verified
===
There's the change back for the 2cents change from the 2 ... nevermind..
;-)
Bill
--
韓家標
