I am revisiting my config and my config was made a long time ago (before 
relay_restrictions)

Would this be a good restrictions set? I think it is but I’m not 100% certain 
if this is efficient for instance. For instance, I am blocking 
reject_non_fqdn_recipient in  smtpd_recipient_restrictions without the 
permit_mynetworks and such first. Isn’t it then not more efficient to do that 
at the start of smtpd_relay_restrictions? And I also wonder if it isn’t better 
to remove permit_mynetworks from smtpd_relay_restrictions so that if a device 
has broken into my network (e.g. via Wifi), it cannot spam the world without 
authentication.

smtpd_client_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        check_client_access 
regexp:/opt/local/etc/postfix/rna_rbl_whitelist_clients,
        reject_rbl_client zen.spamhaus.org,
        permit
smtpd_helo_restrictions =
        permit_mynetworks,
        reject_non_fqdn_helo_hostname,
        reject_invalid_helo_hostname,
        permit
smtpd_sender_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_unknown_sender_domain
smtpd_relay_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_unauth_destination
smtpd_recipient_restrictions =
        reject_non_fqdn_recipient,
        reject_unlisted_recipient
# with greylisting:
#smtpd_recipient_restrictions =
#       reject_non_fqdn_recipient,
#       reject_unlisted_recipient,
#       check_client_access 
regexp:/opt/local/etc/postfix/rna_policy_whitelist_clients,
#       check_sender_access 
regexp:/opt/local/etc//postfix/rna_policy_whitelist_senders,
#       check_policy_service unix:private/policy permit
smtpd_data_restrictions =
        reject_unauth_pipelining,
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_multi_recipient_bounce


Gerben Wierda
Chess and the Art of Enterprise Architecture <http://enterprisechess.com/>
Mastering ArchiMate <http://masteringarchimate.com/>
Architecture for Real Enterprises 
<https://www.infoworld.com/blog/architecture-for-real-enterprises/> at InfoWorld
On Slippery Ice <https://eapj.org/on-slippery-ice/> at EAPJ

Reply via email to