On Sat, Aug 13, 2022 at 03:42:41PM +1200, Peter wrote:
> /etc/postfix/sender-recip:
>
> # Joe is only allowed to send to Bob
> j...@example.com check_recipient_access
> inline:{b...@example.com=permit},reject
>
> # Jane is not allowed to send to Joe or Bob but can send to anyone else
> j...@example.com check_recipient_access inline:{j...@example.com=reject,
> b...@example.com=reject},permit
>
> # Jeff is allowed to send to anyone who's address begins with a "j" (far
> # fetched, I know but it illustrates the example)
> j...@example.com check_recipient_access pcre:{{/^j/ permit}},reject
>
> Note: None of these examples are tested and I may have gotten the syntax
> wrong, but the premise is that the result of an access(5) lookup can be
> additional restrictions, combine this with the use of inline tables (or
> pcre/regexp tables using the documented inline syntax) and you can do
> quite a bit.
There is no such syntax, as you'd discover if you tried it. Access
tables are pre-registered while parsing *restriction classes*, both
built-in (smtpd_mumble_restrictions) and user-defined. On the RHS of
tables only already defined restriction classes and built-in verbs are
available. It is not possible to define inline or any other tables
in the RHS value of an access(5) lookup.
On a small-enough scale, it is possible to do some table lookup chaining
via the methods show in RESTRICTION_CLASS_README.
--
Viktor.
