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)
smime.p7s
Description: S/MIME Cryptographic Signature