1

Topic: POSTFIX - /etc/postfix/main.cf - permit and reject statements order

==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version (check /etc/iredmail-release): 0.9.9
- Deployed with iRedMail Easy or the downloadable installer? Downloadable
- Linux/BSD distribution name and version: Ubuntu 18.04
- Store mail accounts in which backend (LDAP/MySQL/PGSQL):  MySQL
- Web server (Apache or Nginx): Nginx
- Manage mail accounts with iRedAdmin-Pro? iRedAdmin
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
====

Hi

After the fresh install of iRedmail 0.9.9, I modified the file - /etc/postfix/main.cf to improve security.

Can I please know whether the order of adding the permit and reject statements are correct here?
I am not sure whether there is any order to make it effective.

..
smtpd_helo_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    check_helo_access pcre:/etc/postfix/helo_access.pcre
    reject_non_fqdn_helo_hostname
    reject_unknown_helo_hostname

# Sender restrictions
smtpd_sender_restrictions =
    reject_unknown_sender_domain
    #Below line added to reject email sending hosts without a valid PTR record
    reject_unknown_reverse_client_hostname
    #Below line added to reject email sending hosts without a valid A Record
    reject_unknown_client_hostname
    reject_non_fqdn_sender
    reject_unlisted_sender
    permit_mynetworks
    permit_sasl_authenticated
    check_sender_access pcre:/etc/postfix/sender_access.pcre

# Recipient restrictions
smtpd_recipient_restrictions =
    reject_non_fqdn_recipient
    reject_unlisted_recipient
    check_policy_service inet:127.0.0.1:7777
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination

...


Mathew

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2

Re: POSTFIX - /etc/postfix/main.cf - permit and reject statements order

Postfix applies the restriction rules in order, so you must be very clear what the restriction rules do, and order them correctly. iRedMail default settings are well balanced and i think it's very good and secure.

3

Re: POSTFIX - /etc/postfix/main.cf - permit and reject statements order

Hi Zhang,

Thanks for the reply.

Will you be able to confirm or at least comment on my changes?

I used the default iRedmail configuration and added few lines more and need to be sure they will work.

Thanks in advance for your support.

Mathew


ZhangHuangbin wrote:

Postfix applies the restriction rules in order, so you must be very clear what the restriction rules do, and order them correctly. iRedMail default settings are well balanced and i think it's very good and secure.

4

Re: POSTFIX - /etc/postfix/main.cf - permit and reject statements order

mathewfer wrote:

# Sender restrictions
smtpd_sender_restrictions =
    reject_unknown_sender_domain
    #Below line added to reject email sending hosts without a valid PTR record
    reject_unknown_reverse_client_hostname
    #Below line added to reject email sending hosts without a valid A Record
    reject_unknown_client_hostname
    reject_non_fqdn_sender
    reject_unlisted_sender
    permit_mynetworks
    permit_sasl_authenticated
    check_sender_access pcre:/etc/postfix/sender_access.pcre

I think it will cause problem for your end users.

Your users who are going to send email by smtp auth will be rejected by reject_unknown_reverse_client_hostname, reject_unknown_reverse_client_hostname, reject_unknown_client_hostname, reject_non_fqdn_sender.
You must move them after "permit_sasl_authenticated", so that user can be passed with "permit_sasl_authenticated" rule and postfix ignores all other rules AFTER "permit_sasl_authenticated".

Again, i think iRedMail default setting is very good and well balanced, i hope you clearly understand what you modified settings. my suggestion is just using iRedMail default settings in this case.

5

Re: POSTFIX - /etc/postfix/main.cf - permit and reject statements order

Hi Zhang,

Thanks for the reply.
So far, I have checked all the users can send/receive emails within the local domain and externally.
They use SSL authentication to send emails on SMTP and IMAP SSL authentication too. Users are on Windows, MAC, iPhone and also webmail (SSL), all are working well.

I am actually checking the order is correct. I will do more research on this order as I am looking to make it very tight to combat spam. I understand iRedmail defaults are good but we got some spam and after adding those few more lines, it reduced to almost zero so far. I will report back when/if I find more on this.

Thanks and regards,

Mathew




ZhangHuangbin wrote:
mathewfer wrote:

# Sender restrictions
smtpd_sender_restrictions =
    reject_unknown_sender_domain
    #Below line added to reject email sending hosts without a valid PTR record
    reject_unknown_reverse_client_hostname
    #Below line added to reject email sending hosts without a valid A Record
    reject_unknown_client_hostname
    reject_non_fqdn_sender
    reject_unlisted_sender
    permit_mynetworks
    permit_sasl_authenticated
    check_sender_access pcre:/etc/postfix/sender_access.pcre

I think it will cause problem for your end users.

Your users who are going to send email by smtp auth will be rejected by reject_unknown_reverse_client_hostname, reject_unknown_reverse_client_hostname, reject_unknown_client_hostname, reject_non_fqdn_sender.
You must move them after "permit_sasl_authenticated", so that user can be passed with "permit_sasl_authenticated" rule and postfix ignores all other rules AFTER "permit_sasl_authenticated".

Again, i think iRedMail default setting is very good and well balanced, i hope you clearly understand what you modified settings. my suggestion is just using iRedMail default settings in this case.

6

Re: POSTFIX - /etc/postfix/main.cf - permit and reject statements order

mathewfer wrote:

I understand iRedmail defaults are good but we got some spam and after adding those few more lines, it reduced to almost zero so far. I will report back when/if I find more on this.

I understand your new rules can catch some more spams, but be careful, many legit mail servers may trigger them too. That's what i mean "balanced".