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.)
