Yeah. The OP presumably had his "permit_sasl_authenticated" both in sender
restrictions and relay restrictions. Thats why I gave a example of sender
restrictions where I also said that every instance of
permit_sasl_authenticated need to be replaced (For example, if one is in
recipient restrictions or relay restrictions).

With "policy stack", I didn't mean that the different stages affect each
other.
What I meant is that a policy containing "check_[something]_access" pointing
to something (a table, binary program, whatsoever) that itself return a
policy as reply, will cause the new policy to be "inserted" at the
check_[something]_access location during policy evulation.

This effectively means there is a separate "stack" for each mumble, where
parts of policy may be replaced.

(As different check_[something]_access and different other policies may be
mixed)

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to