Discussion:
This ought to be simple to stop. Am I missing something?
(too old to reply)
Phil Stracchino
2016-07-12 13:14:02 UTC
Permalink
I'm getting spam leaking through from sites with non-resolving IP or
invalid DNS, sending mail to myself as me. Here's an example:


Jul 12 08:03:52 minbar postfix/smtpd[17824]: warning: hostname
static.vnpt.vn does not resolve to address 14.167.212.244
Jul 12 08:03:52 minbar postfix/smtpd[17824]: connect from
unknown[14.167.212.244]
Jul 12 08:03:53 minbar postfix/smtpd[17824]: 4F5D74037FB5B:
client=unknown[14.167.212.244]
Jul 12 08:03:53 minbar postfix/cleanup[17827]: 4F5D74037FB5B:
message-id=<003601d1dc70$06d04a92$***@dveov>
Jul 12 08:03:53 minbar opendkim[4236]: 4F5D74037FB5B: external host
[14.167.212.244] attempted to send as caerllewys.net
Jul 12 08:03:53 minbar postfix/qmgr[15588]: 4F5D74037FB5B:
from=<***@caerllewys.net>, size=2201, nrcpt=1 (queue active)
Jul 12 08:03:54 minbar postfix/pickup[16696]: 018314037FB5D: uid=1666
from=<***@caerllewys.net>
Jul 12 08:03:54 minbar postfix/cleanup[17827]: 018314037FB5D:
message-id=<003601d1dc70$06d04a92$***@dveov>
Jul 12 08:03:54 minbar postfix/pipe[17828]: 4F5D74037FB5B:
to=<***@caerllewys.net>, relay=dspam, delay=0.69,
delays=0.66/0.01/0/0.02, dsn=2.0.0, status=sent (delivered via dspam
service)
Jul 12 08:03:54 minbar postfix/qmgr[15588]: 4F5D74037FB5B: removed
Jul 12 08:03:54 minbar opendkim[4236]: 018314037FB5D: DKIM-Signature
field added (s=dkim, d=caerllewys.net)
Jul 12 08:03:54 minbar postfix/qmgr[15588]: 018314037FB5D:
from=<***@caerllewys.net>, size=2321, nrcpt=1 (queue active)
Jul 12 08:03:54 minbar postfix/local[17843]: 018314037FB5D:
to=<***@caerllewys.net>, relay=local, delay=0.05,
delays=0.04/0.01/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
Jul 12 08:03:54 minbar postfix/qmgr[15588]: 018314037FB5D: removed
Jul 12 08:03:54 minbar postfix/smtpd[17824]: disconnect from
unknown[14.167.212.244] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5


I have the following helo and sender restrictions in place:

smtpd_helo_restrictions = reject_invalid_hostname
reject_unknown_sender_domain
reject_non_fqdn_sender
reject_unknown_reverse_client_hostname

smtpd_sender_restrictions = permit_mynetworks
reject_invalid_hostname
reject_unknown_sender_domain
reject_non_fqdn_sender


OpenDKIM is picking up that 14.167.212.244 is falsely trying to send
mail as caerllewys.net, but Postfix is letting it happen. I just added
a pcre restriction to smtpd_helo_restrictions to refuse any host trying
to HELO as 'caerllewys.net', though I haven't had time yet to see
whether it works, 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.

Am I missing something that should be obvious?
--
Phil Stracchino
Babylon Communications
***@caerllewys.net
***@co.ordinate.org
Landline: 603.293.8485
Wietse Venema
2016-07-12 13:40:46 UTC
Permalink
Post by Phil Stracchino
smtpd_sender_restrictions =
permit_mynetworks
permit_tls_clientcerts
permit_sasl_authenticated
Post by Phil Stracchino
reject_invalid_hostname
reject_unknown_sender_domain
reject_non_fqdn_sender
check_sender_access hash:/etc/postfix/block-local-sender

/etc/postfix/block-local-sender:
example.com REJECT local sender address is not allowed
someone-***@example.com PERMIT

This is a crude way to block a local sender address in remote email.

Wietse
Bill Cole
2016-07-12 14:30:21 UTC
Permalink
Post by Phil Stracchino
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"

It's more than slightly hypocritical to publish a "-all" SPF record when
you don't pay attention to it yourself. There are a wide variety of
tools that can be used to enforce SPF in various ways. I use
SpamAssassin (via MIMEDefang, which isn't important) because SA has a
deep capacity to deal with the fact that SPF records are often not worth
anything for a variety of reasons, including domain owners who don't
understand what "-all" should mean in principle. There are also
free-standing milters and policy daemons available for SPF enforcement.

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.

In addition, you should split initial mail submission from inbound
transport and (if you do any...) intermediary relay of mail. Putting a
submission service on port 587 removes the need to make your port 25
smtpd configuration allow for both types of handling.
Post by Phil Stracchino
Jul 12 08:03:52 minbar postfix/smtpd[17824]: warning: hostname
static.vnpt.vn does not resolve to address 14.167.212.244
Jul 12 08:03:52 minbar postfix/smtpd[17824]: connect from
unknown[14.167.212.244]
client=unknown[14.167.212.244]
Jul 12 08:03:53 minbar opendkim[4236]: 4F5D74037FB5B: external host
[14.167.212.244] attempted to send as caerllewys.net
Jul 12 08:03:54 minbar postfix/pickup[16696]: 018314037FB5D: uid=1666
delays=0.66/0.01/0/0.02, dsn=2.0.0, status=sent (delivered via dspam
service)
Jul 12 08:03:54 minbar postfix/qmgr[15588]: 4F5D74037FB5B: removed
Jul 12 08:03:54 minbar opendkim[4236]: 018314037FB5D: DKIM-Signature
field added (s=dkim, d=caerllewys.net)
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...
Post by Phil Stracchino
delays=0.04/0.01/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
Jul 12 08:03:54 minbar postfix/qmgr[15588]: 018314037FB5D: removed
Jul 12 08:03:54 minbar postfix/smtpd[17824]: disconnect from
unknown[14.167.212.244] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
smtpd_helo_restrictions = reject_invalid_hostname
reject_unknown_sender_domain
reject_non_fqdn_sender
reject_unknown_reverse_client_hostname
smtpd_sender_restrictions = permit_mynetworks
reject_invalid_hostname
reject_unknown_sender_domain
reject_non_fqdn_sender
You've been here long enough to have seen this request before:

Please provide 'postconf -n' output as described in the last section of
Postfix's DEBUG_README file.

The above snippets do not draw a full enough picture of your config to
offer a proper specific fix. However, IN GENERAL, you should avoid
duplicating 'reject_*' settings in different restriction lists unless
you have a concrete reason to do that. It is also pointless to put
sender restrictions in smtpd_helo_restrictions.
Post by Phil Stracchino
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.
Post by Phil Stracchino
but Postfix is letting it happen. I just added
a pcre restriction to smtpd_helo_restrictions to refuse any host
trying
to HELO as 'caerllewys.net', though I haven't had time yet to see
whether it works,
It almost surely will not in this case, but that is not a bad choice. I
see no indication that this spambot is HELO'ing with your name, but some
will.
Post by Phil Stracchino
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".
You should also have distinct SMTP and initial submission services, so
that you can more tightly control who claims to be you and what mail
Postfix hands to OpenDKIM for signing.
Post by Phil Stracchino
Am I missing something that should be obvious?
Yes: DEBUG_README.
Phil Stracchino
2016-07-12 19:44:05 UTC
Permalink
Post by Bill Cole
Post by Phil Stracchino
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.
caerllewys.net. 259200 IN TXT "v=spf1 ip4:216.246.132.90 -all"
I'm trying to. :)
Post by Bill Cole
It's more than slightly hypocritical to publish a "-all" SPF record when
you don't pay attention to it yourself. There are a wide variety of
tools that can be used to enforce SPF in various ways. I use
SpamAssassin (via MIMEDefang, which isn't important) because SA has a
deep capacity to deal with the fact that SPF records are often not worth
anything for a variety of reasons, including domain owners who don't
understand what "-all" should mean in principle. There are also
free-standing milters and policy daemons available for SPF enforcement.
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 haven't deployed postscreen yet, as I simply don't know enough about
it. 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.
Post by Bill Cole
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.
Post by Bill Cole
Please provide 'postconf -n' output as described in the last section of
Postfix's DEBUG_README file.
The above snippets do not draw a full enough picture of your config to
offer a proper specific fix. However, IN GENERAL, you should avoid
duplicating 'reject_*' settings in different restriction lists unless
you have a concrete reason to do that. It is also pointless to put
sender restrictions in smtpd_helo_restrictions.
Good point. I plead tiredness when I tried that change. Just removed
those.
Post by Bill Cole
Post by Phil Stracchino
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.
Post by Bill Cole
Post by Phil Stracchino
[...] 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.


access_map_reject_code = 553
alias_database = btree:/etc/postfix/aliases
btree:/var/lib/mailman/data/aliases
alias_maps = btree:/etc/postfix/aliases btree:/var/lib/mailman/data/aliases
allow_untrusted_routing = no
command_directory = /usr/sbin
compatibility_level = 2
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
default_database_type = btree
default_destination_concurrency_limit = 10
fast_flush_domains = $relay_domains
header_checks = pcre:/etc/postfix/smtp_header_checks
regexp:/etc/postfix/header_checks
html_directory = /usr/share/doc/postfix-3.1.1/html
in_flow_delay = 0
inet_interfaces = all
inet_protocols = ipv4
invalid_hostname_reject_code = 501
local_destination_concurrency_limit = 2
local_recipient_maps = unix:passwd.byname $alias_maps
mail_owner = postfix
mail_spool_directory = /var/spool/mail
mail_version = 3.1.1
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maps_rbl_reject_code = 553
message_size_limit = 40960000
meta_directory = /etc/postfix
milter_default_action = tempfail
mydestination = $myhostname localhost.$mydomain $mydomain
mydomain = caerllewys.net
myhostname = smtp.caerllewys.net
mynetworks = 127.0.0.0/8 10.24.32.0/24 10.24.33.0/24 10.24.34.0/24
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases
non_smtpd_milters = inet:localhost:8891
parent_domain_matches_subdomains = debug_peer_list fast_flush_domains
mynetworks permit_mx_backup_networks qmqpd_authorized_clients
relay_domains smtpd_access_maps
qmqpd_authorized_clients = $mynetworks $relay_domains
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-3.1.1-r1/readme
recipient_delimiter = +
reject_code = 550
relay_domains = $mydestination novylen.net flambe.org myschyf.net
thegaminghall.com toontownhall.com freerealmsforums.com
downwardspiral.net third-design.net
relay_domains_reject_code = 553
relay_recipient_maps = btree:/etc/postfix/relay_recipients
relay_transport = relay
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
shlib_directory = /usr/lib64/postfix/${mail_version}
smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
smtpd_client_restrictions = permit_mynetworks
smtpd_error_sleep_time = 5
smtpd_hard_error_limit = 5
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_hostname
reject_unknown_reverse_client_hostname pcre:/etc/postfix/helo.pcre
smtpd_milters = inet:localhost:8891
smtpd_recipient_limit = 40
smtpd_recipient_restrictions = permit_mynetworks
reject_unauth_destination reject_unknown_reverse_client_hostname
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
smtpd_soft_error_limit = 10
smtpd_tls_cert_file = /etc/postfix/cert-20160508-183210.pem
smtpd_tls_key_file = /etc/postfix/key-20160508-183210.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtputf8_enable = yes
soft_bounce = no
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
transport_maps = btree:/etc/postfix/transport
unknown_address_reject_code = 551
unknown_client_reject_code = 450
unknown_hostname_reject_code = 550
unknown_local_recipient_reject_code = 550
--
Phil Stracchino
Babylon Communications
***@caerllewys.net
***@co.ordinate.org
Landline: 603.293.8485
Bill Cole
2016-07-13 05:52:50 UTC
Permalink
Post by Phil Stracchino
Post by Bill Cole
Post by Phil Stracchino
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.
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.

[...]
Post by Phil Stracchino
Post by Bill Cole
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)
Post by Phil Stracchino
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...
Post by Phil Stracchino
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.
Post by Bill Cole
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.
[...]
Post by Phil Stracchino
Post by Bill Cole
Post by Phil Stracchino
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.
Post by Phil Stracchino
Post by Bill Cole
Post by Phil Stracchino
[...] 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.

[...]
Post by Phil Stracchino
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.
Post by Phil Stracchino
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.
Post by Phil Stracchino
smtpd_milters = inet:localhost:8891
Presumably opendkim?
Post by Phil Stracchino
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...)
Post by Phil Stracchino
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.
Post by Phil Stracchino
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.)
l***@lazygranch.com
2016-07-13 06:54:38 UTC
Permalink
‎Hopefully this won't be interpreted as thread hijacking, but can you elaborate of this?
-------
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)‎
---------

So I gather some element of "zen" are not to your liking? That is, if you didn't specify the return codes, zen would do all of the above and more.

The Spamhaus write up on snow shoe spam is certainly interesting. 
L.P.H. van Belle
2016-07-13 06:55:54 UTC
Permalink
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-----
Verzonden: woensdag 13 juli 2016 7:53
Onderwerp: Re: This ought to be simple to stop. Am I missing something?
Post by Phil Stracchino
Post by Bill Cole
Post by Phil Stracchino
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.
caerllewys.net. 259200 IN TXT "v=spf1
ip4:216.246.132.90 -all"
Post by Phil Stracchino
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.
[...]
Post by Phil Stracchino
Post by Bill Cole
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
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)
Post by Phil Stracchino
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...
Post by Phil Stracchino
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.
Post by Bill Cole
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.
[...]
Post by Phil Stracchino
Post by Bill Cole
Post by Phil Stracchino
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.
Post by Phil Stracchino
Post by Bill Cole
Post by Phil Stracchino
[...] 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
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.
[...]
Post by Phil Stracchino
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.
Post by Phil Stracchino
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.
Post by Phil Stracchino
smtpd_milters = inet:localhost:8891
Presumably opendkim?
Post by Phil Stracchino
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...)
Post by Phil Stracchino
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
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
# 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)
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.
Post by Phil Stracchino
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.)
j***@gmail.com
2016-07-15 15:20:49 UTC
Permalink
Post by L.P.H. van Belle
A good combination of rbl lists with postscreen im using.
postscreen_dnsbl_threshold=4
postscreen_dnsbl_sites =
...
fresh.spameatingmonkey.net*2
...
How is fresh.sem working out for you? http://spameatingmonkey.com/lists.html

-Jim P.

Benny Pedersen
2016-07-13 09:36:20 UTC
Permalink
Post by L.P.H. van Belle
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
last time it was tryed here bind9 says lame-servers to some of them, so
if see this then dont use them

the good part here is postscreen sadly many of the above needs datafeeds
to be stable
Benny Pedersen
2016-07-13 09:39:33 UTC
Permalink
Post by l***@lazygranch.com
So I gather some element of "zen" are not to your liking? That is, if
you didn't specify the return codes, zen would do all of the above and
more.
each of them can hit independly, eq some ips is listed multiplaces

so postscreen score would not be the same
L.P.H. van Belle
2016-07-13 09:41:12 UTC
Permalink
Then stop using google dns or other dns servers
that block dns request to rbl servers.
Source : https://www.spamhaus.org/faq/section/DNSBL%20Usage

Check what DNS resolvers you are using: If you are using a free "open DNS resolver" service such as the Google Public DNS or large cloud/outsourced public DNS servers, such as Level3's or Verizon's, to resolve your DNSBL requests, in most cases you will receive a "not listed" (NXDOMAIN) reply from Spamhaus' public DNSBL servers. We recommend using your own DNS servers when doing DNSBL queries to Spamhaus.


I no lame servers in my bind logs.
The set below is running over 1 year now, without any problems.


Greetz,

Louis
-----Oorspronkelijk bericht-----
Pedersen
Verzonden: woensdag 13 juli 2016 11:36
Onderwerp: Re: This ought to be simple to stop. Am I missing something?
Post by L.P.H. van Belle
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
last time it was tryed here bind9 says lame-servers to some of them, so
if see this then dont use them
the good part here is postscreen sadly many of the above needs datafeeds
to be stable
Benny Pedersen
2016-07-13 09:47:32 UTC
Permalink
Post by L.P.H. van Belle
recommend using your own DNS servers when doing DNSBL queries to
Spamhaus.
using ::1 here i dont trust others
Post by L.P.H. van Belle
I no lame servers in my bind logs.
The set below is running over 1 year now, without any problems.
bind9 default dont log lame-servers, since there is none that if enabled
will fill logs pretty fast and it will drop bind9 performance aswell
L.P.H. van Belle
2016-07-13 09:56:06 UTC
Permalink
here your have an bind log example, WITH lame server logging.
Adjust where needed.

Just enable only lameserver logging.
Set all to null and enable lameserver logging.
No performance drop.

logging {
channel bind_log {
file "/var/log/bind/bind.log" versions 3 size 1m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
channel query_log {
file "/var/log/bind/query.log" size 1m;
// Set the severity to dynamic to see all the debug messages.
severity debug 3;
};
channel update_debug {
file "/var/log/bind/update_debug.log" versions 3 size 100k;
severity debug;
print-severity yes;
print-time yes;
};
channel security_info {
file "/var/log/bind/security_info.log" versions 1 size 100k;
severity info;
print-severity yes;
print-time yes;
};
channel xfer_log {
file "/var/log/bind/xfer.log" size 1m;
print-category yes;
print-severity yes;
print-time yes;
severity info;
};

channel unmatched_log {
file "/var/log/bind/unmatched.log" size 1m;
print-category yes;
print-severity yes;
print-time yes;
severity info;
};

channel lameservers_log {
file "/var/log/bind/lameservers.log" size 1m;
print-category yes;
print-severity yes;
print-time yes;
severity info;
};

category default { bind_log; };
category lame-servers { lameservers_log; };
category update { update_debug; };
category update-security { update_debug; };
category security { security_info; };
category queries { query_log; };
//category unmatched { unmatched_log; };
category xfer-in { xfer_log; };
category xfer-out { xfer_log; };

// No logging at all ..
// category default { null; };

};
-----Oorspronkelijk bericht-----
Pedersen
Verzonden: woensdag 13 juli 2016 11:48
Onderwerp: Re: This ought to be simple to stop. Am I missing something?
Post by L.P.H. van Belle
recommend using your own DNS servers when doing DNSBL queries to
Spamhaus.
using ::1 here i dont trust others
Post by L.P.H. van Belle
I no lame servers in my bind logs.
The set below is running over 1 year now, without any problems.
bind9 default dont log lame-servers, since there is none that if enabled
will fill logs pretty fast and it will drop bind9 performance aswell
Benny Pedersen
2016-07-13 11:18:35 UTC
Permalink
Post by L.P.H. van Belle
here your have an bind log example, WITH lame server logging.
Adjust where needed.
logging {
channel default_log {
file "/var/log/named/named.log" versions 9 size 1M;
print-time yes;
print-severity yes;
print-category yes;
};

category default { default_log; };
category general { default_log; };
};

i have only the above

26-Jun-2016 07:53:24.062 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
26-Jun-2016 20:55:53.324 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 168.100.1.3#53
26-Jun-2016 20:55:53.945 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
27-Jun-2016 00:08:46.369 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
27-Jun-2016 01:20:09.482 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
27-Jun-2016 01:20:09.590 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 168.100.1.3#53
27-Jun-2016 02:29:09.732 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
27-Jun-2016 03:43:58.806 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
27-Jun-2016 06:18:26.299 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
27-Jun-2016 15:28:56.449 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
28-Jun-2016 07:16:36.493 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
28-Jun-2016 15:48:29.665 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
29-Jun-2016 02:32:58.281 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 168.100.1.3#53
29-Jun-2016 02:32:58.349 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
29-Jun-2016 09:59:43.474 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
29-Jun-2016 21:07:58.956 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
29-Jun-2016 21:07:59.026 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
30-Jun-2016 06:32:03.605 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 168.100.1.3#53
01-Jul-2016 04:32:07.408 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
01-Jul-2016 08:48:15.474 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
01-Jul-2016 10:02:22.506 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
01-Jul-2016 13:45:54.584 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
01-Jul-2016 13:45:55.588 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
01-Jul-2016 18:20:13.819 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 168.100.1.3#53
01-Jul-2016 18:20:13.887 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
02-Jul-2016 03:22:45.031 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
02-Jul-2016 04:28:20.981 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
02-Jul-2016 04:28:21.055 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 168.100.1.3#53
02-Jul-2016 19:56:18.759 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
02-Jul-2016 23:34:16.631 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
03-Jul-2016 05:05:21.607 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
03-Jul-2016 16:35:46.833 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 168.100.1.3#53
03-Jul-2016 22:20:58.588 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
03-Jul-2016 23:21:23.438 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
04-Jul-2016 02:51:53.104 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
04-Jul-2016 11:26:57.156 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
04-Jul-2016 11:26:57.232 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
04-Jul-2016 18:10:26.131 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 168.100.1.3#53
04-Jul-2016 18:10:26.201 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
04-Jul-2016 19:47:39.232 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 168.100.1.3#53
04-Jul-2016 19:48:10.295 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
04-Jul-2016 23:49:13.318 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
05-Jul-2016 02:32:33.143 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
05-Jul-2016 12:16:43.269 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
05-Jul-2016 15:55:39.545 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 168.100.1.3#53
06-Jul-2016 13:47:35.071 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
06-Jul-2016 18:29:08.970 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
06-Jul-2016 18:29:10.389 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
06-Jul-2016 23:47:21.442 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
07-Jul-2016 08:18:10.210 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
07-Jul-2016 11:14:46.163 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
07-Jul-2016 16:36:23.552 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
07-Jul-2016 18:04:40.485 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
07-Jul-2016 18:04:40.555 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
07-Jul-2016 20:35:31.047 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
09-Jul-2016 03:10:28.635 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
09-Jul-2016 18:41:02.140 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 168.100.1.3#53
11-Jul-2016 07:59:14.721 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 2604:8d00:0:1::3#53
11-Jul-2016 07:59:14.806 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 168.100.1.3#53
11-Jul-2016 14:27:45.933 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
11-Jul-2016 16:27:26.513 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
11-Jul-2016 18:00:04.908 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
11-Jul-2016 21:40:46.352 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
11-Jul-2016 21:40:46.429 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53
12-Jul-2016 00:28:26.878 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
12-Jul-2016 14:14:44.204 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 168.100.1.3#53
12-Jul-2016 14:14:45.952 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
13-Jul-2016 04:39:28.497 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
13-Jul-2016 06:53:20.466 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/MX/IN': 168.100.1.3#53
13-Jul-2016 06:53:21.304 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/TXT/IN': 2604:8d00:0:1::3#53
13-Jul-2016 09:49:55.577 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 2604:8d00:0:1::3#53
13-Jul-2016 10:56:32.600 lame-servers: info: REFUSED unexpected RCODE
resolving 'postfix.org/NS/IN': 168.100.1.3#53

i can still recieve mails from postfix.org, so its possible just
temporary ?
Bill Cole
2016-07-13 13:42:20 UTC
Permalink
Post by l***@lazygranch.com
‎Hopefully this won't be interpreted as thread hijacking, but can
you elaborate of this?
-------
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)‎
---------
So I gather some element of "zen" are not to your liking?
No. Those are all of the documented return codes currently in use.

To be clear: I cannot imagine a circumstance where I would say: "I don't
think Steve Linford's judgment can be trusted with this." I know he's
not the sole operator of Spamhaus these days, but he's one of the few
people I've dealt with professionally who I trust so fully that I extend
that trust to the team and processes he has built for Spamhaus.
Post by l***@lazygranch.com
That is, if you didn't specify the return codes, zen would do all of
the above and more.
I don't believe that to be true. See these pages:

https://www.spamhaus.org/zen/
https://www.spamhaus.org/faq/section/Spamhaus%20XBL#136

I expect that if and when Spamhaus brings a new class of listing into
Zen and assigns it a new code, I will hear about it quite near the
launch and add it to the systems I manage immediately.

HOWEVER: in the history of DNSBLs there have been a number of cases
where technical or psychological glitches have caused a DNSBL to
effectively list the whole IPv4 space, sometimes with wild return codes.
Until Spamhaus clearly *intentionally* uses other return codes, I will
not treat them as meaningful. I trust Steve, his team, and their
processes, but I do not trust the universe to not toss up a bit of chaos
in random places like DNSBLs from time to time.
Post by l***@lazygranch.com
The Spamhaus write up on snow shoe spam is certainly interesting. 
Yes. They were really the first anti-spam organization to notice the
snowshoe mechanism as a defining characteristic of a distinct class of
spammer in between the purely criminal botnet spammers and the nominally
legitimate sorts who can be handled by the SBL-style (or MAPS RBL-style,
if you're old enough...) human-vetted DNSBL.
Phil Stracchino
2016-07-13 13:50:38 UTC
Permalink
Post by Bill Cole
Post by Phil Stracchino
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.
Post by Bill Cole
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.
Post by Bill Cole
Post by Phil Stracchino
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
I will take that recommendation too, especially since I don't remember
why I stopped using it in the first place.
Post by Bill Cole
Post by Phil Stracchino
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.
Post by Bill Cole
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
[...]
Post by Bill Cole
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*.
Post by Bill Cole
Post by Phil Stracchino
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.
Post by Bill Cole
Post by Phil Stracchino
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.
Post by Bill Cole
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.
Post by Bill Cole
Also, consider putting all of that in smtpd_recipient_restrictions
instead, after permit_mynetworks.
reject_invalid_helo_hostname can go in smtpd_recipient_restrictions?
Post by Bill Cole
Post by Phil Stracchino
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.
Post by Bill Cole
Post by Phil Stracchino
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?
Post by Bill Cole
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.
Post by Bill Cole
Post by Phil Stracchino
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
***@caerllewys.net
***@co.ordinate.org
Landline: 603.293.8485
Bill Cole
2016-07-13 15:34:13 UTC
Permalink
[...]
Post by Phil Stracchino
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.
I think the world has largely moved beyond that being useful. Microsoft
is actually using Exchange for their free and cheap mail hosting these
days and doing so in a very big way, and there are botnets of shoddy
Linux machines. Those include at least one that sustains itself by
exploiting BusyBox (i.e. embedded Linux) flaws. We live in a world of
small routers, firewalls, lightbulbs, doorbells, and refrigerators
sending spam.... YAY!
Post by Phil Stracchino
Post by Bill Cole
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
[...]
Post by Bill Cole
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*.
I get that, and it also has the tangible benefit of nailing down
defaults that you depend on not being changed by Wietse (rare and almost
never wrong) or an intermediary packager (less rare, less consistently
right.)
Post by Phil Stracchino
Post by Bill Cole
Post by Phil Stracchino
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.
Well, I understand it to be an innovation somewhere near v2... :)

[...]
Post by Phil Stracchino
Post by Bill Cole
Also, consider putting all of that in smtpd_recipient_restrictions
instead, after permit_mynetworks.
reject_invalid_helo_hostname can go in smtpd_recipient_restrictions?
Yes. This has been true for at least as long as Postfix has had milter
support (which is when I tossed Sendmail aside for anything other than
than null-client and completely insane rigs involving hand-built
cf-ese.) Like I said above, I think this was a v2 innovation.

There are corner cases where particular needs make it helpful to put
logically early restrictions and permissions into the client/helo/sender
lists but the side effects can be subtle and non-intuitive. By default
(i.e. with smtpd_delay_reject=yes) all of the smtpd restriction lists
are evaluated in order at RCPT time, with PERMIT results from early
lists being effectively DUNNO results. See the SMTPD_ACCESS_README file
for details and examples of where you might want to make use of multiple
lists vs. putting all client/ehlo/sender directives in
smtpd_recipient_restrictions.
Post by Phil Stracchino
Post by Bill Cole
Post by Phil Stracchino
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.
Post by Bill Cole
Post by Phil Stracchino
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?
Yes. Note that ordering becomes critical when collapsing everything into
smtpd_recipient_restrictions because a PERMIT from any directive in a
restriction list causes a message to bypass later directives in that
list. It is not inherently better or worse to split up the directives
between lists but with the ones you are using, it should work correctly
and avoids duplication of directives in multiple lists.
Post by Phil Stracchino
Post by Bill Cole
Post by Phil Stracchino
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.
It's also duplicative of the default setting. Using 450 makes sense as a
default IF you use the more aggressive and accident-prone
reject_unknown_client_hostname. Since that restriction relies on DNS
coordination of 2 zones that may not have a common administrative
authority, it is more likely to "catch" on temporary mistakes that are
resolved within the retry lifetime of a legitimate message.
Phil Stracchino
2016-07-13 19:14:51 UTC
Permalink
Post by Bill Cole
Post by Phil Stracchino
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.
I think the world has largely moved beyond that being useful. Microsoft
is actually using Exchange for their free and cheap mail hosting these
days and doing so in a very big way, and there are botnets of shoddy
Linux machines. Those include at least one that sustains itself by
exploiting BusyBox (i.e. embedded Linux) flaws. We live in a world of
small routers, firewalls, lightbulbs, doorbells, and refrigerators
sending spam.... YAY!
Agreed, it's no longer really a useful strategem anyway. So I haven't
tried too hard to figure out a way to re-implement it.
Post by Bill Cole
Post by Phil Stracchino
...And then remove the settings from smtp_sender_restrictions that are
now duplicated in the expanded smtpd_recipient_restrictions list?
Yes. Note that ordering becomes critical when collapsing everything into
smtpd_recipient_restrictions because a PERMIT from any directive in a
restriction list causes a message to bypass later directives in that
list. It is not inherently better or worse to split up the directives
between lists but with the ones you are using, it should work correctly
and avoids duplication of directives in multiple lists.
That would make sense. Early PERMITs only where you want them to be
unconditionally accepted regardless of other conditions.
Post by Bill Cole
Post by Phil Stracchino
Post by Bill Cole
Post by Phil Stracchino
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.
It's also duplicative of the default setting. Using 450 makes sense as a
default IF you use the more aggressive and accident-prone
reject_unknown_client_hostname. Since that restriction relies on DNS
coordination of 2 zones that may not have a common administrative
authority, it is more likely to "catch" on temporary mistakes that are
resolved within the retry lifetime of a legitimate message.
Noted. Makes sense.
--
Phil Stracchino
Babylon Communications
***@caerllewys.net
***@co.ordinate.org
Landline: 603.293.8485
Phil Stracchino
2016-07-14 03:16:14 UTC
Permalink
pypolicyd-spf installed and working. Studying the postscreen docs now...
--
Phil Stracchino
Babylon Communications
***@caerllewys.net
***@co.ordinate.org
Landline: 603.293.8485
Continue reading on narkive:
Loading...