On 07/13/16 01:52, Bill Cole wrote: > On 12 Jul 2016, at 15:44, Phil Stracchino wrote: >> I'm trying to. :) > > Well, the choices for how to do that are many. Probably the simplest way > to do it is with a "policy daemon" and the pypolicyd-spf implementation > is the purest up-to-date SPF enforcement tool in that class.
I will definitely investigate that recommendation then. Thanks. > Other options: there are other more comprehensive policy daemons, you > can do SPF checks with amavisd-new, or if you're a Perl weenie like me > you can install MIMEDefang and either implement SPF checks through one > of the available Perl modules in filter_sender() or let SpamAssassin > handle it. I'm not actually using amavisd or spamassassin (I've been using DSpam, which has historically performed very well for me, though I may have to switch to spamassassin because DSpam is abandoned and becoming increasingly difficult to maintain). So pypolicyd-spf sounds like the way to go at the moment. >> I considered that option, yes. I ... could have sworn I *was* using >> the Zen RBL, actually. It looks as though I took it out for some >> reason >> at some time in the past and never restored it. > > I strongly recommend it. If you want fine-grained control over which > parts you use, you can select which return codes to look for. In my > case, I use these as part of my smtpd_recipient_restrictions list: I will take that recommendation too, especially since I don't remember why I stopped using it in the first place. >> I haven't deployed postscreen yet, as I simply don't know enough about >> it. > > It's designed for doing the simplest and most numerous spam rejections > with the least effort. Its best features are the greeting delay, which > catches many of the most aggressively obnoxious bots, and the ability to > use multiple DNSBLs and DNSWLs in a scoring configuration. ~90% of the > rejections my personal mail system does are by postscreen, and I don't > believe it has ever made a mistake in rejecting a would-be sender. > That's with ONLY the DNSBL and PREGREET functions enabled. Obviously > everything else I do to keep the spam out is marginal in comparison... I will definitely have to make time to investigate that as well then. One thing I USED to do back when I was running an OpenBSD firewall box was reject incoming connections to port 25 from Windows hosts. Any legitimate mail coming directly from a Windows machine would fall back to my MX relay. It stopped a LOT of botnet spam. I don't imagine there's any way to do that with Postfix though, and there doesn't seem to be a way to do ut ising netfilter/shorewall on my current firewall, which is a Ubiquiti embedded appliance. > 1st note: You have a lot of explicitly set parameters that simply > replicate defaults. That's not harmful per se, but it adds noise to > postconf -n. The ones I found trivially are: [...] > So you can reduce clutter in main.cf and postconf -n by removing the > explicit setting of those. There are likely others. So noted, and cleaned up those. I'll check through and see if I can spot any others, with the reservation that in some cases I've left the default explicitly set as a reminder to myself of what the default *is*. >> smtpd_client_restrictions = permit_mynetworks > > Noise. There's no need to define any of the smtpd_*_restrictions lists > if the definition only includes a sequence of conditions that are going > to show up in logically later ones. Hm, don't think I'd been aware of that. >> smtpd_helo_restrictions = reject_invalid_hostname >> reject_unknown_reverse_client_hostname pcre:/etc/postfix/helo.pcre > > I cannot make sense of the dangling map reference at the end. Perhaps > you want 'check_helo_access' before it? I would expect an error to be > logged about this. Totally right. I'm not sure how I munged that. I only added that the other day, trying to defeat the forged local sender problem. > Also: it seems that you've been using Postfix longer than me. :) The > 'new' name for "reject_invalid_hostname" is > "reject_invalid_helo_hostname" because there are too many nuances in > email jargon... Non-critical to change it, but doing so may save you a > 'man 5 postconf' next year or later. Thanks. :) Good catch, I wasn't aware of that change. > Also, consider putting all of that in smtpd_recipient_restrictions > instead, after permit_mynetworks. reject_invalid_helo_hostname can go in smtpd_recipient_restrictions? >> smtpd_milters = inet:localhost:8891 > > Presumably opendkim? Yup. I'll have to study the docs (and possibly ask on the opendkim list) on how to have opendkim sign only *outgoing* mail. I hadn't actually looked closely enough to see that it was signing incoming mail as well. Though possibly the forged sender was tricking it. >> smtpd_recipient_restrictions = permit_mynetworks > smtpd_recipient_restrictions = > permit_mynetworks,reject_unauth_destination, > > reject_unknown_reverse_client_hostname,reject_invalid_helo_hostname, > check_helo_access pcre:/etc/postfix/helo.pcre, > reject_unknown_sender_domain,reject_non_fqdn_sender, > check_sender_access btree:/etc/postfix/block-local-sender ...And then remove the settings from smtp_sender_restrictions that are now duplicated in the expanded smtpd_recipient_restrictions list? > Also, it is quite safe to add: > > smtpd_data_restrictions = > reject_multi_recipient_bounce,reject_unauth_pipelining,permit > > Those will not catch much which won't be caught by Zen and/or > postscreen's PREGREET check, but they are non-zero and extremely safe. I didn't know about that setting. Thanks again. >> unknown_client_reject_code = 450 > > If you're sticking with reject_unknown_reverse_client_hostname only > (which I'd recommend) you can change this safely to 550 (and in my > opinion should, on a 'fail fast' principle.) I'm not actually sure why I had that set to 450. Might have been a testing setting that I forgot. -- Phil Stracchino Babylon Communications [email protected] [email protected] Landline: 603.293.8485
