Keine SMTP Verbindung ins Internet mehr möglich

[GrandDixence]

Wie unschwer auf der Webseite:

https://testtls.com/mx1.lhsystems.com/25

ersichtlich, hat mx1.lhsystems.com einige Probleme mit der Verschlüsselung (STARTTLS) der Kommunikation über TCP Port 25 (SMTP zwischen Mailservern).

Mit einem Internetanschluss von UPC-Sunrise funktioniert STARTTLS über TCP Port 25 (SMTP zwischen Mailservern) zu posteo.de einwandfrei:

# openssl s_client -CApath /etc/ssl/certs/ -starttls smtp -connect posteo.de:25
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = GeoTrust EV RSA CA 2018
verify return:1
depth=0 businessCategory = Private Organization, jurisdictionC = DE, jurisdictionST = Berlin, jurisdictionL = Charlottenburg, serialNumber = HRA 47592, C = DE, ST = Berlin, L = Berlin, O = Posteo e.K., CN = posteo.de
verify return:1
---

Zu mx1.lhsystems.com gibt es auch am Internetanschluss von UPC-Sunrise technische Probleme:

- Mit STARTTLS

-------------------------------------------------------------------------------------------------------------------------------

# openssl s_client -CApath /etc/ssl/certs/ -starttls smtp -connect mx1.lhsystems.com:25
CONNECTED(00000003)
Didn't find STARTTLS in server response, trying anyway...
write:errno=0
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 225 bytes and written 352 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

- Ohne STARTTLS

--------------------------------------------------------------------------------------------------------------------------------------

# openssl s_client -CApath /etc/ssl/certs/ -connect mx1.lhsystems.com:25
CONNECTED(00000003)
140494734500480:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:332:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 319 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

Über einen Internetanschluss von Swisscom funktioniert STARTTLS über TCP Port 25 (SMTP zwischen Mailservern) gar nicht. Auch nicht zu posteo.de. Somit ist dies klar ein hausgemachtes Problem vom ISP Swisscom.

Ein SSL-Proxy ist erforderlich für die Filterung des verschlüsselten Datenverkehrs (zum Beispiel: HTTPS -> TCP Port 443). Meine Haltung zu SSL-Proxies habe ich unter:

https://www.lancom-forum.de/fragen-zur-lancom-systems-routern-und-gateways-f41/probleme-mit-weiterle...

kundgetan.

Die Unterstützung von STARTTLS über TCP Port 25 (SMTP) ist für jeden seriösen ISP aus Sicherheitsgründen Pflicht.

https://www.golem.de/news/verschluesselung-sicherheitsrisiko-starttls-2108-158714.html

https://www.golem.de/news/starttls-keine-verschluesselung-mit-der-spd-1607-122291.html

https://www.golem.de/news/smtp-mta-sts-bringt-sichere-verschluesselung-zwischen-mailservern-1809-136...

[ChrisO]

Den da haben sie zugänglich gelassen, wass immer der Grund sein mag:

osk@server:~$ telnet mail.hostcenter.com. 25
Trying 193.246.38.134...
Connected to mail.hostcenter.com.
Escape character is '^]'.
220-mail.atomia.hostcenter.com ESMTP Postfix (Ubuntu)
220 mail.atomia.hostcenter.com ESMTP Postfix (Ubuntu)
helo me
250 mail04.atomia.hostcenter.com

...

[SkyBeam]

Ohne jetzt Öl ins Feuer dieser hitzigen Diskussion schütten zu wollen... Aber zu einer Verbindung gehören immer zwei Enden. Es ist durchaus auch möglich, dass der gewünschte SMTP Server auf Port 25 nur Verbindungen aus gewissen IP-Bereichen erlaubt. Insbesondere haben einige Mail-Provider wohl schon länger Verbindungen direkt auf Port 25 aus Endkunden IP-Segmenten unterbunden.

Port 25 wird eigentlich nur noch für die Kommunikation der Mail-Provider untereinander verwendet. Clients sollten die SSL (465) oder CLient-Submission Ports (587) verwenden. Deswegen blockieren einige Mail-Provider Server alles auf Port 25 von unbekannte4n Servern oder zumindest aus Endkunden-Bereichen.

Wer natürlich einen Mail-Relay oder Mailserver an einem Endkunden-Anschluss betreiben will hat damit ein Problem. Im Besten Fall werden die Mails potentiell als Spam eingestuft und im schlechtesten Fall gleich verworfen oder die Verbindung blockiert.

Wenn es von einem anderen Provider aus geht kann das auch daran liegen, dass deren Client-IP-Bereiche (noch) nicht auf der schwarzen Liste des Server-Betreibers stehen.

Vielleicht wäre es hier mittelfristig wirklich die bessere Alternative sich eine günstige Cloud-Instanz irgendwo zuzulegen um den Mail-Relay da drauf zu verlegen.

[Roger G.]

@ChrisO Ich hab es kurz mit unseren Spezialisten abgeklärt. Es gab einen Zeitraum, wo der Port25 aufgrund einer Anpassung völlig gesperrt wurde. Dies war nicht in unserem Sinne und wurde nun wieder so umgebaut, dass der Redirect zum Security Server wieder funktioniert. Aber wichtig ist: Alles, was nach SPAM aussieht, wird auch geblockt.

Grundsätzlich sollte man Mail bei einem ausgehenden Mailversand via SMTP auf Port 465 oder 587 einstellen.

Es gibt einige Anbieter die haben Port 25 vollständig unterbunden. Zum Beispiel Google: https://cloud.google.com/compute/docs/tutorials/sending-mail/

Viele Grüsse

[ChrisO]

@Roger G.
> Ich hab es kurz mit unseren Spezialisten abgeklärt.
Schön für Dich, ich kann die aber nich kontaktieren, postmaster@swisscom.com ist ein Schwarzloch.

Als ich noch für/bei Swisscom gearbeitet habe, waren die Spezialisten etwas anders, jetzt kaufen sie alles
was ihnen M$ (antispam: Redirect zum Security Server) und andere Internet "experten" verkaufen.
Eine schöne Reise nach US und schon "schützt" proofpoint.com die Swisscom vor Spammers:

osk@opi-r1:~$ telnet mail10.swisscom.com. 25
Trying 138.188.176.225...
Connected to mail10.swisscom.com.
Escape character is '^]'.
554 Blocked - see https://ipcheck.proofpoint.com/?ip=89.186.19.239

proofpoint.com reagiert auf Anfragen so gut wie Swisscom.
Traurig.

> "Es gibt einige Anbieter die haben Port 25 vollständig unterbunden.Zum Beispiel Google"

Google, sprich gmail.com gar nicht:

osk@opi-r1:~$ dig gmail.com mx

; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> gmail.com mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54735
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;gmail.com. IN MX

;; ANSWER SECTION:
gmail.com. 1000 IN MX 30 alt3.gmail-smtp-in.l.google.com.
gmail.com. 1000 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 1000 IN MX 20 alt2.gmail-smtp-in.l.google.com.
gmail.com. 1000 IN MX 40 alt4.gmail-smtp-in.l.google.com.
gmail.com. 1000 IN MX 10 alt1.gmail-smtp-in.l.google.com.

osk@opi-r1:~$ telnet alt3.gmail-smtp-in.l.google.com. 25
Trying 142.250.141.27...
Connected to alt3.gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP t13si5070892vsn.210 - gsmtp
helo me
250 mx.google.com at your service
quit
221 2.0.0 closing connection t13si5070892vsn.210 - gsmtp
Connection closed by foreign host.

Versuch das auf die Ports 465 oder 587.
Oder noch besser, versuch bitte die Aussage: "Grundsätzlich sollte man Mail bei einem ausgehenden Mailversand via SMTP auf Port 465 oder 587 einstellen" mir zu erklären, direkt, ohne Verweise auf andere Quellen.

Würde mich gerne mit Swisscom's e-Mail Spezialisten über diese Sachen unterhalten, kann auch ohne leben.
Bin mittlerweile ausgewandert, hab' kein Internetzugang von Swisscom mehr. Mails an ehemalige Swisscom Kollegen kann ich auch von meinem zweiten Anschluss versenden.
Bleibt nur ein bitterer Nachgeschmack....

Grüsse
ChrisO

[Hientagreu14]

Nein, das ist nicht korrekt!

[ChrisO]

Wau, ein ganzes Satz kannst du schon sagen!