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
