A good combination of rbl lists with postscreen im using.
postscreen_dnsbl_threshold=4
postscreen_dnsbl_sites =
b.barracudacentral.org*4
bad.psky.me*4
zen.spamhaus.org*4
dnsbl.cobion.com*2
bl.spameatingmonkey.net*2
fresh.spameatingmonkey.net*2
dnsbl.anonmails.de*2
dnsbl.kempt.net*2
dnsbl.inps.de*2
bl.spamcop.net*2
dnsbl.sorbs.net*2
psbl.surriel.com*2
bl.mailspike.net*2
bl.suomispam.net*2
all.rbl.jp*2
swl.spamhaus.org*-4
basicly. If one of the servers is in barracuda spamhaus or psky
its always spam so i gave the the max (4).
If its a "new" domain name fresh.spameatingmonkey.net give 2.
And mostly one of the other gives also to if its really spam.
Works good here and espacialy with fail2ban
Using these filter/failregex
failregex = addr <HOST> listed by domain
client \[<HOST>\] blocked using multiple DNS-based blocklists
Which reduces cpu load and unneeded connections.
And if you use spamassassin
https://github.com/extremeshok/spamassassin-extremeshok_fromreplyto
but setting up dkim dmarc spf is recommended yes.
Greetz,
Louis
> -----Oorspronkelijk bericht-----
> Van: [email protected] [mailto:owner-postfix-
> [email protected]] Namens Bill Cole
> Verzonden: woensdag 13 juli 2016 7:53
> Aan: [email protected]
> Onderwerp: Re: This ought to be simple to stop. Am I missing something?
>
> On 12 Jul 2016, at 15:44, Phil Stracchino wrote:
>
> > On 07/12/16 10:30, Bill Cole wrote:
> >> On 12 Jul 2016, at 9:14, Phil Stracchino wrote:
> >>
> >>> I'm getting spam leaking through from sites with non-resolving IP or
> >>> invalid DNS, sending mail to myself as me.
> >>
> >> You COULD use reject_unknown_client_hostname but it has substantial
> >> false positives.
> >>
> >> More directly, you could enforce your own SPF record:
> >>
> >> caerllewys.net. 259200 IN TXT "v=spf1
> ip4:216.246.132.90 -all"
> >
> > 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.
>
> 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'd definitely choose pypolicyd-spf if I had noticeable quantities of
> this sort of crap making it to holistic filtering. SPF failure is
> actually decisive in so little mail that I see anywhere that I've not
> seen a need to push it to the top of the filtering heap.
>
> That's assuming you have a need to accept some mail claiming to be from
> addresses in your own domain via that service, which you may not if
> you've got a submission service set up. Based on the absence of any SASL
> settings in your postconf -n output, I'm guessing you have such a
> service, unless you rely entirely on source IP (i.e. permit_mynetworks)
> for relay control.
>
> [...]
> >> In this case it also appears that the IP address was in the CBL and
> >> hence SpamHaus Zen when you accepted it. Maybe not, but if you are
> >> not
> >> killing such IPs in postscreen you're going to have a lot of spam
> >> getting further in than it needs to. Also, if you're running a
> >> smallish
> >> mail system with a limited audience that does not include a need to
> >> communicate with Vietnamese correspondents, you can probably block
> >> all
> >> email traffic from 14.160.0.0/11.
> >
> > 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:
>
> reject_rbl_client zen.spamhaus.org=127.0.0.2,
> reject_rbl_client zen.spamhaus.org=127.0.0.3,
> reject_rbl_client zen.spamhaus.org=127.0.0.4,
> reject_rbl_client zen.spamhaus.org=127.0.0.10,
> reject_rbl_client zen.spamhaus.org=127.0.0.11,
>
> Those are, in order: SBL(chronic spam sources), CSS(snowshoers),
> CBL(spambots), PBL(ISP-designated dynamic), and PBL(Spamhaus-determined
> dynamic)
>
> > 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've been working on various additional services (including DKIM)
> > to try to tighten things up, but I have limited time to work on my own
> > stuff and - I admit - it tends to get attention mainly when something
> > is
> > obviously broken.
> >
> >
> >> Why are you signing mail that came from a random bot in Vietnam? If
> >> OpenDKIM can't be made to require authentication in order to sign
> >> mail,
> >> it is broken. I'm not familiar with it, so I expect you're just
> >> missing
> >> some setting that exists...
> >
> > Quite likely, yes. I'm fairly new to OpenDKIM and don't know all of
> > the
> > best practices for it yet. It certainly SHOULDN'T have been signing
> > it.
> [...]
> >>> OpenDKIM is picking up that 14.167.212.244 is falsely trying to send
> >>> mail as caerllewys.net,
> >>
> >> It doesn't seem to me like OpenDKIM is noticing any sort of falsity,
> >> since it claims to be adding a signature.
> >
> > Which is probably a configuration error on my part.
>
> I don't use it so I don't know what knob to turn, but if this is a pure
> MTA then the opendkim milter probably shouldn't be signing at all. Sign
> messages only in the submission service, verify only on the MTA.
>
> >>> [...] but surely there should be some straightforward
> >>> directive to tell Postfix not to allow a site outside of $mynetworks
> >>> to send me mail using my own email address as sender.
> >>
> >> Yes, there are such directives, and you're not showing the most
> >> suitable
> >> places for them.
> >>
> >> You should have smtpd_recipient_restrictions and maybe
> >> smtpd_relay_restrictions lists, one or both of which end with
> >> "reject".
> >
> > I'm quite possibly doing some checks in the wrong (or sub-optimal)
> > places. And it's been a while since I last read through the full
> > documentation, and I know I haven't kept up with changes.
> >
> > Postconf -n output follows; I'd appreciate any tips on errors I'm
> > making
> > or places where I could improve my configuration. There's always room
> > to learn more.
>
> 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:
>
> allow_untrusted_routing
> fast_flush_domains
> inet_interfaces
> invalid_hostname_reject_code
> local_destination_concurrency_limit
> mail_owner
> milter_default_action
> parent_domain_matches_subdomains
> relay_transport
> setgid_group
> smtpd_soft_error_limit
> soft_bounce
> tls_random_source
> unknown_client_reject_code
> unknown_local_recipient_reject_code
>
> So you can reduce clutter in main.cf and postconf -n by removing the
> explicit setting of those. There are likely others.
>
> [...]
> > 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.
>
> > 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.
>
> 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.
>
> Also, consider putting all of that in smtpd_recipient_restrictions
> instead, after permit_mynetworks.
>
> > smtpd_milters = inet:localhost:8891
>
> Presumably opendkim?
>
>
> > smtpd_recipient_restrictions = permit_mynetworks
> > reject_unauth_destination reject_unknown_reverse_client_hostname
>
> All fine, and a fine order, but I would suggest a consolidation (see
> above and below...)
>
> > smtpd_sender_restrictions = permit_mynetworks reject_invalid_hostname
> > reject_unknown_sender_domain reject_non_fqdn_sender
> > check_sender_access
> > btree:/etc/postfix/block-local-sender
>
> There's probably no reason not to merge this list and
> smtpd_helo_restrictions into one grand smtpd_recipient_restrictions
> list:
>
> 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
>
> CAVEAT: taking advice from me on this is worth what you pay for it, *at
> most*. Note that I go a bit "grander" myself:
>
> # postconf -f smtpd_recipient_restrictions|wc
> 26 59 1709
>
> Which includes 12 map checks, 11 DNSBL checks, and 7 simple of postfix's
> reject_* rules. (It's complicated)
>
> 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.
>
> > 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.)
