On 12/01/2019 11:43, John Fawcett wrote:
On 12/01/2019 12:09, Nick Howitt wrote:
Hi all,
Until recently I did not receive too much spam and had it pretty-much
under control. This week has gone mental. So far this week I have
received 29860 connection attempts form {some_random_number}@qq.com to
{the_same_random_number}@howitts.co.uk.

I have a mail server and two backup MX servers and most of the mail is
arriving via one of the backup servers. Some comes directly to me and
some comes via the other backup server.Because of my settings, none of
it can get through.

My postconf-n is:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
bounce_queue_lifetime = 6h
broken_sasl_auth_clients = yes
clearglassnetwork = 172.19.0.0/16
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = mailprefilter
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id & sleep 5
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/header_checks
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
local_recipient_maps = $alias_maps $virtual_alias_maps
luser_relay =
mail_owner = postfix
mailbox_size_limit = 102400000
mailbox_transport = mailpostfilter
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 51200000
message_strip_characters = \0
milter_default_action = accept
milter_protocol = 6
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
mydomain = howitts.co.uk
myhostname = mailserver.howitts.co.uk
mynetworks = 127.0.0.0/8, [::1]/128, 172.17.2.0/23, $clearglassnetwork
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
recipient_delimiter = +
relayhost = [smtp.ntlworld.com]:25
sample_directory = /usr/share/doc/postfix-2.10.1/samples
sender_dependent_relayhost_maps = hash:/etc/postfix/relayhost_map
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sender_dependent_authentication = yes
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_use_tls = yes
smtpd_client_restrictions = permit_mynetworks,
reject_unknown_reverse_client_hostname
smtpd_helo_required = yes
smtpd_milters = inet:127.0.0.1:8891
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_non_fqdn_hostname,
reject_non_fqdn_sender, reject_non_fqdn_recipient,
reject_invalid_hostname, check_policy_service
unix:/var/spool/postfix/postgrey/socket, reject_unauth_pipelining,
reject_unknown_recipient_domain, reject_rbl_client zen.spamhaus.org
smtpd_relay_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_auth_enable = no
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = permit_mynetworks, check_sender_access
hash:/etc/postfix/access, permit_sasl_authenticated,
reject_non_fqdn_sender, reject_invalid_hostname
smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_auth_only = no
smtpd_tls_cert_file =
/etc/letsencrypt/live/www.howitts.co.uk/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/www.howitts.co.uk/privkey.pem
smtpd_tls_loglevel = 1
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
unverified_sender_reject_code = 550
virtual_alias_maps = $alias_maps, $virtual_maps,
ldap:/etc/postfix/imap-aliases.cf, ldap:/etc/postfix/imap-groups.cf

In /etc/postfix/access I have:
howitts.co.uk        REJECT
qq.com            REJECT

The howitts.co.uk is there to stop anyone from the internet pretending
to send mail from my domain to me. My roadwarriors send on port 587 to
bypass this restriction.

This means the spam can't get through for two reasons 1 - it is from
qq.com and 2 - the users don't exist on my system.

The qq.com sent directly so me is from all sorts of IP addresses, but
often 163.com so it is not a single IP. It has the typical scattering
of sending IP's some with and some without PTR records (so from unknown).

Is there anything further I can do to cut down or stop this spam? Also
are there more effective blocks I can do to lighten the load on the
server and reduce traffic?

Thanks,

Nick

I'd suggest looking into postscreen. There are some additional things
that can be blocked over and above what smtpd can block and it can block
some of the same things using less resources.

http://www.postfix.org/POSTSCREEN_README.html
I'll have a look. I already use postgrey and that has problems with senders who send from different IP's. It seems like postscreen has the same issue and I'd rather try to avoid myltiple whitelists.

You could so is to look into additional block lists to use with
reject_rbl_client checks. I use b.barracudacentral.org as well as
zen.spamhaus.org but there are others too that can be valid either as
outright blocks or as part of the scoring mechanism to use with
postscreen_dnsbl_threshold.
I think this is too late in the process. I think check_sender_access fires earlier in the receiving process and does not require DNS lookups so should be "cheaper" for resource utilisation.

You could also consider some specific smtpd_helo_restrictions like
reject_invalid_helo_hostname and reject_non_fqdn_helo_hostname. I also
use dbl.spamhaus.org with reject_rhsbl_helo and reject_rhsbl_sender. You
could also look into adding reject_unknown_recipient_domain and
reject_unknown_sender_domain.
I used to use this for a while with reject_invalid_helo_hostname and reject_non_fqdn_helo_hostname but removed it. Unfortunately I can't remember why. I've now set them up again with warn_if_reject to see if I can remember why. Also what HELO greeting is used by the MX Backup? If it is its own, most of the spam will pass this check.

Also if the 29860 connections are coming through with many concurrent
connections or in a short space of time you could add some
concurrency/rate limits.
I will investigate. I don't think I have a load issue. I just wish they would go away.

John

Reply via email to