Assistance to protect from spam flood

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Assistance to protect from spam flood

Nick Howitt
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

Reply | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

John Fawcett
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

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.

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.

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.

John

Reply | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

Dominic Raferd
In reply to this post by Nick Howitt
On Sat, 12 Jan 2019 at 11:10, Nick Howitt <[hidden email]> 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 {[hidden email] to
{[hidden email].

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

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?

Using postscreen even if only with zen.spamhaus.org will probably stop most of them before they get their foot in the door. If the load remains a problem then try the postfix jail in fail2ban - but it will only help with repeated attempts from same ips.
Reply | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

Nick Howitt
In reply to this post by John Fawcett


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 | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

John Fawcett
On 12/01/2019 15:23, Nick Howitt wrote:

>
>
> 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. ....
>>
>> 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.
If you only use the first layer of checks not the deep protocol checks,
the clients don't have to disconnect and retry.
>>
>> 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.
for the specific domain yes, but in general you might be able to block more.

>>
>> 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.
If your users use submission service to send email and you use the above
restrictions only for inbound email on port 25 they may block some badly
configured servers, but I don't think its a big issue. YMMV. I'd
configure the backup server as far as possible with the same
restrictions used on the main server to block email incoming into the
backup server.
>>
>> 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
>>
Just one last thought. Are these emails that are coming in from qq.com
spam emails or bounces? If they'll bounces you may have a different
problem with one of your users' accounts or pc that is compromised,
though they may just be backscatter generated by some spammer that you
can't do much more about.

John

Reply | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

Nick Howitt
In reply to this post by Nick Howitt


On 12/01/2019 14:23, Nick Howitt wrote:

>
>
>
> 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.
Confirming, HELO checks don't work on my MX backup as it uses its own
(valid) HELO. Most of the spam is coming via the MX Backup.
>>
>> 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 | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

Nick Howitt
In reply to this post by John Fawcett


On 12/01/2019 14:47, John Fawcett wrote:

> On 12/01/2019 15:23, Nick Howitt wrote:
>>
>> 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. ....
>>> 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.
> If you only use the first layer of checks not the deep protocol checks,
> the clients don't have to disconnect and retry.
>>> 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.
> for the specific domain yes, but in general you might be able to block more.
>>> 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.
> If your users use submission service to send email and you use the above
> restrictions only for inbound email on port 25 they may block some badly
> configured servers, but I don't think its a big issue. YMMV. I'd
> configure the backup server as far as possible with the same
> restrictions used on the main server to block email incoming into the
> backup server.
Unfortunately I don't have access to the MX Backup service. It is
provided by my DNS provider.

>>> 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
>>>
> Just one last thought. Are these emails that are coming in from qq.com
> spam emails or bounces? If they'll bounces you may have a different
> problem with one of your users' accounts or pc that is compromised,
> though they may just be backscatter generated by some spammer that you
> can't do much more about.
>
> John
>

Reply | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

John Fawcett
On 12/01/2019 15:52, Nick Howitt wrote:

>
>
> On 12/01/2019 14:47, John Fawcett wrote:
>> restrictions only for inbound email on port 25 they may block some badly
>> configured servers, but I don't think its a big issue. YMMV. I'd
>> configure the backup server as far as possible with the same
>> restrictions used on the main server to block email incoming into the
>> backup server.
> Unfortunately I don't have access to the MX Backup service. It is
> provided by my DNS provider.

I know it sounds a bit drastic, but you might want to think about
whether you need a backup server you don't control. A better choice if
you can't control your own backup server is to have none.

The amount of email you would lose for small outages on the main server
without a secondary MX should be close to zero. With a backup server
that cannot reject mail for unknown users, you will probably be
generating backscatter when your main server rejects email being handed
off from the backup to your main server.

John

Reply | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

Durga Prasad Malyala
Hi,
if you implement Mailscanner etc you can assign a higher score based
on a header containing 163.com. Maybe that would work.
In any case everyone uses either mailscanner or rspamd on top of postfix.
You can try one of those
As John suggested and its my personal experience also that, If you
have a backup MX, that should also have good anti-spam as most
spammers target that server as a backdoor entry.

Regards/DP

On Sat, 12 Jan 2019 at 20:35, John Fawcett <[hidden email]> wrote:

>
> On 12/01/2019 15:52, Nick Howitt wrote:
> >
> >
> > On 12/01/2019 14:47, John Fawcett wrote:
> >> restrictions only for inbound email on port 25 they may block some badly
> >> configured servers, but I don't think its a big issue. YMMV. I'd
> >> configure the backup server as far as possible with the same
> >> restrictions used on the main server to block email incoming into the
> >> backup server.
> > Unfortunately I don't have access to the MX Backup service. It is
> > provided by my DNS provider.
>
> I know it sounds a bit drastic, but you might want to think about
> whether you need a backup server you don't control. A better choice if
> you can't control your own backup server is to have none.
>
> The amount of email you would lose for small outages on the main server
> without a secondary MX should be close to zero. With a backup server
> that cannot reject mail for unknown users, you will probably be
> generating backscatter when your main server rejects email being handed
> off from the backup to your main server.
>
> John
>
Reply | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

@lbutlr
In reply to this post by Nick Howitt
On 12 Jan 2019, at 07:52, Nick Howitt <[hidden email]> wrote:
> Unfortunately I don't have access to the MX Backup service. It is provided by my DNS provider.

Honestly, you should not have an MX server outside of your control.

If your server is routinely down for several days, then you shouldn't be running your own server.

--
The reaper does not listen to the harvest. --Reaper Man

Reply | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

Bill Cole-3
In reply to this post by Nick Howitt
On 12 Jan 2019, at 6:09, Nick Howitt wrote:

> I have a mail server and two backup MX servers and most of the mail is
> arriving via one of the backup servers.

Your first step should be to seriously interrogate that architectural
choice.

When variable-priority MXs were devised, the Internet was very different
and general experiences with cross-domain email were very different. It
made sense to have distant backup MXs, even if they were run by other
people. Also, spam wasn't a thing.

Today there are very few mail systems can gain anything discernible from
having multiple MXs that are not under common administrative control and
consciously configured to operate together as equals or with varied
priorities. As you have discovered, having secondary MXs which you do
not control causes hard problems with spam. In addition to the fact that
spammers have learned to hit the backup MXs first, you are presented
with the problem of very likely causing backscatter and/or silently
dropping mail.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
Reply | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

allenc
In reply to this post by Nick Howitt


On 12/01/2019 11:09, Nick Howitt wrote:
>
> 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

If you are troubled by Chinese hosts, you might also like to look at the thread "SMTP filter using geo-localization" for
ideas.

But as others have said, ditching the secondary MX servers and setting up Postscreen should be your first two priorities.

Talk to me off-list.

Allen C
Reply | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

Nick Howitt
In reply to this post by @lbutlr


On 12/01/2019 16:42, @lbutlr wrote:
> On 12 Jan 2019, at 07:52, Nick Howitt <[hidden email]> wrote:
>> Unfortunately I don't have access to the MX Backup service. It is provided by my DNS provider.
> Honestly, you should not have an MX server outside of your control.
>
> If your server is routinely down for several days, then you shouldn't be running your own server.
>
OK. Let's assume I don't have an MX Backup. Then all 30k+ attempted spam
deliveries would have come straight to me. They would all have failed,
initially because of unknown recipient, then, when I added them to the
access list, because of an denied sender. What is the most efficient way
of blocking these messages? Can they be blocked earlier than
smtpd_sender_restrictions?
Reply | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

Benny Pedersen-2
Nick Howitt skrev den 2019-01-12 21:58:

> efficient way of blocking these messages? Can they be blocked earlier
> than smtpd_sender_restrictions?

:

check valid recipient BEFORE valid senders
qq.com have SPF use it, if SPF is pass block this sender domain if its
spam, report to qq.com and hope thay listen

use postscreen

use dnsbl in postscreen

google postscreen dnsbl, it have being posted nummer of thing to solve
spamming
Reply | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

John Fawcett
In reply to this post by Nick Howitt
On 12/01/2019 21:58, Nick Howitt wrote:

>
>
> On 12/01/2019 16:42, @lbutlr wrote:
>> On 12 Jan 2019, at 07:52, Nick Howitt <[hidden email]> wrote:
>>> Unfortunately I don't have access to the MX Backup service. It is
>>> provided by my DNS provider.
>> Honestly, you should not have an MX server outside of your control.
>>
>> If your server is routinely down for several days, then you shouldn't
>> be running your own server.
>>
> OK. Let's assume I don't have an MX Backup. Then all 30k+ attempted
> spam deliveries would have come straight to me. They would all have
> failed, initially because of unknown recipient, then, when I added
> them to the access list, because of an denied sender. What is the most
> efficient way of blocking these messages? Can they be blocked earlier
> than smtpd_sender_restrictions?

In your specific case I would have just let them reject based on unknown
recipient (if they get past postscreen and rate limitng, when they are
in use). It doesn't require maintenance of access files unless you plan
to auotmate that. 

John

Reply | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

Bill Cole-3
In reply to this post by Nick Howitt
On 12 Jan 2019, at 15:58, Nick Howitt wrote:

> On 12/01/2019 16:42, @lbutlr wrote:
>> On 12 Jan 2019, at 07:52, Nick Howitt <[hidden email]> wrote:
>>> Unfortunately I don't have access to the MX Backup service. It is
>>> provided by my DNS provider.
>> Honestly, you should not have an MX server outside of your control.
>>
>> If your server is routinely down for several days, then you shouldn't
>> be running your own server.
>>
> OK. Let's assume I don't have an MX Backup. Then all 30k+ attempted
> spam deliveries would have come straight to me.

Not necessarily. There are spammers who use backup MXs intentionally to
scam their own customers, since they can show "successful" deliveries
without regard to what ultimately happens to the messages. There is also
the possibility that this is an intentional backscatter-flood attack on
the putative senders, using your backup MXs to bounce a flood of junk at
them.

> They would all have failed, initially because of unknown recipient,
> then, when I added them to the access list, because of an denied
> sender. What is the most efficient way of blocking these messages? Can
> they be blocked earlier than smtpd_sender_restrictions?

Maybe.

If you use postscreen's pre-greeting data detection and a suitable set
of DNSBLs it is likely (if this is mostly spambots, which seems likely)
that you can keep a large fraction of them from ever talking to a real
smtpd

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
Reply | Threaded
Open this post in threaded view
|

Re: Assistance to protect from spam flood

Kris Deugau
In reply to this post by Nick Howitt
Nick Howitt wrote:
> OK. Let's assume I don't have an MX Backup. Then all 30k+ attempted spam
> deliveries would have come straight to me. They would all have failed,
> initially because of unknown recipient, then, when I added them to the
> access list, because of an denied sender. What is the most efficient way
> of blocking these messages? Can they be blocked earlier than
> smtpd_sender_restrictions?

Blocking at that point is still incredibly cheap compared to accepting
the message then feeding it to eg SpamAssassin.

About the only notch better you could do would be to watch for some of
the IPs, look up the netblock they're part of in WHOIS, then block them
in the firewall.  That assumes you never ever EVER want to receive mail
from anyone using those providers, with ANY domain in the sender address.

I had a P100 with maybe 32MB or RAM, running sendmail, relaying possibly
10-15K messages daily to a legacy mail system running on a Novell
Netware 4.something host (yes, really) around 2001, and rejecting a
longish list of things based on connecting IP or sender email both
within sendmail and occasionally via milter (MIMEDefang).  Load was
effectively 0.  If these aren't showing up in your mailbox, don't worry
about it.

-kgd