[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive
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 the resolved RCPT TO address (and for some tables domain, parent domains, and localpart@), and execute the corresponding action. That way a newcomer knows to look for clarification on "some" if they intend to rely on a partial key lookup. Another option is to remove the partial key enumeration from these descriptions entirely. It appears that some restriction types are already documented this way (e.g. check_client_mx_access). Jakob ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive
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 mention of > the indexed table type limitation? There are a dozen or more check_*_access features. Their descriptions all link to the access(5) manpage that describes the table lookups. Having 12x that text in the postconf masnpage would not help. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive
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 mention of the indexed table type limitation? Thanks for Postfix! Jakob ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive
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 specific table is skipped for a specific name.
for (map_name = maps->argv->argv; *map_name; map_name++) {
...
if (flags != 0 && (dict->flags & flags) == 0) {
if (msg_verbose)
msg_info("%s: %s: skipping %s lookup for %s",
myname, maps->title, *map_name, name);
continue;
}
/* Seach this table for this key. Return after 'found' or error. */
}
/* Log "search aborted" after error, "not found" otherwise. */
There is no need for additional flags to distinguish between "skipped"
and "not found": "skipped" always applies to a single table instance,
while "not found" always applies to the table collection.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive
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 sequence are skipped (e.g. my case with a single regexp table). 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. Whether this would actually be a net benefit I'm not sure, but it seemed worth mentioning. Some tables support partial keys, other do not, as documented under in regexp_table(5): Ah, didn't see this before in the man page. Thoughts on updating the documentation for check_recipient_access to mention the indexed/non-indexed distinction? Thoughts on more fully documenting which table types do partial key lookups? Jakob ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive
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 > table lookups might be in order, and some clarification in the docs. > I'm happy to create patches for some docs changes at least if that's > useful. Not sure what the contribution policy of the project is. That'd be a layer-violation. The logging code lives outside the individual table drivers and with "_maps" parameters that support multiple tables, above any individual table lookup. It does not make a lot of sense to push the logging down into each table. Some tables support partial keys, other do not, as documented under in regexp_table(5): TABLE SEARCH ORDER Patterns are applied in the order as specified in the table, until a pattern is found that matches the input string. Each pattern is applied to the entire input string. Depending on the application, that string is an entire client hostname, an entire client IP address, or an entire mail address. Thus, no parent domain or parent network search is done, and user@domain mail addresses are not broken up into their user and domain constituent parts, nor is user+foo broken up into user and foo. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive
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 distinction? It doesn't state which table types are indexed, and in the database readme only a few types are called out as indexed. (My testing indicates the 'inline' type is indexed, but I can't find mention of this in the documentation.) While the documentation for 'check_recipient_access' in postconf(5) links to access(5), it doesn't mention the indexed table type distinction, implying the lookup sequence for indexed files is used regardless of the table type: check_recipient_access type:table Search the specified access(5) database for the resolved RCPT TO address, domain, parent domains, or localpart@, and execute the corresponding action. And then there's the confusing logs from my original email which appear to show the full lookup sequence being done on a regexp table. My assumption is that the full lookup sequence is actually being processed, but individual lookups beyond the first one are being skipped without skipping the corresponding logging code. 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 table lookups might be in order, and some clarification in the docs. I'm happy to create patches for some docs changes at least if that's useful. Not sure what the contribution policy of the project is. Jakob ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive
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 correct behaviour. > /^jcornell\.net$/ reject_sender_login_mismatch, permit This is just the domain part of an address, and would match in an indexed file or similar table, not in a regexp, pcre, ... table. > This works fine for ja...@jcornell.net, but my ultimate goal is to > configure delivery for *.m.acorn.ignorelist.com too (arbitrary > subdomain), See access(5). In indexed files, domains by default also match their sub-domains, but see: https://www.postfix.org/postconf.5.html#parent_domain_matches_subdomains and preferably set it empty and then list: access: blocked.example REJECT .blocked.exampleREJECT > Could this be a bug in regexp table lookup? Works as intended. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
