On Fri, May 31, 2013 at 8:09 AM, /dev/rob0 <r...@gmx.co.uk> wrote: > 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.)
Thanks for the tip. This is a good idea that I just attempted to implement based on some reading / research. Forgive the lack of knowledge in this particular field -- like your postscreen readme indicated, I'm attempting to walk before I run. :) Any gentle guidance on things to improve in this master.cf snippet would be definitely appreciated and humbly accepted. -->8-- submission inet n - - - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt smtps inet n - - - - smtpd -o syslog_name=postfix/smtps --8<-- Look good? > [ 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. Yes, you're right. I suppose I found these deprecated syntaxes in some reading material and didn't look them up to confirm. > >> 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! Can you please clarify? I omitted permit_* restrictions because I didn't think that they were necessary if a message passed all of the reject restrictions. Should I be explicitly defining a permit? If so, where and why? > >> 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 Thank you for the detailed response. I will take a look at both and follow up with any further questions about fcrdns.pcre or postscreen if needed.
