On Fri, May 31, 2013 at 12:43:51AM -0400, James Zee wrote:
> I was hoping someone could take a quick glance at my
> smtpd_*_restrictions configurations. While I've read and (re-)read the
> SMTPD_ACCESS_README file a few times over I would be greatly
> appreciative if someone could sanity check my work.
>
> The goal is, obviously, to (a) block spammers, (b) only allow relaying
> / sending to SASL-authorized users.
>
> -->8--
>
> smtpd_relay_restrictions =
If you have smtpd_relay_restrictions, you have postscreen. Consider
postscreen in addition to the spam control restrictions below.
> permit_mynetworks
> permit_sasl_authenticated
> check_policy_service unix:private/policy-spf
> reject_unauth_destination
As was indicated upthread, this could be a problem. I'm not sure why
you'd be checking SPF in smtpd_relay_restrictions anyway.
Also, you really should separate submission from your inbound port
25. I only allow relaying on the submission port. As such I define
separate smtpd_*_restrictions for the submission port, to wit:
[ master.cf ]
submission inet n - n - - smtpd
-o smtpd_tls_auth_only=yes -o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=
-o smtpd_relay_restrictions=$submission_relay_restrictions
-o milter_macro_daemon_name=ORIGINATING
-o syslog_name=postfix/submission
(Also unset any other restrictions which are in use on port 25.)
[ main.cf ]
submission_relay_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination
(Also include any other restrictions that you want to apply to your
own users, before the permit_* ones.)
> smtpd_recipient_restrictions =
> reject_non_fqdn_sender
> reject_unknown_sender_domain
ok
> reject_non_fqdn_recipient
> reject_unknown_recipient_domain
These two will generally only apply to your own users. Won't hurt
anything being applied to inbound mail, but won't help, either.
> reject_non_fqdn_hostname
> reject_invalid_hostname
These are both deprecated syntax. Did you look them up in the
postconf(5) manual? They are reject_non_fqdn_helo_hostname and
reject_invalid_helo_hostname respectively. And they're reasonably
safe except that they should not be applied to your own users.
> reject_unauth_destination
smtpd_relay_restrictions has this, so it's not needed here. OTOH
perhaps you did need the permit_* restrictions you have omitted;
everything here will also be applied to your own users: very wrong!
> reject_unauth_pipelining
> reject_rbl_client zen.spamhaus.org
You definitely should not apply Zen to your own users.
> reject_rbl_client bl.spamcop.net
I wouldn't use Spamcop like this. I use it with a low score in
postscreen.
> reject_rbl_client cbl.abuseat.org
This is included in Zen and now hosted by Spamhaus, wasted lookup.
> reject_rbl_client dnsbl.njabl.org
NJABL is no more.
> reject_rbl_client dnsbl.sorbs.net
I wouldn't use SORBS like this. I use it with a low score in
postscreen.
> reject_rhsbl_sender dsn.rfc-ignorant.org
RFC-ignorant.org is long gone. Don't use random DNSBLs/RHSBLs without
becoming familiar with them and their policies.
> reject_rhsbl_sender blackhole.securitysage.com
Yikes, this one looks like a wildcard! I don't know what happened to
securitysage.com, but I suspect it is not under the control of the
original registrant.
> An extra pair of eyes that could confirm things look good and
> things are as "locked down" as possible (both in terms of relaying
> *and* dealing with blacklisted IPs) would be greatly appreciated.
Consider postscreen, as I said, and Stan's fcrdns.pcre, as I bet he
said.
http://www.postfix.org/POSTSCREEN_README.html
http://rob0.nodns4.us/postscreen.html
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
