Rodre Ghorashi-Zadeh wrote:
Yes, that's fine. Although it would be easier to just set
smtpd_delay_reject back to it's default of "yes", or remove it
from your config entirely.
Yes, I changed it around and that allowed me to specify the map in
smtpd_sender_restrictions=
Just one question so I can better my understanding of postfix, does it not make
logical sense to have the filter be a smtpd_recipient_restrictions because it
is being applied to the recipient address, or I am understanding these values
backwards?
smtpd_mumble_restrictions apply at stage "mumble". it doesn't mean they
check the "mumble" field. so at recipient stage (RCPT TO command), you
can check the client, the helo, the sender and the recipient. at the
sender stage (MAIL FROM command), you can check the client, the helo and
the sender. ... etc.
but when you use the default smtpd_delay_reject, all checks are done at
recipient stage, so you can put your checks wherever you want.
a common choice is to put all anti-uce checks under
smtpd_recipient_restrictions (so as to have an easily manageable linear
list of checks, and not need to repeat whitelisting checks), and to put
checks that are not for whitelisting or blocking uce under other
restrictions. This prevents accidental errors that make you an open
relay (OK in a map before reject_unauth_destination) or that cause all
anti uce checks to be skipped (accidentally I mean).
Also, when using maps like "hash" that do not allow for a default action
(you can't do: * do_foo_bar), you can use other restrictions to
implement this. for example
smtpd_helo_restrictions =
check_sender_access hash:/etc/postfix/test
reject
== test
example.com OK
This implements the (unrealistic) rule "reject if the sender is not in
example.com".
