[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
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
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
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] Unexpected behavior of regexp table in check_sender_access directive
Hi folks,
I'm updating the configuration of my mail server and having problems with a
regexp table. This is the relevant configuration in main.cf:
smtpd_recipient_restrictions =
check_sender_access regexp:/etc/postfix/db/sender_access_table
...
And /etc/postfix/db/sender_access_table:
/^jcornell\.net$/ reject_sender_login_mismatch, permit
/^m\.acorn\.ignorelist\.com$/ reject_sender_login_mismatch, permit
With this configuration when I attempt to send a test email from
ja...@jcornell.net to an external address I see in the logs that the regexp
lookup fails:
Feb 12 01:18:01 server postfix/smtpd[26577]: dict_regexp_lookup:
/etc/postfix/db/sender_access_table: ja...@jcornell.net
Feb 12 01:18:01 server postfix/smtpd[26577]: maps_find:
regexp:/etc/postfix/db/sender_access_table: ja...@jcornell.net: not found
Feb 12 01:18:01 server postfix/smtpd[26577]: maps_find:
regexp:/etc/postfix/db/sender_access_table: jcornell.net: not found
Feb 12 01:18:01 server postfix/smtpd[26577]: maps_find:
regexp:/etc/postfix/db/sender_access_table: net: not found
Feb 12 01:18:01 server postfix/smtpd[26577]: maps_find:
regexp:/etc/postfix/db/sender_access_table: jakob@: not found
Feb 12 01:18:01 server postfix/smtpd[26577]: mail_addr_find: ja...@jcornell.net
-> (not found)
Notice that I've used domain names in the table patterns, and one of the
attempted lookups is with the domain from the address, as intended, but the
lookup fails. However, the same lookup apparently succeeds when done using
'postmap':
# postmap -q jcornell.net regexp:/etc/postfix/db/sender_access_table
reject_sender_login_mismatch, permit
My temporary workaround is to use an inline table instead:
check_sender_access inline:{ { jcornell.net=reject_sender_login_mismatch,
permit }, { m.acorn.ignorelist.com=reject_sender_login_mismatch, permit } }
This works fine for ja...@jcornell.net, but my ultimate goal is to configure
delivery for *.m.acorn.ignorelist.com too (arbitrary subdomain), and an inline
table won't work for that. Could this be a bug in regexp table lookup?
Thanks,
Jakob
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
