Bob Proulx via mailop wrote on 2022-04-18 05:59:
Paul Vixie via mailop wrote:
all of these actors might be "trying to make things work" but be taking a
naive or ignorant or provincial or subjective view of both "things" and
"work".
By trying to make things work I was thinking of SPF, DKIM, DMARC,
DANE, and DNSBLs, and other, and the list goes on. To keep the noise
down so that email is usable.
that's fair. note that the original RBL (at MAPS, this was) was an
attempt (by me, and then by others) to "keep the noise down so that
e-mail is usable". you should be able to verify from where you sit that
(a) we did not achieve that goal, (b) we achieved a number of other
deleterious non-goals, and (c) we were not universally hailed as
liberators by others who thought they knew better what "the public
interest" actually was.
(... It's difficult to learn all at once now. It's hard enough
keeping up with the developments as they develop.)
and for the record, when google started bouncing my e-mail because i
didn't have DKIM and SPF set up, i was a little annoyed but a lot more
embarrassed. it wasn't until i'd fixed everything they demanded but they
were still bouncing my e-mail and not telling me why that i got a lot
annoyed. once they invited their first billion mailboxes to shelter
behind their spam defense, they acquired the obligations of nobility.
...
We all have taken shortcuts that we hoped were temporary to reduce a
problem somewhat. Block an IP address? Sure. The /24 neighborhood?
Yup. It's from OVH, Digital Ocean, Linode? Let's block all of that
hosting center. Just examples of behavior I think is undesirable.
(Yet I definitely have /24 networks in my own block lists.)
for the record, when vernon schryver and i developed the DNS version of
all this (called RPZ; see it on the web at dnsrpz.info) my first ruleset
for my own RDNS servers was to accept TCL.TK but deny resolution for all
other *.TK names. what a relief! so i grok your cost:benefit concerns.
But that really creates problems for the concept of distributed email.
If any operator that is NOT Too Big To Block has their entire hosting
network blocked then only those that are Too Big To Block will remain.
And those very small ones that no one knows about. With nothing in
between. The big get bigger and the small get smaller.
centralization is the capital-amplifying way to scale things. i know
that google has a hard problem in accepting e-mail from small domains
and that their life would be easier if they only had to worry about the
big ones. however, they're the centralizer, so the burden is theirs. i
was he who first coined the phrase "their network, their rules" but i
did not realize that the future held many operators who were "too big to
care" on the receiving side. in my present at that time (1996 or so) the
only "too big to care" entities were on the sending side. ouch.
--
P Vixie
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
