Prev: Out of Office auto reply setting
Next: rate limit issue
From: "Paul Hutchings" on 1 May 2010 13:28
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,
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
permit_mynetworks,
reject_unauth_destination,
check_client_access hash:/etc/postfix/client_whitelist,
check_sender_access hash:/etc/postfix/sender_whitelist,
check_sender_access hash:/etc/postfix/trusted_domains,
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,
reject_unknown_sender_domain,
reject_unauth_pipelining,
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,
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

Thanks,
Paul

--
MIRA Ltd

Watling Street, Nuneaton, Warwickshire, CV10 0TU, England.

Registered in England and Wales No. 402570
VAT Registration GB 114 5409 96

The contents of this e-mail are confidential and are solely for the use of the intended recipient.
If you receive this e-mail in error, please delete it and notify us either by e-mail, telephone or fax.
You should not copy, forward or otherwise disclose the content of the e-mail as this is prohibited.

From: Noel Jones on 1 May 2010 14:31
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.

 | 
Pages: 1
Prev: Out of Office auto reply setting
Next: rate limit issue