main.cf recipient_restrictions rules order

[bdoster]

I've inherited a system built by someone else with no "baton handoff", so am learning it as I go. Recently a bounced email issue arose, and in trying to decipher the cause and allow this email in, I've found the following in main.cf. I've added numeric comments on significant lines which are explained below.

smtpd_recipient_restrictions =
# added 12/11/05
        reject_unlisted_recipient,
        check_client_access  regexp:/etc/postfix/fqrdns.regexp, #1
        check_helo_access      hash:/etc/postfix/access,
        check_helo_access    regexp:/etc/postfix/helo_blacklist.regexp,
        check_sender_access    hash:/etc/postfix/blacklist,
        check_sender_access  regexp:/etc/postfix/sender_blacklist.regexp,
        check_sender_mx_access cidr:/etc/postfix/mx_access.txt,
        check_client_access    hash:/etc/postfix/broken_helos, #2
        reject_invalid_hostname,
        reject_non_fqdn_sender,
        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
        check_sender_access regexp:/etc/postfix/filter_10026_catchall,
        permit_mynetworks,
        reject_non_fqdn_hostname,
        reject_non_fqdn_recipient,
        reject_unauth_destination,  #3
        check_client_access    hash:/etc/postfix/fqrdns_override #4

#1 is where the email gets blocked with a "Relay via ISP" comment. I tried adding the user's email address to #2 as OK, where there are LOTS of "OK"s for others -- it didn't work. So I did some research and created the file at #4, placing it below #3 as my research indicated I should. Still no joy.

But the more I read about this file, the more it seems upside-down to me. First it seems that #2 needs to be above #1. Second, everything I've read indicates that #2 should be below #3. So now I'm thinking that I should have #3 where it is, followed by #2, followed by #1, and #4 probably isn't needed.

Since I am learning this system on the fly, I thought it would be prudent to poll the masses for input before making changes that could have unforeseen effects. Could there be a legit reason for having #1 and #2 above #3? As for #2 following #1, I can see that IF the original author thought that NO ONE should EVER be allowed to override the checks in #1 -- but wouldn't that be extreme?

TIA for your thoughts!
--bd

 

[Noway2]

Welcome to tek-tips.
You've got a lot of check lists and you've got a lot of restrictions only in one category. Postfix can apply checks to various parts of the transaction and you may want to read up on how this works to get a better understanding.

When it comes to the postfix rules, they will be processed in order. Normally this is used to attempt the light weight checks before using DNS and content scanning applications. I don't understand what the person who set your configuration up was thinking with regards to spreading these list checks out like they did. One thing feature, which you will see indicated below in the code sample provided is smtpd_delay_reject, which causes Postfix to complete the transaction set before rejecting the mail. This is done so that they spammer does not know what check caused their junk to get rejected.

Anyway, here is the restriction set used by the mailing list of my local LUG. It has had several pairs of experienced eyes going over it and been refined extensively to provide balance between spam rejection and performance. I thought it might be helpful for you to see another example, so I provided it below.

# check HELO message (see [URL unfurl="true"]http://www.freesoftwaremagazine.com/articles/focus_spam_postfix)[/URL]
smtpd_delay_reject = yes
smtpd_helo_required = yes
disable_vrfy_command = yes

smtpd_client_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  ## NO LONGER WORKING -> reject_rbl_client relays.ordb.org,
  check_client_access hash:/etc/postfix/tables/access_client,
  # dsbl.org says this service is gone.
  #reject_rbl_client list.dsbl.org,
  reject_rbl_client zen.spamhaus.org,
  permit

smtpd_helo_restrictions =
  permit_sasl_authenticated,
  # permit_mynetworks is required for SquirrelMail to work
  permit_mynetworks,
  check_helo_access hash:/etc/postfix/tables/access_helo,
  reject_non_fqdn_hostname,
  reject_invalid_hostname,
  reject_unknown_hostname,
  permit

# check sender address (see [URL unfurl="true"]http://www.freesoftwaremagazine.com/articles/focus_spam_postfix)[/URL]
smtpd_sender_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  # check to see if they claim to be ME
  ##warn_if_reject check_sender_mx_access
  check_sender_access hash:/etc/postfix/tables/access_sender,
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
  permit

smtpd_recipient_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  #UNNECESSARY reject_non_fqdn_recipient,
  #UNNECESSARY reject_unknown_recipient_domain,
  reject_unauth_destination,
  check_recipient_access hash:/etc/postfix/tables/access_recipient,
  # not implemented yet - I am not dealing with secondaries yet
  #check_helo_access mysql:/etc/postfix/mysql_secondary_mx.cf,
  # Postgrey is on port 10023
  check_policy_service inet:127.0.0.1:10023,
  # 'spfpolicy' is defined in master.cf, points to a perl script
  # note - exceptions to the policy (2ndary at wayfarer) live in that script
  # next line was the perl one.
  #check_policy_service unix:private/spfpolicy,
  # this one is the python one
  check_policy_service unix:private/pypolicyd-spf,
  permit

policy_time_limit = 3600

 

[bdoster]

Thanks for the reply. I like the idea behind the smptd_delay_reject -- on my inerited system it is set to No, but I'll look into that some more.

In the meantime, I'd really appreciate feedback on my origianal questions. Am I right about the way I think the lines I mentioned should be reordered? And if yes, is there a downside to making the changes I proposed?

-bd