On 7/22/2014 7:34 PM, Will Yardley wrote: > I'm wondering if someone can help me make sure I get the order right for > some recipient classes. I had hoped to just phase these out in favor of > a more unified system > > The *intent* was to have the recommended class behave the same as a user > without the attribute set to 'recommended'. > > Right now, the config (which was written by someone else, a long, long > time ago) looks something like this, which I realize doesn't accomplish > its original goal: > > Postfix 2.3.3 on RHEL 5 (upgrading to 2.6.6 very soon) > > smtpd_recipient_restrictions = > [...] > reject_rbl_client foo.example.org=127.0.0.4, > reject_unknown_recipient_domain, > reject_non_fqdn_recipient, > permit_mynetworks, > reject_unauth_destination, > [...] > check_recipient_access ldap:acct_class_ldap, > > [slightly simplified] > > smtpd_restriction_classes = minimum, modest, recommended, strict > > minimum = permit > > modest = reject_rbl_client foo.example.org, > permit > > recommended = reject_non_fqdn_sender, > reject_rbl_client foo.example.org > reject_rhsbl_client rhsbl.example.com > reject_rhsbl_sender rhsbl.example.com > permit > > strict = reject_non_fqdn_sender, > reject_non_fqdn_helo_hostname, > reject_unknown_reverse_client_hostname, > reject_rbl_client foo.example.org > reject_rbl_client bar.example.com > reject_rhsbl_client rhsbl.example.com > reject_rhsbl_sender rhsbl.example.com > permit > > The main problem I see here is that a) certain checks are made > redundant, and b) 'minimal' and 'modest' still have some of the > "recommended" checks included.
Don't worry too much about redundant or repeated checks in different classes. The impact is negligible. > > > My thought was that maybe I should do something like this instead: > > reject_non_fqdn_recipient, Be careful about rejecting mail from your own users/networks. Some desktop mail clients misbehave when the mail is rejected, either sending confusing messages to the user or continually retrying. > permit_mynetworks, > reject_unauth_destination, OK. > reject_unknown_recipient_domain, After reject_unauth_destination, the only domain left is yours. So this rule either won't do anything, or will reject your own mail if the local DNS hiccups. Probably best to remove it. Some folks like to use this rule before permit_mynetworks to prevent local users from sending to unknown domains. That's OK, but see my earlier comment about rejecting user mail. > check_recipient_access ldap:acct_class_ldap, > # "recommended", i.e., default stuff here > reject_non_fqdn_sender, > reject_rbl_client foo.example.org > reject_rhsbl_client rhsbl.example.com > reject_rhsbl_sender rhsbl.example.com > [...] > > and then have > recommended = Yes, that should work as expected. > > [to avoid redundant checks] > > Will this work, and are there any fatal flaws in my ordering? > -- Noel Jones
