Thank you all for the helpful feedback. Some comments in no particular
order, and then a summary at the end (for now). I intentionally omit
most names and express my gratitude and respect for chiming in, on
either side of the fault line, even (and more so) the side that is not
aligned with my interest.
>> 18.32.0.0 - 18.255.255.255 Amazonaws.com
>
> I'm obviously biased, but I'd like to think so, yes. Our DE and UK
> deployments use IPs from that range, for instance.
sorry for your predicament. I've been in a similar predicament with my
old deployment at Digital Ocean. Not much I can do if the swamp's owner
has policies that smell worse than rotten fish, other than sanitizing
myself out of there.
> I get a fair amount of real mail mixed in with the crud
this is what makes it difficult when getting close to the **FAULT
LINE**. Whose fault is it for the mixing up of ham and spam and for
commingling water with sewage? And which perspective prevails?
> AWS needs to add transparency.
Possibly? transparency is one way to **GOVERNANCE** and certainly a
requirement for democratic governance. BUT: governance start with
self-governance; and there are forms of non-democratic governance that
work pretty well. As a user, I receive less spam when I am governed by
Apple (iMessage) or Telegram.
> Honest question -- are there any hosting networks that do a particularly
> great job at keeping spammers away? I'd be happy to move my server.
Honest answer: I do not know. It depends on **INCENTIVES**.
>> 34.4.5.0 - 34.63.255.255 Googleusercontent.com
>
https://developers.google.com/static/crawling/ipranges/user-triggered-fetchers.json
>
> and applying extreme rate limits to keep down the noise.
thanks for the (maybe?) useful link. some feedback says it is not
always up to date. At least it is an attempt at playing civilized. but
why just rate limits? IMHO rate limiting is the wrong **SIGNAL**: it
still taxes my resources more than I am willing to tolerate. Tolerance
tends to encourage bad behavior and unless there are benefits to the
tolerance, or it is technically impossible to avoid, it should be avoided.
>> 141.98.10.0/24 hostbaltic / tiscali.it?
>
> 141.98.10/24 has been in our block-and-forget list since 2022-Mar-21
nobody had good words for this one, surprise.
> no reason to reconsider.
important thought that requires design. what if the subnet changes
ownership, or, against all odds, they do clean up their act and start
participating civilly? **DYNAMICS**
>> 64.62.197.0/24 shadowserver.org
> It is useful security scanner
...
> You can easily opt out
...
> I think they do good work
...
> legitimate, but noisy .. you can request they don't probe your machines
A lot of good words for them. HOWEVER: IMHO, the opt out model is
insufficient and unacceptable. Another signal.
Too many "white hats." Some try to justify their stuff in their
whois/RDAP remarks. Some have some sort of TOKEN there. No idea what
it is. If someone cares to explain, I am curious. But it is curiosity
only. To me, the white hats are as much of a nuisance as the black
hats. Unless *I* decide that I want to hire/pay a white hat.
BACKGROUND INFORMATION: These four picked subnets were just a
representative sample. Four different cases collected over the first
two days of life of a new cloud instance. Apart from a couple of test
emails I sent forth and back to validate my proof of concept (still
needs some work), it was all sewage that assaulted port 25 on an IP
address that has been kept inoperative/silent for a couple of years.
No ports 465, 587, imap, pop3 (is it still a thing?). SSHd behind
wireguard. For easy management, the cloud instance is an Incus host and
the mail server is in an Incus container. Almost completely scripted
instantiation/provisioning. Still a mess, because I am DYI and because
I believe in a different design paradigm than the existing
orchestration/provisioning tools out there. The Postfix/Rspamd inside
the container was showered with sewage once port 25 was forwarded to it.
>> https://github.com/StevenBlack/hosts for hosts?
>
> I've been thinking about building something like this as a hobby,
> but haven't had the time.
If there is one thing that is clear to me: this is not a hobby. There
is a good reason why DNSRBL operators are asking for money for their
service. But also a good reason to avoid their business model.
> there are RBL's [...] Google does have a public list,
> but it isn't even that accurate.
If only the RBL's services were the answer. Abdication of sovereignty
is too much. I may as well move all of my emails to any of the
hyperscaling oligopolists and call it a day.
Rspamd is a partial solution to the data sovereignty issue, but at what
cost and complexity? It has its place closer to the FAULT LINE, but as
first line I am looking for a low compute requirements, bright line
between obvious networks from which I can expect nothing of value in my
circumstances. For the rest, I may indeed apply the finer mechanisms of
Rspamd.
> You can have an 'exemption list' for the few legitimate servers
certainly part of the intended design of that low-computing line. The
beauty of Steven Black's hosts consolidation is that it consolidates
multiple inputs to one user-customizable output, all based on criteria
that match the user's circumstances and coupled with easy
augmentation/reduction based on the circumstances of the specific host.
Such use is far from perfect, and interests contrary to mine can (try
to) circumvent it with hard-coded IP addresses and with kill-switches
embedded in their spyware-infested devices (out on the web there is an
interesting account of an engineer trying to make a robo-vacuum work for
him instead of spying on his household; but I am digressing).
I am dividing the UNWANTED INCOMING TRAFFIC into three classes. Only
one is in scope:
(a) clients/subnets that I do not want to receive from, nor expect to
receive from, anything valuable to me. This is in scope.
(b) compromised/hacked clients: out of scope. There are tools for that
including fail2ban.
(c) clients that are too close to the FAULT LINE, e.g. commingled
traffic, bad network-neighborhood. out of scope. There are tools for
that, including rspamd.
> The worst if the number of AUTH attacks
out of scope.
> hard to tell if they are simply compromised installations,
> or threat actors.
out of scope.
> NOTE: with increased use of MCP, you will see
> more legitimate login attempts, but you should use 2FA methods
> required from this IP space.
out of scope.
Off-topic note on MCP: total shitshow. once again, security was an
afterthought. Rumors have it that some higher up at Meta had all of
their emails deleted; and others had their databases deleted. I like
the German canonical answer: "selber schuld!" I have very briefly
experimented with (custom) MCPs. isolate. isolate. isolate. And not
the way Anthropic suggest, with a firewall on the inside of the
container. Make sure it is isolated from the outside, so that an
unauthorized privilege escalation is not immediately followed by a
gaping firewall hole.
> If you REALLY want to stop the noise, yes you can build an ipset for
> your firewalls, with minimal blow back.
That is indeed the intended goal. But before reinventing the wheel, and
building the ipset alone and on my own, I am looking for something along
the GitHub repo linked above, or at least allies with similar needs to
build an ipset out of common intelligence and common interest.
> [worst offenders] probably on most DROP lists like SpamHaus and
> SpamRats, you are using those correct?
they have their place in rspamd, after the low-compute-cost first line
of defense has limited access. In addition to the waste of compute
resources, it is structurally not wise to rely on DNSRBLs at this stage.
Strategically, they are welcome to contribute to building the ipset
the same way the input from ad-blockers contributors is welcome into the
hosts list at the Github repo linked above. Not the other way around,
which is just a slippery slope to entshittification where the "free"
tier lasts until the new tool reaches critical mass collected from the
data of the "free" users, and then paywalls and other shenanigans are
raised. This kind of sneaky monetization is as acceptable as charging
for security patches that would not be needed in the first place with
access to the automated build pipeline (Ubuntu Pro).
I know that my idea is contrary to the business model and the bread and
butter of many in anti-abuse space. Sorry not sorry. Their interest is
ortogonal if not opposed to mine. My idea is also contrary to the bread
and butter of many if not most ESPs: I will block what they believe is
legitimate interest spam. Sorry not sorry. I am unabashedly and
uncompromizing seeking the best possible implementation of the one rule:
my inbox, my rules.
THE FAULT LINE
Because there is only one reasonable view of ham vs spam: spam is in the
eyes of the recipient. With very few exceptions. I wish I could ignore
as spam the claims of legitimate creditors.
Where an effort is made to accommodate cases that are closer to the
fault line than they could be: cost/benefit-analysis. Too much
complication has been added to capture the DYNAMICS. Sure, network
ownership change, behavior change, people may be open to change
suppliers, etc. -- but the majority of my incoming legit traffic follow
established pattern, and the majority of all traffic is not legit.
Hence, accommodation of dynamic / introduction of change shall be the
afterthought, not a main concern.
GOVERNANCE
Governance starts with self-governance. There will always be someone
looking to exploit a loophole. It's part of my job (lawyer). No
protocol is perfect and there will always be loopholes, with cost,
benefits, and consequences. Without incentives not to exploit
loopholes, most forms of governance will fail, and the more tolerant
ones will fail before the strict/authoritarian ones.
SIGNALS AND INCENTIVES
If the cost/benefit calculation for the bad behavior stays positive,
consequences are just the cost of doing business. If I want the bad
behavior to end, I need to increase the cost. The decision not to
accept traffic from a subnet is a radical one, but it communicates that
bad behavior will not be tolerated. There is room for tolerance before
resorting to an outright block, and that room is well served by existing
tools. However, the cost is completely born by the recipient. No
incentive for the subnet from which the nuisance is emanating to do
anything differently. Adding them on a permanent block list is a clear
signal that their traffic is unwanted here. And if they do not get the
message and are not incentivated to improve their ethics, at least it
does not cost me more resources than putting them on a list. Let them
deal with the problem of not being able to deliver to me.
DYNAMICS
If delivering to me is so important to them, a dynamic will develop. At
their expense, not at mine. When my mail server started suffering from
swampy neighborhood, I contracted SMTP service from an ethical ESP. I
use it as an SMTP relay for outgoing traffic. I still control my inbox,
so if my clients send confidential matter, it does not risk
transit/storage at my service provider that could be affected by legal
and often covert interception (search warrants) or by unethical or
unauthorized inspection. Of course all of these security measures are
moot if my clients use some juggernaut's services for their email
sending, but I have complied with my professional duty to them, and I do
try to educate them about mitigating risk by not emailing confidential
matter.
CONCLUSION
the conclusion for now is that until I have some sort of ip blocklist, I
need to oversize a bit my mail server resources. Not satisfying, but
pragmatic.
I have some other ideas about reducing traffic and reducing compute
waste, but they are still half-backed.
Yuv
On 2026-06-06 01:14, Hans-Martin Mosner via mailop wrote:
Hi,
a bit late, but just adding a data point:
Am 05.06.26 um 18:46 schrieb postfix--- via mailop:
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 a mail source, this is used by some legitimate senders. I'd prefer if
they used dedicated mail infrastructure with a responsible operator, of
course, but you can't always have what you want.
However, the cloud file hosting service of AWS is currently being abused
for massive phishing runs so that I hold any mail referencing a
*.amazonaws.com domain for manual vetting.
34.4.5.0 - 34.63.255.255 Googleusercontent.com
Block. I've not seen any good come from there, ever.
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
Can't say anything personally, but apparently they are white-hat as
reported by other list members.
141.98.10.0/24 hostbaltic / tiscali.it?
Hostbaltic has been on my block list for a long time for reasons...
Cheers,
Hans-Martin
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
