Am 20.10.22 um 21:29 schrieb Michael Rathbun via mailop:
On Thu, 20 Oct 2022 20:47:40 +0200 (CEST), Bernardo Reino via mailop
<mailop@mailop.org> wrote:
However, I still find that Postel's law should apply, in any context, and
specifically in this one. You want to run an e-mail server and don't want to be
blocked, so you should (liberally) accept, instead of "being like them" and
block unfairly (for some definition of fairness anyway).
Yes and no. I don't want to be blocked by arbitrary rules that aren't based
on industry standards.
If my servers sent out spam, fine, block me and let's work on it case-by-case
(usually the root cause is failing spam detection – running non-profit or even
private mailservers, I cannot afford commercial services like expurgate – so
that the few spam content which rspamd with RBLs, Bayes- and Fuzzy-filters
doesn't detect is relayed via mailing lists or ticket systems to external
addresses).
That's the industry standard: block after abuse. Instead, t-online.de uses
block-and-maybe-unblock-after-contact. This is not how email is supposed to
work.
"Fairness" isn't my concern; the policy of t-online.de is creating bounces
at potentially a shitload of mailservers out there, because of a totaly
arbitrary setup.
This leads to lost communication — something no mail provider should stimulate.
Anything that helps to mitigate these effects is A Good Thing™, IMHO.
After all, this is what we (should) teach our kids, so I'm a bit surprised that
some people are proposing (or have already implemented) doing the eye-for-an-eye
(or was it a tooth?) to T-Online.
While it looks like an eye for an eye, this is only a side effect. Sitting on
the receiving side of t-online.de mails, I'm faced with users confused why
"that @t-online.de address I just replied to isn't valid anymore". Of course
it isn't, the error code is not 550 but 554 ...
Is there a quick solution? No, see the discussion here.
Is it my fault? No.
Will my users resent their message in a few days time, after this issue is
resolved, hopefully? Unlikely.
Does t-online.de care? Nope.
Do t-online.de's users understand who is causing the issues? Highly unlikely.
And last but not least: is t-online.de's setup significantly reducing the amount
of spam received by it's users in 2022? Highly unlikely — if t-online.de would
be run according to industry standards. But then
https://postmaster.t-online.de/index.en.html#t3.5 reads:
*
Do t-online.de systems use greylisting, SPF or DKIM for e-mail filtering?
Greylisting is generally understood to mean that every incoming e-mail is
initially rejected temporarily and only accepted after a renewed delivery
attempt. This is based on the assumption that only authorized e-mail
systems initiate renewed delivery of rejected e-mails. As greylisting cannot
actually identify unauthorized e-mails and also hinders the delivery of
legitimate e-mails, Telekom systems do not use this procedure.
The Sender Policy Framework, SPF for short, can enable a check to determine
whether the sending IP address is authorized to send e-mails for the domain
in question. This procedure has numerous vulnerabilities that cannot be
compensated for, including those that are described here
<https://en.wikipedia.org/wiki/Sender_Policy_Framework>. Therefore, Telekom
does not use SPF either passively (when receiving e-mails) or actively (for
sending) by creating corresponding DNS resources.
Until now, we have neither used nor evaluated DKIM signatures. (An exception
is the "Trusted Dialog" project, which uses DKIM signatures for "inbox
branding".)
Tja ... Since one cannot properly compute the validity of emails from
t-online.de,
seriously, what's the point of accepting from that doamin anyway?
Another rule from an earlier era outlines one of the fundamental principles of
the Internet Agreement: I will accept your traffic, subject to my policies
and agreements, if you will accept mine, subject to your policies and
agreements.
Yes, but as t-online.de fundamentally breaks with this principle, giving a 554
to *any* IP per default, they should be single cased out for good by default.
They can always apply for being re-enabled bilaterally on any mailserver — as
per
their view on how email works.
Regards,
-kai
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
