mail () funktioniert nicht mehr

Der_Jan

Aktives Mitglied
Thread Starter
Dabei seit
06.01.2004
Beiträge
711
Reaktionspunkte
30
Moin zusammen,
ich habe heute ein seltsames Problem auf dem Projekt www.holzwirtschaft.org entdeckt. Die Seite ist in Eigenarbeit gecodet und hat in den letzten Monaten soweit problemlos funktioniert.

Heute habe ich nun festgestellt, dass keine Seite mit integrierter mail()-Funktion mehr funktioniert. Der Browserball dreht sich zwar hübsch, abgearbeitet wird die Funktion jedoch nicht. Hätte ich nun an einer Seite etwas verändert (was ich nicht habe), könnte ich es mir selber erklären - aber hier funktioniert keine mail()-Funktion mehr, sodaß ich an ein serverseitiges Problem glaube. Da Servertechnik nicht gerade meine Stärke ist, hab ich keine Ahnung, wie ich diesen Effekt beurteilen soll und vor allem beheben kann.

Wäre sehr dankbar, wenn mir hier jemand nen Tipp geben könnte, wo man den Fehler suchen kann.

Gruß
Der Jan

P.S.: Bitte jetzt nicht wie wild die Mailfunktionen austesten. Wenn Ihr es auf einen Test ankommen lassen wollt, dann bitte hier
 
Zuletzt bearbeitet:
Ausfall des Mailservers?
Gibt mail() irgendeine Fehlermeldung aus? Wenn du @mail() verwendest, mach mal das @ weg und poste hier die Ausgabe.
 
Leider keine Fehlermeldung.

Mails verschicke ich (wenn es denn klappt :)) über

mail("$an","$betreff","$inhalt","From: $avorname $anachname <$aemail>");

Gruß
Der Jan
 
Zuletzt bearbeitet:
SaC schrieb:
Ausfall des Mailservers?
...

Um den Onlinestatus des Mailservers zu prüfen, kann ich folgenden Codeschnipsel anbieten:
PHP:
<?php
    $server="mail.provider.com:25";
    echo "<h3>Status Mailserver</h3>";
    $check=explode(":",$server);
    if (@fsockopen($check[0],$check[1],&$errno, &$errstr, 2))
    {
    echo "Mailserver is <font color=green><b>Online</b></font><br>";
    }
    else    
    {
    echo "Mailserver is <font color=red><b>Offline</b></font><br>
    Es k&ouml;nnen derzeit leider keine Mails gesendet werden";
    exit;   
    };
?>

Man muss nur noch "mail.provider.com" durch den zuständigen Mailserver ersetzen.
Ich setze das auf meinem Mailformular ein;
Die Formularseite wird so nur dann aufgerufen, wenn der Mailserver auch verfügbar ist.

HTH
 
Kann's sein, dass Dein Provider sein PHP aktualisiert hat? Ab ner bestimmten Version kann man die Variablen, die von dem Kontaktformular eine Seite vorher kommen nicht mehr einfach weiterbenutzen, sondern muss sie sich erst wieder „holen“:

Kontaktformular:
PHP:
<form action="mail.php" method="post">
<input name="Feld1" />
<input type="submit" />
</form>

Wenn Du das jetzt los schickst, kannst Du im nächsten Schritt nicht einfach mehr die Variable $Feld1 nehmen, sondern musst $_POST['Feld1'] nehmen.

Im Grunde kannst Du auch im neuen Dokument schreiben
$Feld1=$_POST['Feld1'];
Dann klappt der Rest ohne Umschreiben.

Wenn Die Variablen per Get (über die Adresszeile) weitergegeben werden, brauchst Du natürlich $_GET['…'].

Das man nie Post- und Get-Variablen trauen soll, überlass ich jetzt mal jemand anderem :)
 
Der Tipp von Jakob ist ziemlich gut! Zumal in neueren PHP-Versionen die alten arrays $HTTP_POST_VARS und $HTTP_GET_VARS nicht mehr mit Werten belegt werden. Viele Programme nutzen noch diese alten Variablen. Ab PHP5 muß dazu in der php.ini ein Wert gesetzt werden, wenn noch die alten arrays verwendet werden!
 
Jakob schrieb:
Kann's sein, dass Dein Provider sein PHP aktualisiert hat? Ab ner bestimmten Version kann man die Variablen, die von dem Kontaktformular eine Seite vorher kommen nicht mehr einfach weiterbenutzen, sondern muss sie sich erst wieder „holen“:

Kontaktformular:
PHP:
<form action="mail.php" method="post">
<input name="Feld1" />
<input type="submit" />
</form>

Wenn Du das jetzt los schickst, kannst Du im nächsten Schritt nicht einfach mehr die Variable $Feld1 nehmen, sondern musst $_POST['Feld1'] nehmen.

Im Grunde kannst Du auch im neuen Dokument schreiben
$Feld1=$_POST['Feld1'];
Dann klappt der Rest ohne Umschreiben.

Wenn Die Variablen per Get (über die Adresszeile) weitergegeben werden, brauchst Du natürlich $_GET['…'].

Das man nie Post- und Get-Variablen trauen soll, überlass ich jetzt mal jemand anderem :)

Das nennt sich "Global Values" und ist in PHP5 standardmäßig nicht mehr aktiviert, korrekt. Kann man in der php.ini aber wieder neu machen :D
 
Ist auch schon ab einer 4.x deaktiviert und das aus gutem Grund. Ich würd's deaktiviert lassen. An das bisschen deklarieren gewöhnt man sich schnell und es ist sicherer.
 
wegus schrieb:
Zumal in neueren PHP-Versionen die alten arrays $HTTP_POST_VARS und $HTTP_GET_VARS nicht mehr mit Werten belegt werden.

Das ist nicht richtig.
 
@Nogger: doch, daß ist es leider wohl! Du muß extra in der php.ini einen Wert auf yes setzen (Bezeichner muß ich nachschlagen), sonst sind diese Felder IMMER leer und $_POST/$_GET als neue Arrays nat. nicht.
Ich bin selbst mit einer phpBB-Version und noch einer anderen Applikation ( ich glaub es war Mambo) darauf hereingefallen. Daraufhin hab ich es ausprobiert und es ist so - bei PHP 5.03 und PHP 5.04 hab ich selbst erlebt. Der default steht so, daß die long_arrays nicht belegt werden in der php.ini! Die long-arrays gelten als deprecated laut PHP.

Btw: ich laß mich wirklich gern korrigieren, aber dann bitte mit der Aussage wie es denn nun richtig ist! Ich merke und finde meine Fehler durch lange Erfahrung selbst. Andere die hier lernen wollen vielleicht nicht und denen ist mit einem richtig oder falsch allein eher selten geholfen!
 
wegus schrieb:
Du muß extra in der php.ini einen Wert auf yes setzen (Bezeichner muß ich nachschlagen), sonst sind diese Felder IMMER leer und $_POST/$_GET als neue Arrays nat. nicht.

Die Arrays werden normalerweise belegt, weil der Standardwert "yes" ist. Das wollte ich nur sagen. Gut, war was knapp, gebe ich zu :)
 
Ihr habt beide Recht. Kommt auf die Installation an. Wenn man die empfohlene nimmt, ist es deaktiviert.

Also hat wegus bisschen Rechter. :)
 
Also hat wegus bisschen Rechter. :)

Nix da :)

In der standard php.ini (php.ini-dist im CVS) steht "register_long_arrays = On". Der einkompilierte Wert, wenn die Zeile nicht drinstände, ist auch "On".

Der Benutzer hat eine andere ini-Datei verwendet (php.ini-recommended), in der die Option auf "Off" gesetzt ist. Das wäre nicht schlimm, wenn er wenigstens reingeschaut hätte, was denn so drinsteht. Dann hätte er auch gelesen:

; This file is different from the php.ini-dist file in the fact that it features
; different values for several directives, in order to improve performance, while
; possibly breaking compatibility with the standard out-of-the-box behavior of
; PHP. Please make sure you read what's different, and modify your scripts
; accordingly, if you decide to use this file instead.
[...]
; - register_long_arrays = Off [Performance]
; Disables registration of the older (and deprecated) long predefined array
; variables ($HTTP_*_VARS). Instead, use the superglobals that were
; introduced in PHP 4.1.0

Wenn man die Funktion explizit ausschaltet, dann funktioniert es natürlich nicht.

Deshalb ist die Aussage "Zumal in neueren PHP-Versionen die alten arrays $HTTP_POST_VARS und $HTTP_GET_VARS nicht mehr mit Werten belegt werden. [...]. Ab PHP5 muß dazu in der php.ini ein Wert gesetzt werden, wenn noch die alten arrays verwendet werden!" falsch.

Auch in neueren Versionen werden standardmäßig die alten Arrays mit Werten belegt, und man muß auch dafür nichts in der php.ini ändern.
 
Ähm Nogger,
nachdem nun klar ist woran es liegt, ist es doch wohl eher zweitrangig wer da wie recht hat oder? Laut php.net ist die Version von entropy.ch die Standardbinary für Mac OS und da ist es nunmal deaktiviert. Egal wer es gemacht hat und warum. Da das hier ein Mac-Forum ist, dürften viele in diese Falle laufen. Laß uns doch nicht um des Kaisers Bart streiten ( zumal es den zug. Kaiser ja nicht mehr gibt ;) ).
Wichtig ist, daß man diese Option kennt und das die Leute mal wieder für die php.ini sensibilisiert sind! Da stehen ja noch viel mehr spannende Sachen darin. Zum recht haben oder bekommen sind wir doch wahrlich nicht hier!
 
maceis schrieb:
Um den Onlinestatus des Mailservers zu prüfen, kann ich folgenden Codeschnipsel anbieten:
PHP:
<?php
    $server="mail.provider.com:25";
    echo "<h3>Status Mailserver</h3>";
    $check=explode(":",$server);
    if (@fsockopen($check[0],$check[1],&$errno, &$errstr, 2))
    {
    echo "Mailserver is <font color=green><b>Online</b></font><br>";
    }
    else    
    {
    echo "Mailserver is <font color=red><b>Offline</b></font><br>
    Es k&ouml;nnen derzeit leider keine Mails gesendet werden";
    exit;   
    };
?>

Man muss nur noch "mail.provider.com" durch den zuständigen Mailserver ersetzen.
Ich setze das auf meinem Mailformular ein;
Die Formularseite wird so nur dann aufgerufen, wenn der Mailserver auch verfügbar ist.

HTH

Mittlerweile ist klar, dass mein Provider tatsächlich an dem besagten Tag Probleme mit dem Mailserver hatte. Aus Neugierde habe ich Deinen Schnipsel mal getestet, und für (mail.holzwirtschaft.org:25) wird der Status als online angegeben.

Was mich wundert, gebe ich bewußt eine falsche Adresse ein (mail.hhoollzzwwiirrttsscchhaafftt.org:25), wird der Status weiterhin als online angezeigt (click)

Ich bin verwirrt, müsste hier der Status nicht offline sein?
 
Zuletzt bearbeitet von einem Moderator:
Der_Jan schrieb:
...
Was mich wundert, gebe ich bewußt eine falsche Adresse ein (mail.hhoollzzwwiirrttsscchhaafftt.org:25), wird der Status weiterhin als online angezeigt*[...]
Ich bin verwirrt, müsste hier der Status nicht offline sein?
So ist es.
Bei mir funktioniert das auch einwandfrei.
Dein Link ermöglich leider keine Prüfung Deines Skriptes.
Dazu müsstest Du es als *.html Datei onlinestellen oder hier posten.
 
evtl. benötigen Ihr Skripte die PHP Einstellung RegisterGlobals auf "On".
und die mail() funktion einen zusätzlichen parameter, der ein gültige adresse beinhaltet.
Dieser Parameter muss der Mail-Funktion im PHP-Quelltext übergeben werden. Dies könnte z.B. so aussehen:
mail ($empfänger, $betreff, $nachricht, $headers, "-f hier@ihredomain.tld");

gruß
uli
 
Zuletzt bearbeitet:
Zurück
Oben Unten