nicht angemeldet
Mailversand mit der php-Funktion mail() klappt nicht
Hallo, ich möchte den mailversand auf meinem lokalen Rechner testen. Installiert habe ich XAMPP/Apache mit dem Mercury-Server. Wenn ich die Funktion mail() aufrufe, erhalte ich den Fehler
Failed to connect to mailserver at "localhost" port 25, verify your "SMTP" and "smtp_port" setting in php.ini
In der php.ini steht
[mail function]
; For Win32 only.
; http://php.net/smtp
SMTP=localhost
; http://php.net/smtp-port
smtp_port=25
Was muss ich denn in der php.ini ändern?
-
Tach!
Failed to connect to mailserver at "localhost" port 25, verify your "SMTP" and "smtp_port" setting in php.ini
Was muss ich denn in der php.ini ändern?
Na, das was richtig ist. Hilft jetzt nicht viel, diese Aussage. Aber viel mehr kann man dazu nicht sagen. Wenn der Mailservr auf dem Localhost auf Port 25 lauscht, dann sind das genau die richtigen Angaben. Aber vielleicht lauscht er gar nicht, oder nicht dort. Ist er denn gestartet? Sieht man bei einem
netstat -an -p tcpetwas auf Port 25 lauschen?dedlfix.
-
Hallo netstat -an -p tcp liefert folgendes, das mir allerdings nichts sagt:
-
Tach!
netstat -an -p tcp liefert folgendes, das mir allerdings nichts sagt:
Links sind die lokalen Endpunkte, die in dem Fall interessieren. Hinter dem Doppelpunkt steht der Port. Keine 25 zu sehen, also läuft da auch kein Mailserver. Der Apache auf Port 80 und 443 ist aber da.
dedlfix.
-
Installiert habe ich XAMPP/Apache mit dem Mercury-Server.
Der Mercury-Server ist der Mailserver. Bei diesem merkwürdigen und von mir nicht empfohlen Bundle(*) muss der eben so wie der Apache und der Datenbankserver explizit gestartet werden. Womöglich beendet der sich aber gleich wieder, weil er noch nicht konfiguriert ist.
*) Ich halte virtuelle Maschinen mit einem Linux (z.B. einem Debian minimal und nachinstallieren Diensten wie ssh, apache2, exim4, mariadb) und natürlich php für die weitaus bessere Lösung. Grund: Das kommt als Testsystem näher an die Realität. Die virtuelle Maschine würde ich nicht über die "hakelige" Oberfläche von z.B. Virtual Host ansprechen sondern mittels Putty. Das ist realitätsnäher und bequemer.
-
Ich habe jetzt zwei Ergebnisse, links vor Start Mercury, rechts nach dem Start. Es werden dann einige Ports mehr benützt. Aber welchen gebe ich in der PP.ini an?
-
Den Port 587. Das ist der Port über den Mails zwischen Clients und Servern verschlüsselt übertragen werden.
Kann das Dein PHP (ist in dem Fall der Client) nicht, dann musst Du dem Mercury mitteilen, dass er den Port 25 für den Localhost (bisher üblich: 127.0.0.1 oder, moderner: 127.0.0.25) für die lokale, unverschlüsselte Kommunikation öffnen soll. Wenn du den Mercury auf auf der IP 127.0.0.25 und dem Port 25 lauschen lassen wisst, brauchst Du folgendes in der PHP.ini:
[mail function] ; For Win32 only. ; http://php.net/smtp SMTP=127.0.0.25 ; http://php.net/smtp-port smtp_port=25Eines noch: Mach Dir keine Hoffnung: Ohne "Smarthost" geht da sehr überwiegend wahrscheinlich kein Mail ins Internet. (Falls doch läuft da sehr überwiegend wahrscheinlich was Gewaltiges falsch!)
Entweder konfigurierst Du einen "Smarthost" oder Du schickts alle Mails nur an den Lokalhost und holst diese mit Deinem Client dann auch bei dem ab.
-
Den Port 587. Das ist der Port über den Mails zwischen Clients und Servern verschlüsselt übertragen werden.
Hat nicht funktioniert.
Wenn du den Mercury auf auf der IP 127.0.0.25 und dem Port 25 lauschen lassen wisst, brauchst Du folgendes in der PHP.ini:
[mail function] ; For Win32 only. ; http://php.net/smtp SMTP=127.0.0.25 ; http://php.net/smtp-port smtp_port=25Leider auch erfolglos
Eines noch: Mach Dir keine Hoffnung: Ohne "Smarthost" geht da sehr überwiegend wahrscheinlich kein Mail ins Internet. (Falls doch läuft da sehr überwiegend wahrscheinlich was Gewaltiges falsch!)
Entweder konfigurierst Du einen "Smarthost" oder Du schickts alle Mails nur an den Lokalhost und holst diese mit Deinem Client dann auch bei dem ab.
Ich möchte auch nicht, dass diese mails ins Internet gehen.
-
Hat nicht funktioniert.
... ist keine Fehlerbeschreibung.
Leider auch erfolglos
- Lokale Firewall? Deaktivieren oder Mercury das Listen erlauben.
- Mercurry neu starten!
- Apache neu starten! PHP läuft wohl als Modul und liest die ini nur wenn es neu gestartet wird. Das macht dann der Apache.
Geht nicht?
- Untersuche dann ob der Mercury auf Port 25 listet.
Wenn nicht versuche es beim Server und beim Client mit 127.0.0.1, Port 25. Prozedere von vorn.
-
Hat nicht funktioniert.
... ist keine Fehlerbeschreibung.
Damit ist gemeint, dass sich am Ergebnis nichts geändert hat, sonst hätte ich geschrieben "Jetzt kommt der Fehler.....
-
-
-
Tach!
Ich habe jetzt zwei Ergebnisse, links vor Start Mercury, rechts nach dem Start. Es werden dann einige Ports mehr benützt. Aber welchen gebe ich in der PP.ini an?
Welches Protokoll auf einem bestimmten Port läuft, kann man so ohne weiteres nicht sehen. Du braucht denjenigen Port, der für SMTP konfiguriert ist. 25 ist der Standardport. Alle anderen verwenden üblicherweise andere Protokolle, beispielsweise mit irgendeinem Verschlüsslungsverfahren. Die Portnummern können aber beliebig vergeben werden. SMTP muss nicht zwingend auf Port 25 laufen. Es kommt also darauf an, was einerseits Default dafür bei Merqury ist, andererseits, was abweichend davon konfiguriert wurde. XAMPP sollte eigentlich von Haus aus passend konfiguriert sein. Deswegen bauen die ja dieses Komplettpaket.
dedlfix.
-
XAMPP sollte eigentlich von Haus aus passend konfiguriert sein.
Nicht unbedingt. Es könnte ja ein Mailserver existieren... dann wäre die "passende" Konfiguration falsch. Dafür gibt es sicherlich auch einen Abschnitt zum Thema "Mail" im Handbuch...
-
Tach!
XAMPP sollte eigentlich von Haus aus passend konfiguriert sein.
Nicht unbedingt. Es könnte ja ein Mailserver existieren...
Das ist kein Grund, Merqury anders zu konfigurieren. Er muss ja dann nur nicht gestartet werden, wenn bereits eine Alternative existiert. Zwei Mailserver laufen zu haben, ergibt auch nicht unbedingt einen Sinn.
dedlfix.
-
Das ist kein Grund, Merqury anders zu konfigurieren.
Doch gibt es einen: Die Anwender zu zwingen, ins Handbuch zu schauen.
-
-
XAMPP sollte eigentlich von Haus aus passend konfiguriert sein.
Dafür gibt es sicherlich auch einen Abschnitt zum Thema "Mail" im Handbuch...
Leider finde ich kein solches Handbuch
-
Dafür gibt es sicherlich auch einen Abschnitt zum Thema "Mail" im Handbuch... Leider finde ich kein solches Handbuch
Dann hast Du ein Problem. "Kein Handbuch" ist das erste und ein sehr ernstes Anzeichen für "Ganz großer Mist". Ich verweise Dich nochmals auf die bessere Idee, Debian ausgehend vom minimal.iso einer virtuellen Maschine (Virtual Box wäre kostenlos und genügt Dir) zu installieren.
Willst Du es moderner nimm den Ubuntu-Server.
Dann einloggen und folgende Befehle ausführen:
sudo su echo -e "\nAdresse: \\4 \\6" >> /etc/issue apt update apt full-upgrade apt install openssh-server apache2 php mariadb-server exim4-daemon-light mailutilsBeim Setup von exim4-daemon-light kommt eine Zwischenfrage. Wähle "lokale Mailzustellung". Die virtuelle Maschine einmal neu booten wenn (ich erwarte das) ein neuer Kernel beim Upgrade mit geliefert wurde.
Dann musst Du Dich nicht mit undokumentiertem Mist herumschlagen. Bequem zu bedienen mit Putty, Datenübertragung mit WinSCP - alles wie bei einem richtigen Webserver. Die IP siehst Du dank des Eintrags in der Datei /etc/issue nach dem Booten.
- Die Konfig liegt unterhalb von /etc/
- Die Webseiten liegen erst mal unter /var/www/html
- Mails lesen und löschen mit
mailin einem Terminal. Gefällt Dir nicht? installiere und nimm "mutt".
-
Nachdem ich seit meine Anwendungen unter XAMPP/Apache unter Windows teste, möchte ich mir jetzt nicht neue Hürden mit Unix-Derivaten aufbauen. Schließlich lief ja der mailserver schon einmal tadellos.
-
Nachdem ich seit meine Anwendungen unter XAMPP/Apache unter Windows teste,
Nachdem die Medizinmänner seit 30.000 Jahren aus der Asche der Knochen die Zukunft voraussagen brauchen wir weder Schrift noch Wetterbericht.
Etwas richtig zumachen ist besser als sich mit der Behebung des Mists schlecht gepflegter Softwaremixe zu befassen. Auch sind die Test dann realitätsnah. Anders ausgedrückt:
"Hör auf zu murksen - mach es GLEICH richtig!"
(Und das sagt Dir jemand, der Dein Problem ganz gewiss auch unter Windows - wenn er denn davor säße - "mit ein wenig Tastengeklapper und zwei Mal Maus schubsen" lösen könnte.)
-
(Und das sagt Dir jemand, der Dein Problem ganz gewiss auch unter Windows - wenn er denn davor säße - "mit ein wenig Tastengeklapper und zwei Mal Maus schubsen" lösen könnte.)
Ach, wie mag ich diese wenn-Angeberei! Und ich, das sagt Dir jemand, der von Unix keine Ahnung hat, würde das Problem auch lösen, wenn ich vor Deinem PC säße.
-
… würde das Problem auch lösen
Meine Rede! Ist kinderleicht, weil es dokumentiert ist und die Konfiguration von sowas in menschen- und maschinenlesbaren Textdateien steht und weil es neben brauchbaren Dokumentationen (sonst nimmt kein Distributor eine Software in die Distribution auf) vernünftige, menschenlesbare Logfiles gibt. Mach einfach!
wenn ich vor Deinem PC säße
Nana! Glaubst Du wirklich, ich würde es zulassen, dass sich hier (auf einem Produktivsystem mit vertraulichen Daten) Gäste anmelden?
Und ich, das sagt Dir jemand, der von Unix keine Ahnung hat,
Tja. Ich habe zwar über Windows schon mehr vergessen als manch anderer überhaupt weiß oder noch erfahren wird - aber wie die Dinge liegen sind das Netzwerkzeug und Begriffe wie "Dienste" sehr weitgehend OS-unabhängig. Und manches ist wie Radfahren oder Schwimmen. Einmal gelernt kann man das eben.
Ach, wie mag ich diese wenn-Angeberei!
Das hat weniger mit Angeberei zu tun als mit dem Bemühen, Dir darzustellen, dass derjenige, der Dir sagt, dass Du besser eine virtuelle Maschine mit Linux nehmen sollst, sehr genau weiß wovon er spricht und nicht nur dazu rät weil er es unter Windows nicht kann.
-
-
-
-
-
-
Hi,
XAMPP sollte eigentlich von Haus aus passend konfiguriert sein. Deswegen bauen die ja dieses Komplettpaket.
Das war XAMPP offensichtlich auch, da es vor längerer Zeit funktionierte.
-
Tach!
XAMPP sollte eigentlich von Haus aus passend konfiguriert sein. Deswegen bauen die ja dieses Komplettpaket.
Das war XAMPP offensichtlich auch, da es vor längerer Zeit funktionierte.
Im Mecury muss unter Configuration → Protocol Modules der Haken bei SMTP Server gesetzt sein, dann läuft das bei mir problemlos nach einem Neustart von Mercury, falls es vorher deaktiviert war.
dedlfix.
-
-
-
-
-
-
