Re: [exim] Archiving Problems

Page principale
Supprimer ce message
Répondre à ce message
Auteur: W B Hacker
Date:  
À: exim users
Sujet: Re: [exim] Archiving Problems
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
--
韓家標