[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

2024-02-14 Thread Jakob Cornell via Postfix-users
Having 12x that text in the postconf masnpage would not help. Certainly not, but I think there's a good middle ground. A more practical change would just make brief reference to the distinction. For example: check_recipient_access type:table Search the specified access(5) database for

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

2024-02-14 Thread Wietse Venema via Postfix-users
Jakob Cornell via Postfix-users: > Hi Wietse, > > > I can add a debug log that a specific table is skipped for a specific name. > > Ah yes, that's a better fix. That would take care of my confusion with the > logging. > > Do you have any thoughts on postconf(5) describing partial key > lookups

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

2024-02-13 Thread Jakob Cornell via Postfix-users
Hi Wietse, I can add a debug log that a specific table is skipped for a specific name. Ah yes, that's a better fix. That would take care of my confusion with the logging. Do you have any thoughts on postconf(5) describing partial key lookups in the descriptions for check_*_access without

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

2024-02-13 Thread Wietse Venema via Postfix-users
Jakob Cornell via Postfix-users: > If I understand right the non-indexed skip is implemented by the > 'continue' at global/maps.c:199, so a flag could be added to track > whether execution has passed line 199 and if not, the log statement > at 221 could be skipped. I can add a debug log that a

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

2024-02-12 Thread Jakob Cornell via Postfix-users
The logging code lives outside the individual table drivers and with "_maps" parameters that support multiple tables, above any individual table lookup. Oh I see. Well without rearchitecting the logging it seems this could be made more intuitive for the case where all of the maps in a

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

2024-02-12 Thread Viktor Dukhovni via Postfix-users
On Mon, Feb 12, 2024 at 09:05:12PM -0600, Jakob Cornell via Postfix-users wrote: > Can we improve this so it's easier to get this right on the first try > as a newcomer, and make it more clear what's happening at run time? It > looks like a code change to skip the logging along with the actual >

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

2024-02-12 Thread Jakob Cornell via Postfix-users
Thanks Viktor. I found what I believe you're referencing in the access(5) man page: With lookups from indexed files such as DB or DBM, or from networked tables such as NIS, LDAP or SQL, patterns are tried in the order as listed below: Is this the only documentation explaining this

[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive

2024-02-11 Thread Viktor Dukhovni via Postfix-users
On Sun, Feb 11, 2024 at 07:42:24PM -0600, Jakob Cornell via Postfix-users wrote: > smtpd_recipient_restrictions = > check_sender_access regexp:/etc/postfix/db/sender_access_table > ... As documented regexp, pcre, ... tables don't do "partial key" lookups. This is deliberate and