Loading ...
Sorry, an error occurred while loading the content.

Re: Retriction order - a little advice please

Expand Messages
  • Noel Jones
    ... 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 ...
    Message 1 of 2 , May 1, 2010
    • 0 Attachment
      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.
    Your message has been successfully submitted and would be delivered to recipients shortly.