Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: mouss (moussnetoyen.net)
Date: Fri Aug 22 2008 - 02:53:13 CDT
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
This implements the (unrealistic) rule "reject if the sender is not in