php SMTP via Protokoll ssl:// [SOLVED]

[Mutschas]

Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
(Probleme ohne KeyHelp-Bezug gehören ins Offtopic-Forum)


Server-Betriebssystem + Version
Debian 11.9 (64-bit)


Eingesetzte Server-Virtualisierung-Technologie
keine


KeyHelp-Version + Build-Nummer
24.0 (Build 3220)


Problembeschreibung / Fehlermeldungen
Seit dem Update auf 24.0 kann in php (getestet mit php 5.6) mittels SMTP-Mail keine Verbindung via dem Protokoll "ssl://" mehr hergestellt werden.

Beispiel
SMTP-Servernamen: ssl://mail.keyhelp.de
Port: 465

error.log:

Code: Select all

[proxy_fcgi:error] [pid 2419615:tid 140042837731072] (70007)The timeout specified has expired: [remote x.x.x.x:60095] AH01075: Error dispatching request to : (polling), referer: https://www.keyhelp.de

Erwartetes Ergebnis
Mail verschicken

Tatsächliches Ergebnis
Gateway Timeout
The gateway did not receive a timely response from the upstream server or application.

Schritte zur Reproduktion
php 5.6 Web-App mit SMTP-Funktion einrichten und den Server via ssl:// ansprechen.

Zusätzliche Informationen
Seit letztem Update ist das so. Konnte im Changelog dazu nicht wirklich was finden.

[Jolinar]

php 5.6 Web-App mit SMTP-Funktion

Nur mal so ins Blaue geraten...Möglicherweise gibt es Irgendwelche Inkompatibilitäten wegen völlig veralteter PHP Version (EOL 12/2018)...

[Mutschas]

Mir ist bewusst, dass sie veraltet ist. Die Moralkeule habe ich nicht geordert Zudem ist alt nicht immer schlecht.

Aber ja, mir war fast schon klar, dass dieses Argument kommt und daher habe ich den Test auch mit der "Standard-PHP-Version des Betriebssystems" 7.4.33 durchgeführt und es führt zum selben Ergebnis. Weiterhin steht im Changelog nicht, dass die genannte 5er-Version nicht mehr unterstützt wird. Sie wird ja auch weiterhin im Panel angeboten. Es gibt Gründe warum dies so ist und warum man sie nicht einfach entfernt. Nicht alle Software kann einfach so umgeschrieben werden.

Wie auch immer: "ssl://" wird seit php 4.3.0 unterstützt und gibt es auch in den 8er-Versionen.

Fakt ist, seit dem Update auf v24 geht es nicht mehr.

Gleicher Test auf einen externen SMTP-Server (T-Online) ebenfalls mittels "ssl://" klappt ohne Probleme (sowohl php 5.6 wie auch 7.4).
Nur die "ssl://"-Verbindung zum eigenen internen SMTP-Server klappt so leider nicht mehr seit dem Update.

[24unix]

Zudem ist alt nicht immer schlecht.

In Bezug auf Software schon, besonders in dem Fall.
5.x ist EOL, bekommt seit Jahren keine bugfixes mehr.

Wie auch immer: "ssl://" wird seit php 4.3.0 unterstützt und gibt es auch in den 8er-Versionen.

Fakt ist, seit dem Update auf v24 geht es nicht mehr.

Gleicher Test auf einen externen SMTP-Server (T-Online) ebenfalls mittels "ssl://" klappt ohne Probleme (sowohl php 5.6 wie auch 7.4).
Nur die "ssl://"-Verbindung zum eigenen internen SMTP-Server klappt so leider nicht mehr seit dem Update.

Welchen Port hast Du probiert?
StartTLS probiert?

[Jolinar]

Die Moralkeule habe ich nicht geordert

Die hab ich auch noch garnicht ausgepackt...Ich habe lediglich die Vermutung bezüglich möglicher Inkompatibilitäten geäußert, was ja bei so extrem alter Software durchaus im Rahmen des Möglichen wäre...

Es gibt Gründe warum dies so ist und warum man sie nicht einfach entfernt.

Dafür gibt es genau einen Grund...Damit Anbieter ihren Kunden in den Allerwertesten kriechen können, um sie als Kunden nicht zu verlieren.

Nicht alle Software kann einfach so umgeschrieben werden.

Das Argument lasse ich nicht gelten. Entweder paßt man Software selber an aktuelle Systeme an oder, wenn man nicht die Manpower hat, beauftragt man dies als Dienstleistung.
Alternativ wechselt man zu einer modernen und sicheren Software...

[24unix]

Das Argument lasse ich nicht gelten.

Wenn es IonCube nicht geben würde, wurde ich Dir Recht geben …

[Jolinar]

Wenn es IonCube nicht geben würde, wurde ich Dir Recht geben …

Wenn die fragliche Software mit Ioncube, Zend Guard, whatever verschlüsselt ist, dann tritt man dem Hersteller der Software gehörig auf die Füße...Oder (wie schon erwähnt) man wechselt die Software...

[24unix]

Wenn es IonCube nicht geben würde, wurde ich Dir Recht geben …

Wenn die fragliche Software mit Ioncube, Zend Guard, whatever verschlüsselt ist, dann tritt man dem Hersteller der Software gehörig auf die Füße...

So es den noch gibt …

Oder (wie schon erwähnt) man wechselt die Software...

Ist manchmal nicht möglich.

[Mutschas]

Ich möchte mich hier nicht über eine alte Version streiten, die de facto nicht mal etwas mit dem Problem zu tun hat. Please back to topic.

Ist manchmal nicht möglich.

Genau, danke.

[Alexander]

Ich habe mich soeben von einem Debian 11 System mittels ssl:// und tls:// mit einem Remote-Server verbunden und von dort aus E-Mails versendet. Habe sowohl neuere PHP-Versionen als auch PHP 5.6 eingesetzt und konnte bei keinem Versuch irgendwelche Probleme feststellen, alles funktionierte tadellos.

Hätte mich auch gewundert, denn diesbezüglich gab es keinerlei Änderungen mit Version 24.0.

Ich bin immer wieder überrascht, mit welcher Selbstverständlichkeit immer das vermeintlich letzte KeyHelp-Update an allem Schuld sein soll ...

@Mutschas, Kontrolliere ggf. einmal ob Firewall o.Ä. blockiert, oder poste den entsprechenden Code-Abschnitt.

-> Moved to Offtopic, da kein KeyHelp Problem

[Mutschas]

Hallo Alexander.

Remote-SMTP-Server funktionieren ja, siehe wie geschrieben externe SMTP-Server wie z.B. T-Online gehen.
Aber wenn ich den internen SMTP-Server (der auf dem gleichen KeyHelp-System läuft) kontaktiere, geht es nicht mehr.

Es tut mir leid, wenn du dich auf den Schlips getreten fühlst, aber anhand des Loggings konnte ich nachvollziehen, dass unmittelbar nach der Installation der 24er Version, die Möglichkeit via ssl:// aufgehört hat zu funktionieren - und zwar auf die Minute genau. Daher bin ich fest davon der Meinung, dass es an der 24er-Version oder anderen Komponenten, die mit der 24er-Version installiert wurden, liegen muss.

//Edit
Aus der mail.log konnte ich noch folgendes entnehmen:

Code: Select all

Mar  8 23:05:13 admin postfix/smtps/smtpd[2552700]: connect from abc.de.fg.de[x.x.x.x]
Mar  8 23:05:14 admin postfix/smtps/smtpd[2552700]: 0004D174A3BE: client=abc.de.fg.de[x.x.x.x], sasl_method=LOGIN, sasl_username=abc@def.de

Nach genau der letzten Log-Meldung, bleibt der Webserver hängen und gibt danach nur noch ein

Code: Select all

Gateway Timeout

The gateway did not receive a timely response from the upstream server or application.

aus. Im mail.log findet sich nichts weiteres.

@Mutschas, Kontrolliere ggf. einmal ob Firewall o.Ä. blockiert

Habe es via

Code: Select all

iptables -n -L

geprüft, es wird nichts geblockt, was nicht geblockt werden sollte.

[Alexander]

Ich kann auch lokal ohne Probleme mich verbinden und Emails versenden.

Poste doch einmal deinen Code.

[Mutschas]

Leider ist es mir nicht erlaubt, den Code zu veröffentlichen, kennst du ja sicherlich.

Ich habe zu Testzwecken zwei VM errichtet. Die erste mit KeyHelp-Version 23.2.1 danach ein Klon für die zweite VM inkl. Update auf Version 24.
Daraufhin habe ich die Konfigfiles verglichen, was geändert wurde. Da es ein Mail-Problem ist, habe ich mir zuerst einmal die Mail-Files angeschaut und dann in der postfix main.cf festgestellt, dass in der 24er-Version folgende zwei Einträge neu hinzugekommen sind:

Code: Select all

smtpd_forbid_bare_newline = yes
smtpd_forbid_bare_newline_exclusions = $mynetworks

Die $mynetworks sieht wie folgt aus:

Code: Select all

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

Kommentiere ich die zwei neuen Zeilen aus und starte den Postfix-Server neu, dann, tadda, können via ssl://meine.lokale.domain über Port 465 wieder Mails verschickt werden. Entferne ich die Kommentare und starte den Postfix-Server neu, dann können die Mails wieder nicht verschickt werden und es führt zu dem genannten Fehler.

Vielleicht hilft das noch bei der Ursachenforschung?

Danke.

//Edit
Füge ich in $mynetworks zusätzlich die Public-IP-Adresse des Servers ein, dann funktioniert der Mailversand.
Ist das so OK oder gibt es dadurch ein Sicherheitsrisiko?

[ShortSnow]

Moin,

die Zeile sind deswegen hinzugekommen: https://www.postfix.org/smtp-smuggling.html

Dann solltest Du Dein Script einmal überprüfen, ob es nicht am Ende einen falschen Zeilenumbruch gibt und das anpassen. Die Codezeilen zum versenden der Mail werden sicherlich kein großes Geheimnis sein. Soviel kann man da nicht variieren. Damit könnte man sicherlich helfen, das Script richtig zu stellen.

Gruß Arne

[Mutschas]

die Zeile sind deswegen hinzugekommen: https://www.postfix.org/smtp-smuggling.html

Danke dir, der Link half mir, es zu verstehen.
Tatsächlich lag es an dem Script, mit fehlendem "\r\n.\r\n" am Ende der Nachricht. Stattdessen gab es nur ein "\n.".
Man lernt nie aus und diese Sicherheitslücke ging an mir irgendwie vorbei...

Die Codezeilen zum versenden der Mail werden sicherlich kein großes Geheimnis sein.

Mag sein, dennoch stet es mir leider nicht zu (das Skript gehört mir nicht). Tut mir leid.

@Alexander
Es tut mir leid. dass ich das 24er-Update dafür verantwortlich gemacht habe. Aber da das Logging der Mails auf die Minute mit dem Update auf die 24er-Version übereinstimmte, ging ich davon aus - wobei wie geschrieben, entweder Keyhelp an sich, oder eines der mit dem Update aktualisierten Komponenten.

[...] dass es an der 24er-Version oder anderen Komponenten, die mit der 24er-Version installiert wurden, liegen muss.

Das Update der main.cf war der Auslöser.