OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: smtpd_data_restrictions (Was: Re: )

From: mouss (mlist.onlyfree.fr)
Date: Wed May 09 2007 - 10:17:54 CDT


LuKreme wrote:
> [
> Sorry about the lack of subject, I have no idea how that happened
> ]
>
> On 7-Mar-2007, at 15:45, MrC wrote:
>> http://www.postfix.org/SMTPD_ACCESS_README.html#danger
>
> AH, thanks, that makes sense now.
>
>> In order to avoid surprises like these with
>> smtpd_recipient_restrictions, you should place non-recipient
>> restrictions AFTER the reject_unauth_destination restriction, not
>> before. In the above example, the HELO based restrictions should be
>> placed AFTER reject_unauth_destination, or better, the HELO based
>> restrictions should be placed under smtpd_helo_restrictions where
>> they can do no harm.
>
> smtpd_recipient_restrictions =
> check_client_access hash:/usr/local/etc/postfix/pop-before-smtp,
> check_sender_access pcre:/usr/local/etc/postfix/sender_access.pcre,
you are still using a dangerous check. move this below
reject_unauth_destination.
> reject_invalid_hostname,
as Noel said, this may be harsh if you have non techy users with broken
MUAs. note that the error message that this checks returns may not be
made available by the MUA (the MUA may just say "fatal error"...).
> reject_non_fqdn_sender,
> reject_non_fqdn_recipient,
> reject_unknown_sender_domain,
> reject_unauth_pipelining,
As Noel said, this is useless here.
> permit_mynetworks,
> reject_unlisted_recipient,
> permit_sasl_authenticated,
> reject_unauth_destination,
> check_client_access regexp:$config_directory/check_client_fqdn.rx
why mix pcre and regexp. since you have pcre, you should use pcre.
> check_recipient_access
> pcre:/usr/local/etc/postfix/recipient_checks.pcre,
> check_client_access hash:/usr/local/etc/postfix/access,
> reject_rbl_client zen.spamhaus.org
> permit