Am 21.10.22 um 09:39 schrieb Florian Effenberger via mailop:
I am neither a package maintainer nor a mail server developer, so my voice
likely is just a very small one - but last year I've been gone through a lot of
the pain with setting up a new mail server on a new IP address and getting
blocks left and right -
To stay ontopic here, the question is: _why_ were you getting "blocks left and
right"? And what were they?
Was it a "fresh & clean" IPv4 address or one that had been abused in the past?
What did the RBL checking tools tell you about that IP?
Did the IP belong to an ISP that people that have to deal with remote abuse do
wrinkle their nose at?
And, most importantly: did you have to contact any postmaster to get that IPv4
address, with matching PTR and A records, proper SPF and DKIM entries,
whitelisted to access their MXes at all?
Let me agree that blocking a provider by default does not seem wise.
Your end-users don't care, for them it just "does not work". They are not interested in
"politics", and if their e-mail doesn't work, they just go with a different service.
People are lazy and people want practical solutions.
Exactly, people are lazy, they don't want to spend 15 minutes to write a longer email
which then sits 5 days in the mailer's outgoing queue and finally comes back with a
cryptic message like "A problem occurred. (Ask your postmaster for help or to
contact [email protected] to clarify.)".
Postmasters are people, too. They as well don't want such a shit show. _They_
didn't do anything wrong to deserve that treatment.
Second, where to start and where to end? There seem to be quite a few mail
operators who block, let's say, a bit arbitrary.
There is one known public mail service that blocks universally, not just arbitrarily.
Given that, default MTA configuration should be "don't talk to them as the won't let
you talk back". Saves peoples time and nerves, therefore a very pragmatic, and very
practical solution.
If your customers *request* to talk to t-online.de users, you still can
negotiate with tosa@rx and then reflect that in your MTA configuration.
Blocking all of them makes things worse, and then the fear of e-mail getting
into the hand of a few single big players becomes a self-fulfilling prophecy.
Nobody wants to be on a mail server that can only connect to very few selected
sites, whatever the reason, and how good the motivations might be.
Well, mostly no-one using a @t-online.de mailbox knows about their provider's
block-by-default policy. And no customer ever notices, as *their* mail is
deviously delivered to any domain there is. But they don't get a reply, giving
the _receipient_ a bad reputation in their eyes. Whereas it's their very own
mail provider that is inhibiting the replies to them.
As such, disabling reception of @t-online.de mail per default – until the way
back is mutually agreed on – is the best way to solve this. It makes the harm
t-online.de creates visible to their users and prevents communication delays
and blackholes.
Third, I guess the deployment cycles are rather long - so what you add to a
package right now will very likely not end up on a majority of machines for
months, years, whatever. And who knows if distributions will incorporate
anything of that, so it seems a lot of work with very little predictable result.
Every Change has to start somewhere. This is a plague for 10+ years now; if
from, say 2023, or 2024, new MTA deployments start to save the users from the
pitfalls of the t-online.de setup, it is a start. Usually existing
configurations aren't overwritten, so this will help only on new installations
or manual upgrades, where configuration parameters are copied over manually.
I am just a small operator for a rather specific use case here, so I can only
assume the amount of pain and frustration bigger operators must go through.
Speaking as the operator of two really tiny mail servers myself, I rather
assume that the most pain and frustration is created there.
I doubt that it would take GMX more that one single mail to tosa@rx if they change IPs in
their sending pool. Question is if they even would notify t-online.de upfront anyway.
Would Google, Microsoft? "T what?"
I actually expect that t-online.de proactively monitors known webpages or DNS records of
the big players — what they do not want, are major tabloids doing headlines like
"T-Online messes up it's mail service".
Am 21.10.22 um 16:40 schrieb Florian Effenberger via mailop:
Well Germans are not what they used to be 😄, so maybe that one considered your
insistence enough to whitelist you.. or perhaps the decision of when a server
is commercial or not is not /that/ well-defined for them.
maybe the term "commercial" here stems from the German imprint requirements.
It's »geschäftsmäßig« in TMG §5 (1), not commercial. Telekom states mailservers would
need to be run by "commercial" (»kommerziellen«) operators. These are different
terms.
Regards,
-kai
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
