1 (edited by bmackay 2014-06-03 12:48:57)

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.

2

Re: Optimal Order For smtpd_recipient_restrictions?

Your restriction rules are ok.

bmackay wrote:

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.

We have policy in Cluebringer to bypass emails sent from hosted mail accounts, so it's ok. Maybe you didn't setup SMTP auth in your mail client?

3

Re: Optimal Order For smtpd_recipient_restrictions?

The desktop client SMTP is set to port 587 (Deliver), SSL, Password Authentication. 

I switched back to the default order for some testing this evening and came up with consistent results from before.   I have tested this from three separate machines in our office.   When sending from our primary domain, Cluebringer bypasses the check.   When sending from a user in one of the other domains, the greylist check shows up in the log.   The second example from a third hosted domain generated an error on the desktop which matched what I saw yesterday.

Jun  2 20:09:50 mail1 postfix/smtpd[26968]: connect from su.cable.net[74.5.99.92]
Jun  2 20:09:52 mail1 cbpolicyd[2854]: module=Greylisting, action=defer, host=74.5.99.92, helo=[92.68.0.95], from=user@hosteddomain.com, to=user@primarydomain.com, reason=greylisted
Jun  2 20:09:52 mail1 postfix/smtpd[26968]: NOQUEUE: reject: RCPT from S010600195b4aeeec.su.shawcable.net[74.5.99.92]: 451 4.7.1 <user@primarydomain.com>: Recipient address rejected: Greylisting in effect, please come back later; from=<user@hosteddomain.com> to=<user@primarydomain.com> proto=ESMTP helo=<[92.68.0.95]>
Jun  2 20:09:52 mail1 postfix/smtpd[26968]: disconnect from su.cable.net[74.5.99.92]
Jun  3 22:44:22 mail1 cbpolicyd[2854]: module=Greylisting, action=defer, host=74.5.99.92, helo=[92.68.0.77], from=user@otherhosteddomain.com, to=user@primarydomain.com, reason=greylisted
Jun  3 22:44:22 mail1 postfix/smtpd[971]: NOQUEUE: reject: RCPT from su.cable.net[74.5.99.92]: 451 4.7.1 <user@primarydomain.com>: Recipient address rejected: Greylisting in effect, please come back later; from=<user@otherhosteddomain.com> to=<user@primarydomain.com> proto=ESMTP helo=<[92.68.0.77]>
Jun  3 22:44:22 mail1 postfix/smtpd[971]: disconnect from su.cable.net[74.5.99.92]

I have a server which is explicitly listed in mynetworks.   It was also getting greylisted with the default rule order.

Jun  2 07:13:16 mail1 cbpolicyd[19662]: module=Greylisting, action=defer, host=55.55.55.55

How does Cluebringer discover if an account is hosted locally or whether a server is listed in mynetworks?   I can't think of a case where you would want either of these mail sources greylisted.

Time to go digging in Cluebringer...

4

Re: Optimal Order For smtpd_recipient_restrictions?

There will be smtp authentication related data in SMTP session, for example:

sasl_method=plain
sasl_username=[address]
sasl_sender=[address]

NOTE: just a sample, the value might be different on your server.

Reference: http://www.postfix.org/SMTPD_POLICY_README.html