Jon wrote: > Looking for some clarification to help me understand. Are > smtpd_*_restrictions processed in this order: > > smtpd_client_restrictions > smtpd_helo_restrictions > smtpd_sender_restrictions > smtpd_recipient_restrictions > smtpd_data_restrictions > > > > If these restriction mechanisms share a common hash file for their > check, for example:
This can be done, but it is not a good practice. You may get unintended results. > > /etc/postfix/main.cf > ... > smtpd_client_restrictions = check_client_access > hash:/etc/postfix/access_hash ... > ... > smtpd_sender_restrictions = check_sender_access > hash:/etc/postfix/access_hash ... > ... > > /etc/postfix/access_hash > ip.ad.dre.ss ok > tld.com REJECT Access denied > > would this OK if found in smtp_client_restrictions trump REJECT if > found by smtpd_sender_restrictions against tld.com and allow the > message to queue? > Actions from an access(5) map are processed for that class alone. Once a REJECT is triggered, the message is rejected. Nothing can change that. Once an OK is triggered, that *class* is no longer checked. Your example is the reason why it is bad to reuse maps for different checks.
