Re: Retriction order - a little advice please
- On 5/1/2010 12:28 PM, Paul Hutchings wrote:
> Just doing a bit of a sanity check/tidy-up on my Postfix box, I've notIf you're using postfix 2.1 or newer, change the above to
> had to go near it for ages as it all just works, but I'm checking a few
> other things and I'm slowly reminding myself of various Postfix related
> These are my current restrictions, I think the map names are indicative
> of what they do. I'd appreciate any tips on streamlining/optimizing
> these - for example I know the DKIM one is where it is because it has to
> kick in before "permit_mynetworks" so it triggers even if it's spam and
> the mail is then rejected by a further check such as SPF.
> The box is an internet facing relay.
> smtpd_recipient_restrictions =
> check_client_access hash:/etc/postfix/client_blacklist,Make sure that none of the above can ever return an OK,
> check_sender_access hash:/etc/postfix/sender_blacklist,
> # Call dkim proxy to sign mail from @ourdomain
> check_sender_access hash:/etc/postfix/dkim_sign
otherwise you become an open relay. Consider moving these to
smtpd_sender_restrictions where an OK is harmless; moving them
shouldn't change the end result.
> check_client_access hash:/etc/postfix/client_whitelist,Consider combining the two check_sender_access tables to save
> check_sender_access hash:/etc/postfix/sender_whitelist,
> check_sender_access hash:/etc/postfix/trusted_domains,
some buffer space and file handles. This is a minor issue.
> check_helo_access regexp:/etc/postfix/helo_checks.regexp,There are unlikely to be any non-fqdn recipients after
reject_unauth_destination. This won't hurt anything, but
probably will never reject anything.
> reject_unknown_sender_domain,Older versions of postfix (postfix < 2.5 IIRC) need to have
reject_unauth_pipelining in smtpd_data_restrictions. It
doesn't break anything here, but might not reject anything.
> reject_rbl_client zen.spamhaus.org,Remember to review your RBL listing policy every once in a
> reject_rhsbl_client multi.uribl.com,
> reject_rhsbl_sender multi.uribl.com,
> reject_rhsbl_sender multi.surbl.org,
> reject_rhsbl_client multi.surbl.org,
while to make sure the ones you're using are still
operational, and still do what you intend. That said, the
ones you're using are all active and are pretty widely used.
But that can change.
> check_policy_service unix:private/spf,The final "permit" doesn't do anything since that's the
> check_client_access regexp:/etc/postfix/greylist_dyn_fqdn.regexp,
> check_client_access regexp:/etc/postfix/greylist_hosts.regexp,
default, but it doesn't hurt anything.