VR wrote: > I don't grasp how > > smtpd_recipient_restrictions= > check_client_access hash:/etc/postfix/access_client > check_helo_access hash:/etc/postfix/access_helo > > can equate to less whitelisting than: > > smtpd_client_restrictions= > check_client_access hash:/etc/postfix/access_client > > smtpd_helo_restrictions= > check_helo_access hash:/etc/postfix/access_helo > > I think the reason I might be getting hung up on this is because I'm > thinking postfix restrictions operate just like an SMTP conversation > > client > ehlo/helo > mail from > rcpt to > data > > which (I thought) means no matter where, for example: > check_helo_access appears, that particular check is only going to > operate in the realm of line 2 above. This is how things do work.
Restrictions inherit in descending order as noted in postconf(5) manual. Ex: client checks can be present in helo,sender,recipient,data(...); helo checks can be present in sender,recipient,data(...);etc. Doing so allows more complex checks such as: smtpd_helo_restrictions=check_client_access hash:/path/to/file /path/to/file 127.0.0 check_helo_access hash:/path/to/file2 You must also note the value of 'smtpd_delay_reject ' which defaults to yes. This, basically, puts all decisions of restrictions on hold until after RCPT TO. This also allows checks that normally are not allowed/meaningful in a class, such as a helo check in client, to function.
