On 2/2/2013 1:55 PM, Gerben Wierda wrote:
> Just so there is no misunderstanding: I am unhappy running an older version
> that is not updated with security fixes anymore and I had planned to upgrade
> before now (but not immediately when 10.8 came out as 10.8.0 Server was not
> what you say trustworthy. I skipped 10.7 server altogether because it is a
> disaster area.
>
> I plan to upgrade asap to 10.8 server.
>
> For now, I came up with:
>
> smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated
> check_client_access hash:/etc/postfix/whitelist_mtaclientdomains
> reject_rbl_client zen.spamhaus.org permit
> smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks
> reject_unauth_destination check_client_access
> hash:/etc/postfix/whitelist_mtaclientdomains check_policy_service
> unix:private/policy permit
That's awfully difficult to read. Try putting each on its own line as
in the examples we've given you. Also, put everything under
smtpd_recipient_restrictions
and eliminate smtpd_client_restrictions altogether. Now you no longer
have to duplicate restrictions between them. More importantly, you have
fine grained control over evaluation order. Thus, this would be much
better:
smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
check_client_access pcre:/etc/postfix/client_access
check_sender_access pcre:/etc/postfix/sender_access
reject_rbl_client zen.spamhaus.org
check_policy_service unix:private/policy
...
/etc/postfix/client_access:
/.*facebook\.com$/ permit
...
/etc/postfix/sender_access
/.*@apg\.nl$/ permit
...
> Which makes sure some clients are permitted before they end up in either RBL
> or Policy. Just for you more experienced people: is this OK?
When using separate client and recipient restrictions, as you have
above, your rbl check against Zen can trigger before your whitelist
checks, causing a rejection. Using the method I've detailed above
avoids this situation. Because Postfix performs delayed rejection by
default, you can put all of your restrictions under
smtpd_recipient_restrictions and carefully control the order of
restriction evaluations. I'd guess that every experienced OP on this
list does it this way. It just doesn't make any sense to do otherwise.
> Does macports overwrite what Apple has provided or does it have its own
> separate tree (like fink used to have, which means you get another job that
> is: keeping the second tree up to date)?
I have zero experience with MacOS. Sorry.
--
Stan
