Am 20.10.22 um 21:44 schrieb Grant Taylor via mailop:
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.
Ah, you're saying I mustn't be as rude to a specific caller as it is to me?
Nah, doesn't compute.
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.
And someone may find the formula for love and peace for anyone — that's not the
point.
---8<---
Betreff: Undelivered Mail Returned to Sender
Von: mailer-dae...@mailout10.t-online.de (Mail Delivery System)
Datum: 20.10.22, 22:18
An: some...@t-online.de
This is the mail system at host mailout10.t-online.de.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<wusel...@uu.org>: host mx.uu.org[192.251.226.74] said: 554 5.7.1
<some...@t-online.de>: Sender address rejected: Sender domain not setup
to receive mail from here; contact t...@rx.t-online.de to whitelist the
sender IPs for this domain. (in reply to RCPT TO command)
--->8---
_That_ is the point: if something like that would become the default for any
new installation of Exim or Postfix (is Sendmail still a thing?), lost
communication *would* *effectively* be reduced: the t-online.de customer would
be informed of limited communication, read: they see their mail didn't make it
and would react in one way or another.
It's not the final solution. But it's a much better situation compared to now,
where above mail would make it to the receipient, and the _receipient_ would
not be able to reply, leaving the initial sender without the requested
information, considerung the receipient lazy, rude, whatever — email, unless
sent from monitoring systems, is usually a two-way-communication. t-online.de
does not allow for that per default, so one just shouldn't accept their
messages.
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?
In the proposed setup, mail to @t-online.de bounces back with a message pointing to the
local postmaster with a similar message ("have your postmaster to contact tosa@rx…
to mutually agree on terms for mail exchange").
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.
Then you are in error, therefore please explain what you meant with:
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".
With the very specific message at hand ... they still might ignore the facts. BUT: THEY
got the error message, THEY know the message didn't make it to the receipient. And THEY
can immediately choose other means of communication since "mail is broken
again" (courtesy of t-online.de, I'd love to add).
Less lost mail in my view _is_ better,
Lost tends to imply accidental.
As for the sender that is blocked by t-online.de, it feels as being accidental
— we know it's not, but this does not help anyone.
Conversely, you are consciously preventing email in an additional direction.
So my opinion is that you are making things worse than they already are.
Your opinion is flawed from my point of view. I only put those things right
which t-online.de's policy breaks, that's the basic idea.
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.
I dont't talk about Reply-To; it's an irrelevant twist. The real world szenario is that
some...@t-online.de mails to i...@verein.de ("verein" means association, club,
…), verein.de does run it's own mailserver as it's cheaper than using some SP for it.
verein.de runs basically default settings – which usually are good –, thus *not* blocking
mails from @t-online.de, hence i...@verein.de receives the mail and reponds to it. *BÄM*
554.
If Exim, Postfix, ... *properly* would _reject_ mails from @t-online.de _by default_ –
unless t...@rx.t-online.de and the local postmaster agreeed on exchanging mails as per
t-online.de's policy and idea on how email works, at which point the local postmaster
could and should fix the default configuration –, the mail from some...@t-online.de would
have bounced properly at t-online.de's servers, making the t-online.de customer *aware*
that it cannot communicate with i...@verein.de "this way" (because of silly
decisions of t-online.de, but that they only learn in the course of time).
So, some...@t-online.de would understand it cannot sent to i...@verein.de. What
happens next is unknown; but _at least_ some...@t-online.de never ever expects
a reply from i...@verein.de! This Is Good™!
Deutsche Telekom/t-online.de doesn't care. But both, some...@t-online.de and
i...@verein.de, do! And therefore, blocking mails from @t-online.de per default
IS. A. VERY. GOOD. THING. Actually, for mail in general.
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. ;-)
Thanks. Actually, if you shuffle them around a bit, you get the real one this
time ;)
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.
Same would I, turns out:
https://www.postfix.org/postconf.5.html#smtp_skip_5xx_greeting
*smtp_skip_5xx_greeting (default: yes)*
Skip remote SMTP servers that greet with a 5XX status code.
By default, the Postfix SMTP client moves on the next mail exchanger. Specify
"smtp_skip_5xx_greeting <https://www.postfix.org/postconf.5.html#smtp_skip_5xx_greeting> =
no" if Postfix should bounce the mail immediately. Caution: the latter behavior appears to
contradict RFC 2821 <https://tools.ietf.org/html/rfc2821>.
Hence, if a Postfix with default settings hits a t-online.de MX and isn't
whitelisted yet – which roughly accounts to 99.9% of the IPv4 space –, there
will be a ~5 day(!) delay between message sending and final failure
notification. Great.
Anyone still objecting to reject from t-online.de by default? If so, I want
some of your weed!
t-online.de is the only known mail service that does greet with 554 *by
default*; in any other case, a 5xx greeting *is* a remote failure and retrying
another MX *is* a sane operation. Let's call t-online.de what it is: a
troublemaker, an outcast, a misfit.
https://www.rfc-editor.org/rfc/rfc2821#page-45
554 Transaction failed (Or, in the case of a connection-opening
response, "No SMTP service here")
"No SMTP service here"; maybe DNS TTL issues? Unless it's the only MX, retrying
other MXes after a 554 gretting IS a sane thing to do. But nobody expected the Deutsche
Telekom ... that never cared about understanding SMTP.
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.
They do not receive a DSN, they receive a proper "this didn't work at all" message, see above.
Basically anyone understands "Undelivered Mail Returned to Sender" these days, even Germans, and
even readers of "ComputerBild" or customers of T-Online.
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.
I'm totally fine with you disagreeing with my opinion. After all, you aren't
impacted as I by the irresponsible and erratic way t-online.de is running their
service, which indeed has a high locallity.
-kai
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
