On 10/20/22 9:14 PM, Kai 'wusel' Siering via mailop wrote:
But their "policy" does not adhere
Yes, T-Online /does/ adhere to T-Online's policy of only accepting email from senders that T-Online considers to be blessed.
No. They 554 anyone, including me from any of my 1k+ v4 IPs except for 2 of them.
No, T-Online doesn't 554 /anyone/. T-Online quite obviously 250s many blessed senders.
Let me compute 2/1000, I came up with 0. Please correct my math, really, really please …
The math doesn't matter /because/ T-Online /does/ 250 blessed senders.
Granted. OTOH, nothing states that _that single outcast_ shouldn't be properly casted in the default configuration of any mailserver there is.
I believe there have been multiple others beside myself that think that T-Online should NOT be shunned in MTA /default/ configurations.
As has been pointed out before, doing so *does* increase deliverability, *does* increase transparency.
No. It makes deliver-ability *WORSE*.As pointed out before, your choice to refuse to accept email from T-Online means that *you* break communications between a T-Online user and /you/ wherein the T-Online user sends a Reply-To: set to their Gmail address. /You/ *WOULD* be able to communicate with them /without/ sending any email to T-Online. But /you/ have chosen to block that email at /your/ server.
Sure. Totally agree.But: IF it is a KNOWN FACT that they DO NOT ACCEPT MAIL FROM ANY SERVER except those where they previously whitelisted it's IPv4, AND THEY ARE THE SINGLE ONLY MAILSERVICE ON PLANET EARTH to do so, THEY MUST BE MARKED AS SUCH.
I suspect that there are *MANY* Business-to-Business email servers that use similar filtering and only allow /specific/ previously white listed addresses to communicate. That's the exact same thing that T-Online is doing. The only difference is that T-Online has a more public user base.
As anything else leads to broken communication. I'm okay with you being okay with that, but you cannot chance sides afterwards. And this is not over yet.
I have no problem receiving messages from T-Online. I will honor a Reply-To. Or I'll put an impressum on my web site and ask T-Online to white list me. -- I have no problem with what T-Online is doing. It's their server(s) and thus their rules.
I made that clear multiple times already; feel free to check the archives.
No. You have made it abundantly clear that you strongly disapprove of what T-Online is doing. You have not provided justification for why MTAs should alter their default configuration to banish T-Online.
You're apparent vehement dislike for T-Online is not in and of itself justification for banishing them.
Years ago a few email servers started requiring reverse DNS PTR records. People wanted to shun the first few that required such as outliers. Now the PTR record is SOP.
As stated above, there are many B2B email servers that only allow white listed peers.
Do you also want to identify those B2B email servers and equally banish them?
If not, why not? Why do you think that T-Online deserves anything different than other B2B email servers?
Anyone's policy has to work within the parameters of the choosen protocol and it's policies, otherwise interoperability is not possible.
T-Online *IS* working within the parameters of the SMTP protocol. Servers that are white listed can speak bog standard SMTP / ESMTP to T-Online without a hint of a problem. Hence T-Online is using standard protocols.
As such, t-online.de's policy is not compatible with how the SMTP protocol is supposed to work: 554'ing basically anyone is NOT the way to go.
It may not be a /good/ way to go. It might even be a /bad/ way to go. But it is still within the SMTP specification.
Besides, mx*.t-online.de don't comply to RFC 5321, Section 3.1: "a 554 response MAY be given in the initial connection opening message instead of the 220. A server taking this approach MUST still wait for the client to send a QUIT […]". They don't. And they aren't Joe Random following a bad HowTo. t-online.de is deliberately breaking standard's track RFCs to, as it seems, gain a competative advantage. This mustn't hold.
I understand why you might think that. However RFC 5321 § 3.8 -- Terminating Sessions and Connections -- states: """An SMTP server MUST NOT intentionally close the connection under normal operational circumstances (see Section 7.8) except:
...o After a timeout, as specified in Section 4.5.3.2, occurs waiting for the client to send a command or data.
"""The letter of RFC 5321 § 4.5.3.2 -- Timeouts -- talks about /command/ timeouts. I believe that the initial greeting / hello banner is within the spirit and can leverage timeouts. Thus the server can time out connected clients in an extremely short interval and naturally close the connection.
RFC 5321 § 7.8 -- Resistance to attacks -- also goes into more details about what a server can do to protect itself / it's users.
"""In recent years, there has been an increase of attacks on SMTP servers.... While the means of doing so are beyond the scope of this Standard, rational operational behavior requires that servers be permitted to detect such attacks and take action to defend themselves. ...it would be reasonable for the server to close the connection after generating an appropriate number of 5yz (normally 550) replies.
"""So, I'm of the opinion that RFC 5321 § 7.8 *EXPLICITLY* allows and condones the server returning 5yz errors (and timing out ~> closing the connection (after an extremely short timeout)). 554 is definitely within 5yz.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
