See embedded comments, a little clarity and data on those networks..
On 2026-06-05 09:46, postfix--- via mailop wrote:
Hello list, may I pick the accumulated wisdom and experience?
any useful traffic from these subnets:
18.32.0.0 - 18.255.255.255 Amazonaws.com
As pointed out by others, both good and bad, however bad actors are more
visible. AWS needs to add transparency. Some we known marketing
companies now using AWS, several know list washers, so cannot recommend
blanket restrictions, but you can 'flag for further review'. Also, many
IPs appear 'momentarily' for short runs only.
34.4.5.0 - 34.63.255.255 Googleusercontent.com
Yeah, this one is bad.. Both AUTH attackers, bots, and some strange form
of fake bounce checks.. eg..
CONN: 35.229.100.104 -> 25 GeoIP = [US] PTR =
104.100.229.35.bc.googleusercontent.com
EHLO command received, args: [10.88.0.5]
MAIL FROM address: []
Another threat actor though..
CONN: 34.74.236.161 -> 25 GeoIP = [US] PTR =
161.236.74.34.bc.googleusercontent.com
HELO command received, args: les3petitscochons.net
MAIL command received, args: FROM:<[email protected]>
support@, info@ .. well known actor..
treat as you would any other 'dynamic' IP range, block port 25, either
by regex, or by IP ranges.. there are RBL's which also list active
ranges and some informational DNS RBLlike lists SpamRats RATS-Gcloud you
can use/check, note IP ranges change purpose, Google does have a public
list, but it isn't even that accurate.
You can have an 'exemption list' for the few legitimate servers (in
theory) that might appear, but we haven't had to add any yet.
The worst if the number of AUTH attacks, but hard to tell if they are
simply compromised installations, or threat actors. You might also like
to restrict authentication from those, and add an exemption for any
legitimate relay systems. NOTE: with increased use of MCP, you will see
more legitimate login attempts, but you should use 2FA methods required
from this IP space.
But we also see relays, not sure what nature being set up, usually
Indian threat actors.. username only authentication attempts -> port
587, standard dictionary attacks, 'could' be a botnet originating
attack, via googleusercontent relays, however have not been able to get
any confirmations from google on this yet.
Known persistent attackers also end up on RATS-AUTH.
If you REALLY want to stop the noise, yes you can build an ipset for
your firewalls, with minimal blow back.
I am thinking of just dropping them at the firewall and call it a day. I
have not yet advertised my super clean new mail server and there is
already a stream of abuse.
also from:
64.62.197.0/24 shadowserver.org
Others have mentioned, legitimate, but noisy .. you can request they
don't probe your machines.
141.98.10.0/24 hostbaltic / tiscali.it?
Careful, hostbaltic is one issue, other related tiscali.it is another.
HostBaltic-LT, IP space via Tele Asia, that's a bullet proof hoster.. or
inept administrators, obvious spammers, and other attacks.
eg 45.125.64.0/22 -> 45.125.66.0/24
But those are probably on most DROP lists like SpamHaus and SpamRats,
you are using those correct?
Hopes this helps, and give you more insight..
I know rspamd could deal with that, but in the cloud compute resources
have cost and I am looking for the most radical, simple,
compute-efficient solution to keep bad networks out. Are there
community-maintained efforts, like the
https://github.com/StevenBlack/hosts for hosts?
Thank,
Yuv
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
