Am 10.05.2014 06:35, schrieb deoren: > Setup: > > * backup MX with light anti-spam policies (for the moment)
the root of all evil is by setup a backup MX at all there is a reason why smtp servers retry later if the destination is down and that fact is even used for greylisting to reduce spam > * primary MX with current policies. Also whitelists the backup MX via > check_client_access directive and via > permit_mynetworks > > Question: > > If a spam email makes it "in" through the backup MX and is delivered to the > primary, will the 'permit_mynetworks' > or 'check_client_access' directives prevent other checks from blocking the > email? In other words, do those two > directives only apply to mail that originates from the backup MX itself or > all mail that flows through it? nobody knows because nobody knows wat is in that configurations "check_recipient_access" in any ways is dangerous empty "smtpd_recipient_restrictions" is not really smart why are you doing that instead configure them and place the line *below* permit_mynetworks? check_recipient_access, check_sender_access and check_client_access with no relay and smtpd restricitons before makes you sooner or later to a open-realy, why was discussed here many times > Settings on the primary MX: > > smtpd_recipient_restrictions = > permit_mynetworks > reject_unauth_destination > check_recipient_access hash:/etc/postfix/recipient_access.conf > check_sender_access hash:/etc/postfix/sender_access.conf > check_client_access hash:/etc/postfix/client_access.conf > check_policy_service inet:127.0.0.1:10023 > reject_invalid_helo_hostname > reject_non_fqdn_helo_hostname > reject_unknown_client_hostname > reject_unknown_sender_domain > reject_unknown_recipient_domain > reject_non_fqdn_sender > reject_non_fqdn_recipient > reject_unauth_pipelining > reject_rbl_client zen.spamhaus.org > reject_rbl_client b.barracudacentral.org
