On 10/20/22 10:32 AM, Jaroslaw Rafa via mailop wrote:
I consider this being purely a connectivity thing.
Except that it's not a /connectivity/ thing. At least not on any OSI layer. The rejection that you are advocating for is sent across / over / through the established connection. So, no, I don't believe it's a /connectivity/ thing.
Do you call the pone company to report a problem calling a phone number when they answer the call, say "I'm not talking to you.", and hang up on you?
T-Online customers can send mail to any mailserver and they aren't aware of the fact that they can't get a reply because T-Online has a "default block" policy, unless whitelisted. They are harming connectivity in a way that is invisible to their users, doing in fact misservice to those users.
I agree completely.
The proposed configuration change only makes this visible and clear,
I disagree that it will make it visible. I doubt that it will make it clear.
First and foremost, that relies on the rejection notice, and details thereabout, to make it back to the sender. What's more is that it requires the sender to have (access to someone with) a modicum of understanding.
Even if the sender is clued into what is happening on a technical level, you are still left with the mismatch in size of companies, the larger company tends to have an advantage (at least) as large as the size discrepancy. Senders will almost always say "well I can send to others so it can't be on my side thus it must be on the recipient's side".
introducing also default blocking in the reverse direction (unless whitelisted, which you can always do). I think that a block you know about is "better" than a block you don't know about.
I believe such a block is setting things up for a self fulfilling feedback loop. -- Once two parties start "doing something because the other is doing it to them" there is no exit / end / termination of the loop without external influence.
T-Online customers trying to send mail to other mailservers will hit that block, and if the reject message will exactly specify the reason - something like "We block mail from T-Online because they block mail from us" - and the customer forwards this message to T-Online support, I assume they'll at least have to explain the situation to the (probably angry) customer.
I seriously doubt that's going to work out satisfactorily for anyone other than T-Online.
Maybe over time their will consider changing their "default block" approach.
Isn't there some rule / guideline / law that states that the longer that something has been in place the longer it is likely to stay in place? Seeing as how T-Online has purportedly had this in place for a decade, I doubt that it's going to change any time soon.
Finally, I feel like the old adage of two wrongs don't make a right comes to mind. After all, I think most of us can agree that what T-Online is doing is wrong. And you're advocating that more of us make the same wrong choice. What's more is that you're advocating to codifying this wrong choice in default configuration for multiple MTAs. I think that's an order of magnitude worse than the original wrong.
So now I think we're up to 12 wrongs; T-Online's default block is 1st, your reactionary default block is 2nd, and your desire to codify this is another ten.
P.S. Reach for / strive for better, don't settle for what we have. If at all possible don't make things worse.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
