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 not
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
things.
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_recipient_maps,
If you're using postfix 2.1 or newer, change the above to
reject_unlisted_recipient.
http://www.postfix.org/postconf.5.html#reject_unlisted_recipient
check_client_access hash:/etc/postfix/client_blacklist,
check_sender_access hash:/etc/postfix/sender_blacklist,
# Call dkim proxy to sign mail from @ourdomain
check_sender_access hash:/etc/postfix/dkim_sign
Make sure that none of the above can ever return an OK,
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.
permit_mynetworks,
reject_unauth_destination,
OK.
check_client_access hash:/etc/postfix/client_whitelist,
check_sender_access hash:/etc/postfix/sender_whitelist,
check_sender_access hash:/etc/postfix/trusted_domains,
Consider combining the two check_sender_access tables to save
some buffer space and file handles. This is a minor issue.
check_helo_access regexp:/etc/postfix/helo_checks.regexp,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
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,
reject_unauth_pipelining,
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,
reject_rhsbl_client multi.uribl.com,
reject_rhsbl_sender multi.uribl.com,
reject_rhsbl_sender multi.surbl.org,
reject_rhsbl_client multi.surbl.org,
Remember to review your RBL listing policy every once in a
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,
check_client_access regexp:/etc/postfix/greylist_dyn_fqdn.regexp,
check_client_access regexp:/etc/postfix/greylist_hosts.regexp,
permit
The final "permit" doesn't do anything since that's the
default, but it doesn't hurt anything.
Looks OK.
