On 20.10.22 18:50, Grant Taylor via mailop wrote:
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.
Well, it's both at the SMTP layer:
t-online.de to me:
$ telnet mx00.t-online.de 25
Trying 194.25.134.8...
Connected to mx00.t-online.de.
Escape character is '^]'.
554 IP=478.944.843.488 - A problem occurred. (Ask your postmaster for help or
to contact [email protected] to clarify.)
Connection closed by foreign host.
Me to t-online.de:
$ telnet mx.uu.org 25
Trying 192.251.226.74...
Connected to mx.uu.org.
Escape character is '^]'.
220 mx.uu.org ESMTP Proxmox
helo something.uu.org
250 mx.uu.org
MAIL FROM:<[email protected]>
250 2.1.0 Ok
rcpt to:<[email protected]>
554 5.7.1 <[email protected]>: Sender address rejected: Sender domain not
setup to receive mail from here; contact [email protected] to whitelist the sender
IPs for this domain.
quit
221 2.0.0 Bye
Connection closed by foreign host.
Same level.
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?
I don't get your point, as that is what t-online.de is effectively doing.
The proposed configuration change only makes this visible and clear,
I disagree that it will make it visible.
Well, [email protected] would now know, if that would have been a real SMTP
session.
I doubt that it will make it clear.
It will prevent responses written into the void. That's a Good Thing™.
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.
[email protected] is there to help T-Online users in these cases.
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".
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.
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.
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.
P.S. Reach for / strive for better, don't settle for what we have. If at all
possible don't make things worse.
Less lost mail in my view _is_ better, 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 [email protected]
(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 [email protected] to clarify.))
[email protected]
-- 0 Kbytes in 1 Request.
This would have been prevented if [email protected] 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.
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).
-kai
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
