On 13/08/22 16:13, Viktor Dukhovni wrote:
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.
::facepalm:: okay, I actually thought you could, and further seem to
recall having done it before. That said, I went ahead and tested it and
indeed ended up getting this:
Aug 13 08:23:20 angels postfix/submissions/smtpd[2345880]: warning:
access table hash:/etc/postfix/sender_checks has entry with lookup
table: check_recipient_access inline:{te...@pajamian.dhs.org=permit},reject
Aug 13 08:23:20 angels postfix/submissions/smtpd[2345880]: warning: do
not specify lookup tables inside SMTPD access maps
Aug 13 08:23:20 angels postfix/submissions/smtpd[2345880]: warning:
define a restriction class and specify its name instead.
Aug 13 08:23:20 angels postfix/submissions/smtpd[2345880]: NOQUEUE:
reject: RCPT from unknown[2406:e003:c18:4601:6784:712f:7eb4:8313]: 451
4.3.5 Server configuration error; from=<te...@pajamian.dhs.org> to=<test
c...@pajamian.dhs.org> proto=ESMTP
helo=<[IPV6:2406:e003:c18:4601:6784:712f:7eb4:8313]>
...so it looks like postfix recognizes the syntax, but simply refuses to
do it, and indeed at look at smtpd_check.c indicates exactly why this is
an issue:
* Unfortunately, maps must be declared ahead of time so they can be
* opened before we go to jail. We could insist that the RHS can only
* contain a pre-defined restriction class name, but that would be too
* restrictive. Instead we warn if an access table references any map.
On a small-enough scale, it is possible to do some table lookup chaining
via the methods show in RESTRICTION_CLASS_README.
Right, but it doesn't scale well because you have to define each new
table in an individual restriction class, and if you have a lot of
senders you want to restrict in that manner it quickly turns into a lot
of restriction classes and you have to modify main.cf to add and remove
restriction classes for each sender.
The capability to evaluate an access in this way could be a very
powerful feature for Postfix, it would open up a whole host of
possibilities having to do with requirements to say that certain users,
be they sasl users, or senders, or whatever can only send to certain
other users, or more flexibility in how we restrict envelope senders to
certain logins, etc. We already have the syntax to do it, so it's
really just a matter of making it work somehow. Possibly some sort of
mechanism that would allow external tables to be pre-loaded, and inline
tables to be dynamically loaded from inside the jail? Considering that
inline tables should not need to access external dbs or the disk in any
way this should not be a jail violation to do so.
Peter
