On 10/20/22 1:22 PM, Kai 'wusel' Siering via mailop wrote:
Well, it's both at the SMTP layer:Same level.
You are obviously as free to run your server(s) as you want as T-Online is to run their servers as they want.
I don't get your point, as that is what t-online.de is effectively doing.
There's no problem with the phone line / connection. The pone line / connection is working well enough for someone to rudely say something to you and hang up.
Try this: Does the taxi fail to take you to someone's house if the person opens their front door, sees it is you, and then slams the door in your face? -- Did the taxi fail to get you to the person's front door in any way?
Similarly, did the postal service fail to deliver a letter if the recipient sees who it's from and immediately tosses it into the trash?
Well, some...@t-online.de would now know, if that would have been a real SMTP session.It will prevent responses written into the void. That's a Good Thing™.
I'm not convinced of that. There are plenty of ways that someone could (inadvertently) cause one of your users to try to send a message to T-Online. The Reply-To: header comes to mind.
t...@rx.t-online.de is there to help T-Online users in these cases.
And who is to help your users when they send a message to T-Online? Perhaps via replying to a message from somewhere other than T-Online that had a Reply-To: directed to T-Online.
Yeah, so what you are saying is: because t-online.de has 12 millions more mailboxes, it is OK for them to mail my users but to block my user's responses at the same time? I disagree.
Nope. That's not at all what I said. Nor is it what I implied. I'm confident that you knew that too.
I do agree on that. Hence the move to make sure future postmasters will not be bothered _unless_ _their_ users initiate the conversation. It's, after all, not their fault that t-online.de is setup north-korean style.Less lost mail in my view _is_ better,
Lost tends to imply accidental.Conversely, you are consciously preventing email in an additional direction. So my opinion is that you are making things worse than they already are.
The flip side of the Reply-To: is someone sending to one of your users from their T-Online address and setting their Reply-To: to something else; maybe Proton Mail or Gmail.
therefore I completely disagree with your counting. See my reply to an test email I sent yesterday from @t-online.de to a test server of mine wait for expiry ...# mailq -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- 098221201B0 916 Thu Oct 20 21:07:45 some...@testmail.uu.org(host mx01.t-online.de[194.25.134.72] refused to talk to me: 554 IP=931.620.721.400 - A problem occurred. (Ask your postmaster for help or to contact t...@rx.t-online.de to clarify.))some...@t-online.de
Nice IP address lookalike. ;-)How long is that message going to sit in your queue? Given that it has a 554 response, I would have expected your MTA to have sent a DSN already.
This would have been prevented if some...@t-online.de would not have reached that mailbox in the first place. Getting the bounce directly that they cannot sent there, they might use another known email address of the receipient or revert to other means of contact. Or even reach out to tosa@rx to clarify the situation with testmail.uu.org's postmaster.
That assumption is predicated on the T-Online sender 1) receiving a DSN with your error message, 2) the sender understanding it, and 3) the sender being able to take other action.
As t-online.de is not likely to change their setup, the sanest approach is to limit the overall damage, which is to reject mail from t-online.de _unless_ they whitelisted one's sending IPs (as per SPF, most likely).
That is your opinion. It happens to be an opinion that I disagree with. -- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
