Topic: Optimal Order For smtpd_recipient_restrictions?
==== Required information ====
- iRedMail version:
- Store mail accounts in which backend (LDAP/MySQL/PGSQL):
- Linux/BSD distribution name and version:
- Related log if you're reporting an issue:
====I did a fresh install of iRedMail in the last week or so and I noticed that the default restriction order seemed quite different than what I had deployed several years ago with my last iRedMail install. I've been testing the new server, but you never notice some things until you have live users in the system.
I have borrowed what I believe is the default order from another post. (I noticed multiple people all posting questions with similar settings.)
smtpd_recipient_restrictions =
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unlisted_recipient,
check_policy_service inet:127.0.0.1:7777,
check_policy_service inet:127.0.0.1:10031,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
I'm going to post the list I have adopted with an explanation. I'm sure others will have their own opinion and I'm posting this primarily to encourage discussion. Your requirements may vary and I recommend that you don't just copy my config. I may have been doing this wrong for years and I certainly stand to be corrected.
My config looks like this
smtpd_recipient_restrictions =
check_client_access hash:/etc/postfix/whitelist,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unlisted_recipient,
check_policy_service inet:127.0.0.1:7777,
permit_mynetworks,
permit_sasl_authenticated,
check_policy_service inet:127.0.0.1:10031,
reject_unauth_destination,
check_client_access cidr:/etc/postfix/rbl_override,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,
reject_rbl_client rblname.one,
reject_rbl_client rblname.two,
Here's my thinking.
I have two "opt-out" points where I can short circuit checks for specific servers. At the beginning I have my white list which I use to include a very short list of remote servers. This is not the same as "my networks". An example might be a badly configured MS Exchange server in a lawyer's office which is breaking sender_domain, non-fqdn_sender or other rules. The business needs far outweigh the risk mitigated by enforcing the remainder of the smtpd recipient restrictions. I'm sure there is a more elegant way to do this, but this is a legacy method that I've carried over from previous servers. It's quick and dirty when I have a client who doesn't care that some Internet RFC isn't being followed and his legal document isn't showing up in his Inbox.
Then I run all the inexpensive tests such a FQDN checks. These are all local and quickly determined directly by Postfix. The order of these rejects is not critical.
What struck me as odd in the default order is that permit_mynetworks and permit_sasl_authenticated came after policyd. If you have greylisting on, which I believe it is by default, then you are greylisting trusted connections. In testing the original config I even saw greylist "Come back later" messages when connecting on 587 from a desktop client. So I have bumped Cluebringer below my trusted connections.
Next lets reject unauth_destination before we do anything expensive in the way of RBLs.
I have my second opt-out point here. Some RBLs are rather strict and will list email hosts like Yahoo in their blacklists. I don't opt to exclude Yahoo (although some users complain) but I do exclude official email server CIDRs for Gmail, Hotmail, Facebook, Twitter and my Helpdesk provider. In my experience tons of spam purports to be from a Hotmail or Gmail address, but very little of it actually originates from their servers. To be fair, I think Yahoo has cleaned up their act in recent months.
I have a few more strict HELO requirements and then leave the heavy lifting of the RBLs until last.
Any suggestions on how to optimize this list?
----
Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.