funktionsloser mail Befehl (PHP)

[fietur]

Hallo,

ich bin leicht am Verzweifeln. Seit einem Jahrzehnt betreibe ich eine Website mit selbstgebasteltem CMS auf PHP-Basis bei Strato. Eine der Kernfunktionen ist der mail-Befehl. Ob suspekte Requests quasi instant an mich gemeldet werden, Anmeldungen aus Webformularen erfolgen oder automatische Erinnerungsmails abgesetzt werden, immer konnte ich die mail-Funktion problemlos nutzen (oder zumindest eine Fehlermeldung erhalten).

Seit ein paar Tagen nicht mehr.

Im Error-Log findet sich nichts. Die angemailten Email-Adressen sind erreichbar (sowohl die Strato-gehosteten als auch externe). Am Code wurde nichts geändert, auch nicht die PHP-Version (8.2), und Strato hat keinerlei Änderungen vorgenommen. Die Seite läuft bis auf die Nichtausführung von mail() unauffällig. Der mail-Befehl wird mit Rückgabewert true abgesetzt, aber keine email versendet. Strato sagt: nicht unser Problem.

Folgendes rudimentäre Skript

<?php
echo mail ("[e-mail]", "Betreff", "Inhalt");
?> 

auf den Server geladen und im Browser aufgerufen liefert als Ausgabe "1", aber keine Email und keinerlei Fehlermeldung in Browser oder auf dem Server; der request wird sauber mit "HTTP/1.1 200 OK" durchgeführt.

Was könnte da los sein?

[Mitleser 2.0]

Was könnte da los sein?

Strato wird da wohl behilflich sein müssen, um Dir Logs bereitzustellen, was mit der E-Mail auf seiner Reise so schief gelaufen ist.

[fietur]

Strato wird da wohl behilflich sein müssen, um Dir Logs bereitzustellen, was mit der E-Mail auf seiner Reise so schief gelaufen ist.

Das war auch mein Gedanke beim Telefonat mit dem Support. Die Erreichbarkeit der Email-Adressen bei Strato wurde getestet, alles ok von der Seite. Und in den erreichbaren Logs waren keine Hinweise.

[Mitleser 2.0]

Das war auch mein Gedanke beim Telefonat mit dem Support. Die Erreichbarkeit der Email-Adressen bei Strato wurde getestet, alles ok von der Seite. Und in den erreichbaren Logs waren keine Hinweise.

Ich kann nur raten. Ein ratbarer Kandidat auf dem Mailserver(!) wäre:

/var/log/exim/mainlog

Auge hat das im Detail m.E. ganz ordentlich im Detail geschildert, wie man sich den eigentlichen Ablauf vorstellen muss.

Alternativ kannst Du noch darüber nachdenken, Mails direkt via SMTP bei deinem Mailhost auf die Reise zu schicken, dann solltest Du direktes Feedback in Deinem PHP bekommen. Das kostet aber Zeit, bzw. kann zu Timeouts führen, sofern Du keine eigene Mail-Queue aufsetzt.

Oder wechsel zu einem Provider, der sich aufrichtig kümmmert, statt abzuwiegeln…

[fietur]

Alternativ kannst Du noch darüber nachdenken, Mails direkt via SMTP bei deinem Mailhost auf die Reise zu schicken, dann solltest Du direktes Feedback in Deinem PHP bekommen. Das kostet aber Zeit, bzw. kann zu Timeouts führen, sofern Du keine eigene Mail-Queue aufsetzt.

Das wird dann wohl mein nächster Schritt. Was nimmt man da? PHPmailer?

Oder wechsel zu einem Provider, der sich aufrichtig kümmmert, statt abzuwiegeln…

"Zu Codefragen kann ich Ihnen keine Antwort oder Beratung geben." Und auch kein Ticket öffnen. Unausgesprochen: Wir bieten auch kostenpflichtigen 24/7 Support an... Danke, nein. Habe ich 10 Jahre nicht gebraucht. Bisher war ich immer zufrieden. Gewesen. Immerhin war die Zeit in der Warteschleife nicht allzu lang und die vorgeschaltete Nachricht über derzeit laufende Phishingversuche recht unterhaltsam. Vor allem der Teil, als anschließend gefragt wurde, ob man denn tatsächlich noch mit einem Mitarbeiter reden wolle.

[Auge]

Hallo

Alternativ kannst Du noch darüber nachdenken, Mails direkt via SMTP bei deinem Mailhost auf die Reise zu schicken, dann solltest Du direktes Feedback in Deinem PHP bekommen. Das kostet aber Zeit, bzw. kann zu Timeouts führen, sofern Du keine eigene Mail-Queue aufsetzt.

Das wird dann wohl mein nächster Schritt. Was nimmt man da? PHPmailer?

Ja, kann man nehmen. Einerseits funktioniert das recht zuverlässig und ist, wenn man das Prinzip verstanden hat, gut zu „bedienen“ und andererseits schließt man mail, die Übergabe der Daten an den MTA, die dortige Verarbeitung und weiterhin die Übergabe durch den MTA an SMTP als mögliche Fehlerquellen aus. Mit PHPMailer kann man die E-Mail ja direkt an SMTP übergeben. Man kann mit PHMMailer aber auch den Weg über mail gehen. Also obacht bei der Konfiguration!

"Zu Codefragen kann ich Ihnen keine Antwort oder Beratung geben." Und auch kein Ticket öffnen.

Das ist soweit normal, weil …

Unausgesprochen: Wir bieten auch kostenpflichtigen 24/7 Support an …

Das darf der Agent schlicht nicht sabotieren.

Ob dein Problem überhaupt in das Gebiet des kostenpflichtigen Supports fällt, steht auf einem anderen Blatt. Dass, nach deiner Aussage, die Störung ohne jegliche Änderung an Code und Konfiguration von deiner Seite ganz plötzlich seit Zeitpunkt X auftritt, lässt zumindest vermuten, dass es eine irgendeine Änderung im Verantwortungsbereich deines Hosters gab.

Tschö, Auge

[fietur]

Ob dein Problem überhaupt in das Gebiet des kostenpflichtigen Supports fällt, steht auf einem anderen Blatt. Dass, nach deiner Aussage, die Störung ohne jegliche Änderung an Code und Konfiguration von deiner Seite ganz plötzlich seit Zeitpunkt X auftritt, lässt zumindest vermuten, dass es eine irgendeine Änderung im Verantwortungsbereich deines Hosters gab.

Davon gehe ich eigentlich aus.

Update: Heute morgen trudelte eine Bouncemail ein. Auf meiner Website hat sich jemand vor 5 Tagen über ein Formular für einen Kurs angemeldet, woraufhin das Skript über mail() eine Email an zwei Empfänger abgesendet hat: eine an den Kursveranstalter und eine an mich, beide nicht angekommen. Bisher hatte ich keinen Anlass, den Inhalt ein weiteres Mal (außer der Mailkopie an mich) zu dokumentieren.

Diagnostic-Code: smtp; 421 chrootmail.store.d0m.de SMTP-Service currently not
    available due to resource limitations; please try again later (Cond.Orange)

Die Bounce-Meldung ging an die FROM-Adresse (wie angegeben). Die Begründung zur Unerreichbarkeit des SMTP-Services scheint mir allerdings eher eine Verlegenheitsfehlermeldung zu sein. Der meldende Server chrootmail.store.d0m.de[192.168.46.194] trägt eine lokale IP.

An der Zahl der Emails sollte es nicht liegen. Die bewegt sich nämlich im maximal zweistelligen Bereich am Tag. Die Zahl der Zugriffe auf das Anmeldeformular, über das theoretisch Spam generiert werden könnte, ist ebenfalls gering (und nicht durch mail() übermittelt). Ich denke, ich kann einen übermäßigen mail()-Gebrauch als Fehlerquelle sicher ausschließen.

Es dürfte also tatsächlich ein Konfigurationsproblem bei Strato sein.

[Auge]

Hallo

Update:

Diagnostic-Code: smtp; 421 chrootmail.store.d0m.de SMTP-Service currently not
    available due to resource limitations; please try again later (Cond.Orange)

Mit „smtp; 421“ finde ich mit DuckDuckGo Ergebnisse, die auf nicht herstellbare Verbindungen mit SMTP-Servern hinweisen („Cannot connect to SMTP server“, „a problem with your outgoing server connection“, „too many connections … within a short time“ oder „Configuration mistakes … as … an incorrect SMTP port number“). Allesamt Sachen, die du in einem PHP-Serverskript, das E-Mails mit mail versenden soll, nicht in der Hand hast.

Mit dem PHPMailer, der sich direkt an einen SMTP-Server wendet, hättest du das in der Hand. Dort konfigurierst du das, ganz wie in einem lokalen E-Mail-Client, die Verbindung mit Servername, Port und Zugangsdaten.

In dem Seiten, die das Thema behandeln, ist üblicherweise von Problemen beim Versand aus Outlook heraus die Rede, aber am Ende ist das egal, da es in jedem Fall um den (scheiternden) Versand über SMTP geht.

Die Bounce-Meldung ging an die FROM-Adresse (wie angegeben). Die Begründung zur Unerreichbarkeit des SMTP-Services scheint mir allerdings eher eine Verlegenheitsfehlermeldung zu sein. Der meldende Server chrootmail.store.d0m.de[192.168.46.194] trägt eine lokale IP.

Die Adresse gehört offensichtlich zu Strato. Wenn ich nach diesem Domainnamen suche, beziehen sich alle Fundstellen auf Dienste von Strato.

An der Zahl der Emails sollte es nicht liegen. Die bewegt sich nämlich im maximal zweistelligen Bereich am Tag.

Wenn da nicht ein *ganz empfindlicher Admin am Werk ist, sollte diese Menge an E-Mails tatsächlich keine Probleme machen.

Tschö, Auge

[Raketenwilli]

Update: Heute morgen trudelte eine Bouncemail ein. Auf meiner Website hat sich jemand vor 5 Tagen über ein Formular für einen Kurs angemeldet, woraufhin das Skript über mail() eine Email an zwei Empfänger abgesendet hat: eine an den Kursveranstalter und eine an mich, beide nicht angekommen. Bisher hatte ich keinen Anlass, den Inhalt ein weiteres Mal (außer der Mailkopie an mich) zu dokumentieren.

Diagnostic-Code: smtp; 421 chrootmail.store.d0m.de SMTP-Service currently not
    available due to resource limitations; please try again later (Cond.Orange)

Die Bounce-Meldung ging an die FROM-Adresse (wie angegeben). Die Begründung zur Unerreichbarkeit des SMTP-Services scheint mir allerdings eher eine Verlegenheitsfehlermeldung zu sein.

Nun, einen solchen Fall hatte ich auch mal zu bearbeiten (nach dem das Kind im Wasser war). Damals hatten Hacker den jahrelang ohne Updates gebliebenen Wordpress-Auftritt eines KMU gehackt, die Zugänge wurden verkauft und die (zahlreichen) Käufer hatten u.a. gigabyteweise Spammails verschickt.

In dem Fall waren die leicht zu finden, weil die Skripte „verdunkelt“ waren, in dem wesentliche Teile einfach byteweise herumgedreht wurden. Ein

grep $HOME -rn "STOP" *

hat gereicht, um das Ausmaß zu entdecken. Ich hab den Server aber „platt“ gemacht und eine Reihe von Abuses informiert, dass das Problem meines Kunden entdeckt sowie behoben sei und dem Kunde gesagt, für Wordpress soll er sich wen anderes suchen.

(„STOP“ statt „POST“ - via $_POST wurden die Daten der verkauften Webshells übertragen. Es waren hunderte.)

Viele Mailserver nehmen die Mails dann nicht mehr an. Der SMTP-Fehler 421 wird (wohl) gerne genutzt, um „Angreifern“ keine korrekten Infos zu liefern. Ich würde an Deiner Stelle mal untersuchen, ob die Skripte auf Deinem Server das sind, was Du erwartest und ob da nicht ein paar hundert merkwürdige Kandidaten mit harmlosen Namen wie „helper.php“ herumliegen. Das Problem kann aber (im Falle des Massenhostings) auch ein anderer Kunde, der den selben Server nutzt, verursacht haben. Das wird Dir ein, an Deinen Monatsraten interessierter Massenhoster wohl „sofort“ erzählen...

An der Zahl der Emails sollte es nicht liegen. Die bewegt sich nämlich im maximal zweistelligen Bereich am Tag.

Tja. Das sind also womöglich nur die, von denen Du Kenntnis hast.

[fietur]

Viele Mailserver nehmen die Mails dann nicht mehr an. Der SMTP-Fehler 421 wird (wohl) gerne genutzt, um „Angreifern“ keine korrekten Infos zu liefern. Ich würde an Deiner Stelle mal untersuchen, ob die Skripte auf Deinem Server das sind, was Du erwartest und ob da nicht ein paar hundert merkwürdige Kandidaten mit harmlosen Namen wie „helper.php“ herumliegen.

An der Zahl der Emails sollte es nicht liegen. Die bewegt sich nämlich im maximal zweistelligen Bereich am Tag.

Tja. Das sind also womöglich nur die, von denen Du Kenntnis hast.

Besten Dank für diese Information.

In meinem Serverbereich ist alles wie es sein soll, bis auf TCPDF und jetzt PHPMailer gibt es keinen Fremdcode - jede Codezeile stammt von mir. Deshalb fuchst mich die Sache ja auch besonders.

Das Problem kann aber (im Falle des Massenhostings) auch ein anderer Kunde, der den selben Server nutzt, verursacht haben. Das wird Dir ein, an Deinen Monatsraten interessierter Massenhoster wohl „sofort“ erzählen...

Ja, da dürfte der Hase im Pfeffer liegen. Die jetzt wieder eintreffenden Bouncemails sind im Header mit "X-Expurgate spam/phishing" gekennzeichnet. An den Inhalten - sowas Kompromittierendes wie "Test" - liegt es jedenfalls nicht, und per SMTP versandt sind die Inhalte "clean".

[Auge]

Hallo

Im Error-Log findet sich nichts.

Die angemailten Email-Adressen sind erreichbar (sowohl die Strato-gehosteten als auch externe). Am Code wurde nichts geändert, auch nicht die PHP-Version (8.2), und Strato hat keinerlei Änderungen vorgenommen. Die Seite läuft bis auf die Nichtausführung von mail() unauffällig.

Der mail-Befehl wird mit Rückgabewert true abgesetzt, aber keine email versendet.

Um Klarheit zu schaffen: die Funktion mail versendet keine E-Mails. Sie übergibt eine E-Mail an einen Mail Transfer Agent (MTA) und der versendet die E-Mail. Wenn mail also den Rückgabewert true liefert, heißt das nur, dass sie eine E-Mail beim zuständigen Programm abgeliefert hat. Über den Versand der E-Mail an sich sagt das nichts aus.

Strato sagt: nicht unser Problem.

Das sagt der Support (von wem auch immer) erst einmal immer, auch bei nicht offensichtlichen eigenen Fehlern. Das heißt nicht, dass nicht doch eine auf den ersten Blick unauffällige Änderung erfolgt sein kann, die quasi hintenrum das Problem verursacht.

Folgendes rudimentäre Skript

<?php
echo mail ("[e-mail]", "Betreff", "Inhalt");
?> 

Auf der Manual-Seite von mail heißt es in einer Anmerkung (Note) im Abschnitt additional_headers …

When sending mail, the mail must contain a From header. This can be set with the additional_headers parameter, or a default can be set in php.ini.

… in deinem Beispielcode gibt es aber keinen Parameter für zusätzliche Header, also auch keine Angabe für From. Gibt es im nicht rudimentisierten Skript zusätzliche Header mit einer Angabe einer Absendeadresse (From)? Wenn ja, sind es mehrere und wie sind die einzelnen Header voneinander getrennt (\n oder \r\n), falls sie als String und nicht als Array angegeben sind?

edit: Manche Hoster wollen auch einen zusätzlichen Parameter (nicht Header) sehen, der im fünften Parameter der Funktion hinterlegt wird. Das ist dann gerne mal sowas wie -f [e-mail]. Falls das so ist, solltest du die nötigen Infos in den FAQ von Strato finden. edit ende

Ich frage so explizit nach dem Aufbau von, weil mit PHP 8 die Trennung der zusätzlichen Header mit \r\n erzwungen wurde (entspricht RFC2822 für E-Mails). Damit ist der E-Mail-Versand in den Skripten diverser Programme abgestorben, weil sich die Programmierer dieser Skripte aufgrund eigener und/oder erlesener Erfahrungen und Tests darauf verlassen haben, dass speziell unter Unix/Linux, die MTAs üblicherweise mit \n getrennte Header erwartet haben. Das haben sie, weil die Übergabe von mail Richtung MTA auf dem lokalen System erfolgt, das im Falle von Unixoiden mit \n funktioniert.

Die MTAs bauen die Header selbst von \n auf \r\n um. Wenn mail die Header schon mit \r\n angeliefert hat, baut sie der MTA zu \r\r\n um und damit scheitert der Versand der E-Mails in aller Stille ohne Fehlermeldung. Nach Diskussionen wurde das Erzwingen von \r\n zum trennen von Headern mit PHP 8.1 über einen Schalter in der php.ini optional gemacht. Nicht, dass Strato da irgendetwas umkonfiguriert hat.

Soweit ich das verstanden habe, ist das Problem aber umgehbar, indem die zusätzlichen Header als Array an mail übergeben werden (ab PHP 7.2, also kein Problem für dich).

Tschö, Auge

[fietur]

… in deinem Beispielcode gibt es aber keinen Parameter für zusätzliche Header, also auch keine Angabe für From. Gibt es im nicht rudimentisierten Skript zusätzliche Header mit einer Angabe einer Absendeadresse (From)? Wenn ja, sind es mehrere und wie sind die einzelnen Header voneinander getrennt (\n oder \r\n), falls sie als String und nicht als Array angegeben sind?

mail() befindet sich in verschieden stark ausgebauten Varianten in meinen Skripten. Meist sieht es so aus:

mail(
        '[e-mail]',
        $betreff,
        $content,
        'MIME-Version: 1.0'."\r\n" .
        'Content-Type: text/plain; charset=UTF-8'."\r\n" .
        'From: Error-Messenger <[e-mail]>'."\r\n"
    );

$betreff und $content sind unproblematisch (Länge und Zeilenumbrüche, Sonderzeichen im Betreff), bei nicht an mich gesendete Mails kommen noch Reply-To und Cc/Bcc hinzu, sowie manchmal auch mehrere Adressen im Empfänger. Als Array übergebe ich die Daten nicht.

Wie gesagt, es hat bisher funktioniert - die letzte Code-Generalüberholung fand Anfang des Jahres statt, als ich auf PHP 8.x gewechselt bin. Seither sind Hunderte Emails erfolgreich (und schnell) zugestellt worden oder "ordentlich" gebounct. Bis letzte Woche.

edit: Manche Hoster wollen auch einen zusätzlichen Parameter (nicht Header) sehen, der im fünften Parameter der Funktion hinterlegt wird. Das ist dann gerne mal sowas wie -f [e-mail]. Falls das so ist, solltest du die nötigen Infos in den FAQ von Strato finden. edit ende

Ich hatte beim Support nachgefragt, aber da war keine Änderung bekannt. In den FAQ findet sich nichts derartiges. Auch wenn solche Aussagen mit Vorsicht zu genießen sind, würde ich annehmen, dass sich eine Änderung im Support-Aufkommen relativ schnell bemerkbar macht.

Ich frage so explizit nach dem Aufbau von, weil mit PHP 8 die Trennung der zusätzlichen Header mit \r\n erzwungen wurde (entspricht RFC2822 für E-Mails). Damit ist der E-Mail-Versand in den Skripten diverser Programme abgestorben, weil sich die Programmierer dieser Skripte aufgrund eigener und/oder erlesener Erfahrungen und Tests darauf verlassen haben, dass speziell unter Unix/Linux, die MTAs üblicherweise mit \n getrennte Header erwartet haben. Das haben sie, weil die Übergabe von mail Richtung MTA auf dem lokalen System erfolgt, das im Falle von Unixoiden mit \n funktioniert.

Die MTAs bauen die Header selbst von \n auf \r\n um. Wenn mail die Header schon mit \r\n angeliefert hat, baut sie der MTA zu \r\r\n um und damit scheitert der Versand der E-Mails in aller Stille ohne Fehlermeldung. Nach Diskussionen wurde das Erzwingen von \r\n zum trennen von Headern mit PHP 8.1 über einen Schalter in der php.ini optional gemacht. Nicht, dass Strato da irgendetwas umkonfiguriert hat.

mail ohne Header funktioniert aber auch nicht (vorausgesetzt, der Header ist bei Strato optional), und mit fehlenden \r bessert sich die Lage leider nicht (gerade versucht).

Lässt sich der Schalter über phpinfo() auslesen? Ich habe da nichts gefunden. Und eine eigene php.ini habe ich nicht.

Soweit ich das verstanden habe, ist das Problem aber umgehbar, indem die zusätzlichen Header als Array an mail übergeben werden (ab PHP 7.2, also kein Problem für dich).

Ja, nur leider tuts das hier auch nicht:

$headers = [
    'MIME-Version' => '1.0',
    'Content-Type' => 'text/plain; charset=UTF-8',
    'From' => 'Error-Messenger <[e-mail]>'    
];
mail(
    '[e-mail]',
    'Betreff',
    'Inhalt',
    $headers
    );

weitere Ideen?

[Mitleser 2.0]

weitere Ideen?

Womöglich auch einfach ein fehlerhafter / fehlender SPF-Record... Pure Spekulatius...

Das Maillog des Mailservers dürfte aufschlussreich sein...

Bzgl. SPF könnte das hier helfen:

https://mxtoolbox.com/spf.aspx

[fietur]

Womöglich auch einfach ein fehlerhafter / fehlender SPF-Record... Pure Spekulatius...

Wie ich weiter oben geschrieben habe, könnte es tatsächlich in die Richtung vermurkste Konfiguartion gehen.

https://mxtoolbox.com/spf.aspx

sagt mir zu meiner domain, dass weder DMARC noch SPF Record gefunden werden. Bisher verstehe ich zwar nur Bahnhof, aber das lässt sich ändern.

Bei Strato finde ich tatsächlich Einstellungen zur Domainverwaltung (die ich noch nie gesehen oder angefasst habe). Danach ist eine "Eigene DMARC-Regel" (wie auch immer die aussehen mag) und "keine SPF-Regel" eingestellt.

[Mitleser 2.0]

Bei Strato finde ich tatsächlich Einstellungen zur Domainverwaltung (die ich noch nie gesehen oder angefasst habe). Danach ist eine "Eigene DMARC-Regel" (wie auch immer die aussehen mag) und "keine SPF-Regel" eingestellt.

Auch "kein SPF" kann mittlerweile ein Problem darstellen. Ohne konkretes Testszenario ist das hier m.E. alles Kaffeesatzleserei.

Wenn Du halbwegs "safe" sein willst, dann mach lieber direktes SMTP - was aber auch seine Tücken hat.

[Auge]

Hallo

Bei Strato finde ich tatsächlich Einstellungen zur Domainverwaltung (die ich noch nie gesehen oder angefasst habe). Danach ist eine "Eigene DMARC-Regel" (wie auch immer die aussehen mag) und "keine SPF-Regel" eingestellt.

Auch "kein SPF" kann mittlerweile ein Problem darstellen.

Dann würde ich aktuell aber erwarten, dass E-Mails bei einzelnen Empfängerdomains nicht mehr ankommen, nicht bei allen. Eine Domain, bei der (unter anderem) ohne SPF nichts mehr angenommen wird, ist gmail.com. Allerdings liefern die auch eine Fehlermeldung (500-irgendwas, E-Mail nicht zustellbar) an die Absendeadresse zurück.

Tschö, Auge

[Mitleser 2.0]

Dann würde ich aktuell aber erwarten, dass E-Mails bei einzelnen Empfängerdomains nicht mehr ankommen, nicht bei allen. Eine Domain, bei der (unter anderem) ohne SPF nichts mehr angenommen wird, ist gmail.com. Allerdings liefern die auch eine Fehlermeldung (500-irgendwas, E-Mail nicht zustellbar) an die Absendeadresse zurück.

Bin ich komplett bei Dir. Der Wissensstand lt. OP ist halt einfach dünn. E-Mail ist ein fragileres Konstrukt, als mein gemeinhin so denkt. Aber Du scheinst ja im (Leidens-)Thema ;-)

[fietur]

Ich habe jetzt die SPF-Regel "Standard STRATO Mailserver" eingestellt und schaue mal, ob das etwas ändert.

mxtoolbox.com meldet jetzt, dass ein SPF-Record gefunden wird (und sich auch auf strato.com bezieht).

Leider kommt aber immer noch keine mail()-Email durch.

Mit Thunderbird gesendete Emails kommen sofort durch, und an nicht (mehr) existente Adressen gerichtete Emails bouncen ebenfalls sofort (korrekt mit 550 no such mailbox). In beiden Richtungen.

Vielleicht könnte eine Einstellung der DMARC-Regel weiter helfen, dachte ich mir. Und o Wunder, bei Strato finde ich dann unter "Welche DNS-Einträge gibt es bei STRATO und wie kann ich diese verwalten?":

DMARC ist mit der »STRATO Standard DMARC-Regel« bei neu bestellten Paketen (ab Sept. 2024) bereits automatisch für Sie aktiviert (ohne sichtbaren Präfix & Wert im TXT-Bereich). Es dient der Bekämpfung von Phishing.

Und dann noch:

Hinweis: Bei länger bestehenden Paketen ist dies noch keine Standardeinstellung. Setzen Sie den Punkt daher manuell auf die genannte Option, um DMARC nach unseren Standardwerten zu konfigurieren. Die TXT-Einträge dazu werden dann automatisch im Hintergrund gesetzt und sind nicht sichtbar.

Also Kommando zurück von "Standard STRATO Mailserver" auf "Keine SPF-Regel" und den eben gesetzten DMARC-Eintrag wieder gelöscht, um die "STRATO Standard DMARC-Regel" einstellen zu können. So wird es jedenfalls empfohlen.

Bisher kommen dennoch keine Emails mit mail() an. Und mxtoolbox.com meldet jetzt wieder, dass kein SPF-Record gefunden wird, aber ein gültiger DMARC Record vorhanden ist.

Irgendwie hat mir das jetzt nicht wirklich weiter geholfen. Jetzt gebe ich dem Ganzen mal eine Nacht Zeit.

[Mitleser 2.0]

DMARC als Pflichtprogramm wäre mir neu. SPF kommt mittlerweile vor. Pass auf, dass Du nicht mehr kaputt als heile machst.

Entscheidend für den SPF ist die verwendete Absenderadresse. Die muss nicht zwangsläufig bei Strato liegen. Die Empfängeradresse kommt auch ins Spiel, aber erst insofern, ob, welche und wie strenge Regeln der empfangende Mailserver anlegt.

Bleibe dabei: ohne konkretes Testszenario ist sinnvolle Hilfe hier schwierig bis unmöglich…

[fietur]

Hier berichtet jemand vom gleichen Problem (ebenfalls bei Strato): dem plötzlich nicht mehr funktionierenden Versand von Emails durch Plugins und PHP-Formulare.

Dort wird beschrieben, dass für den Versand aus PHP-Formularen als SPF-Regel der Standard Strato Mailserver und für die DMARC-Regel eine eigene Regel angegeben werden muss (in der man auch eine Email-Adresse zum Empfang der Berichte angeben kann). Die DKIM-Einträge werden hingegen automatisch von Strato gesetzt, wenn nichts angegeben wurde.

Dem Vorschlag bin ich jetzt gefolgt, vor allem in der Hoffnung, über den optionalen DMARC-Eintrag - Angabe einer Email-Adresse für Reports - einen aussagefähigen Hinweis zu erhalten.

[fietur]

Mittlerweile sollte der DMARC-Eintrag eigentlich im DNS angekommen sein - ist es aber laut https://mxtoolbox.com nicht.

Inzwischen habe ich alles auf den PHPMailer (SMTP über den Strato-Server) umgestellt. Manches wird dadurch natürlich einfacher (zB. Anhänge). Wobei die Erfahrung sagt: es ist immer problemlos, wenn es keine Probleme gibt. Nur wenn, dann wirds problematisch ;)

Es gibt noch eine Fehlerquelle, die eine Rolle spielen könnte. Ich hatte zuvor eine andere Domain, unter der auch die Emailadressen liefen. Mit der neuen Domain habe ich die alten Adressen übernommen und diese dann gelöscht. Die alte Domain ist noch gültig, ich will sie aber zum Jahresende freigeben. Auf Adressen wie "webmaster@..." laufen die Emails aller Domains zusammen (kann man bei Strato im Rahmen des Vertrags so einstellen).

Ich komme jetzt darauf, weil inzwischen noch eine gebouncte Email als Absender die alte Domain aufführt - die aber vom Skript beim Einliefern über mail() nicht angegeben wurde und zudem in einer Weise verwendet wurde, wie sie nicht von mir stammen kann (vor dem Domainnamen ist ein "www." eingefügt, das ich nie verwendet habe).

Aber damit will ich euch nicht weiter belatschern. Die Informationslage ist einfach zu dünn und ihr habt mir schon gut geholfen; vielen Dank.

Also neue Frage: Was ist zu beachten, wenn man eine nicht mehr benötigte Domain abgibt? Gibt es ein ratsames Verfahren, was man wo und wie lange ankündigt (.htaccess, <head>, ...)?

Ich hatte das Jahr über bereits eine Infoseite und Umleitung auf die neue Domain geschaltet. Der alte Name wird nicht mehr gebraucht (und läuft auch nicht Gefahr, missbraucht zu werden). Nur ein paar Suchmaschinen können es nicht lassen, immer wieder nach Uralt-Seiten zu graben. Besucher gibt es inzwischen keine mehr.

[Auge]

Hallo

Also neue Frage: Was ist zu beachten, wenn man eine nicht mehr benötigte Domain abgibt? Gibt es ein ratsames Verfahren, was man wo und wie lange ankündigt (.htaccess, <head>, ...)?

Was willst du ankündigen? Dass die zur alten Domain gehörenden Seiten nicht mehr existieren? Das wäre wohl entweder HTTP-Status „410 gone“ oder „308 permanent redirect“ mit einer Weiterleitung auf die passende Seite der neuen Domain.

Ich hatte das Jahr über bereits eine Infoseite und Umleitung auf die neue Domain geschaltet. Der alte Name wird nicht mehr gebraucht (und läuft auch nicht Gefahr, missbraucht zu werden). Nur ein paar Suchmaschinen können es nicht lassen, immer wieder nach Uralt-Seiten zu graben. Besucher gibt es inzwischen keine mehr.

Heißt das, dass du die Domain auf- a.k.a. abgeben willst? Ab dem Zeitpunkt kann dir aller Traffic, der auf diese Domain aufläuft, egal sein. Ob dann ein Domain-Inhaber oder -Händler im Besitz der Domain ist, auflaufende Anfragen nach einstmals existiert habenden Ressourcen sind dessen Problem.

Tschö, Auge

[fietur]

Heißt das, dass du die Domain auf- a.k.a. abgeben willst?

Ja. Inzwischen lasse ich einen 410 Gone zurückliefern. Die alte Domain gehörte zu einem Orga-Namen, der sich geändert hat und nicht mehr existiert.

Was das Sache etwas erschwert, ist, dass beim Aufruf der alten Seite ein Redirect auf eine 301 Infoseite der neuen Domain erfolgte. Wer dort gelandet ist, musste die neue Domain zur Kenntnis und zu seinen Lesezeichen nehmen. Es gab aber eine Lücke: War im Request der Domain ein (nicht zugehöriges) "www." vorangestellt und existierte die angefragte Seite sowohl in der alten wie auch der neuen Domain, wurde direkt und ohne Hinweis auf die neue Seite weitergeleitet. Ein Fehler meinerseits, mit nur geringen Auswirkungen. Dachte ich.

Für die menschlichen Besucher war die Umstellung kein Problem; das Design war komplett überarbeitet und die Tatsache des Wechsels auch breit veröffentlicht worden. Die Qualität der Besuche stieg sprunghaft an.

Nur: Immer weniger Menschen versuchen sich Informationen selbst zu beschaffen. Längst ersetzt die Googlesuche per KI das Nachlesen an der (einzig relevanten) Quelle. Und die liefert dann gerne auch Fehlinformationen, mit deren Folgen man sich dann zu befassen hat. In meinem Fall wurden dann gecachte Ergebisse der alten Seite mit Adressen der neuen Seite verquickt als Antwort geliefert.

Jetzt habe ich die Weiterleitung auf die neue Domain unterbunden und liefere nur noch einen 410 Gone für die alte Domain aus. Meine Hoffnung ist, dass die alte Domain zumindest bei den Suchergebnissen bald verschwunden sein wird. Nach Löschung gibt es natürlich auch keine Abfragen auf meinem Server mehr. Ich hoffe nur, dass dann auch die Phantom-Informationen verschwinden.

[Hans Baumann]

Strato sagt (zurecht):

Der Versand von E-Mails mittels CGI- oder PHP-Skripten mit E-Mail Server außerhalb von STRATO ist nicht möglich

wenn die Absende-Mail aber eine Strato-Domain ist, dann geht es:

<?php
$empfaenger = '[e-mail]';
$betreff = 'Der Betreff';
$nachricht = 'Hallo';
$header = 'From: [e-mail]' . "\r\n" .
    'Reply-To: [e-mail]' . "\r\n" .
    'X-Mailer: PHP/' . phpversion();

mail($empfaenger, $betreff, $nachricht, $header);
?>

[fietur]

Strato sagt (zurecht):

Der Versand von E-Mails mittels CGI- oder PHP-Skripten mit E-Mail Server außerhalb von STRATO ist nicht möglich wenn die Absende-Mail aber eine Strato-Domain ist, dann geht es:

Soweit die Theorie (und jahrelang auch Praxis).

<?php
$empfaenger = '[e-mail]';
$betreff = 'Der Betreff';
$nachricht = 'Hallo';
$header = 'From: [e-mail]' . "\r\n" .
    'Reply-To: [e-mail]' . "\r\n" .
    'X-Mailer: PHP/' . phpversion();

mail($empfaenger, $betreff, $nachricht, $header);
?>

Danke, aber dieser Code funktioniert jetzt bei mir nicht mehr. Den X-Mailer brauchte man nie, auch reply-to war (und ist vermutlich, siehe noreply) optional. Verwendung oder Weglassen im Header hilft nicht.

Sendet man Emails beipielsweise mit PHPMailer über SMTP (Strato-Server), braucht man den X-Mailer auch nicht (ich habe die betreffenden Codezeilen entfernt).

[Auge]

Hallo

<?php
$empfaenger = '[e-mail]';
$betreff = 'Der Betreff';
$nachricht = 'Hallo';
$header = 'From: [e-mail]' . "\r\n" .
    'Reply-To: [e-mail]' . "\r\n" .
    'X-Mailer: PHP/' . phpversion();

mail($empfaenger, $betreff, $nachricht, $header);
?>

Den X-Mailer brauchte man nie, auch reply-to war (und ist vermutlich, siehe noreply) optional. Verwendung oder Weglassen im Header hilft nicht.

Der Beispielcode ist in Hinsicht auf Reply-To auch irreführend. Warum sollte man für Reply-To eine Adresse benutzen, deren Local Part „noreply“ lautet? 😉

Den Reply-To-Header benutzt man, um eine von From abweichende Antwortadresse anzugeben. Zum Beispiel eben, wenn man als Absender eine No-Reply-Adresse benutzt und dennoch eine Adresse für Erwiderungen angeben will.

Tschö, Auge

[fietur]

Der Spuk ist vorbei.

Gestern hatte ich erneut den Strato-Support angerufen. Zwar konnte mir nicht geholfen werden - ein Link zu der Hilfeseite für die Email-Server-Einstellungen bezog sich auf externe SMTP-Verbindungen und die vorzunehmenden Einstellungen wurden bei der Überprüfung als bereits korrekt festgestellt -, aber ich konnte den Hinweis anbringen, dass ich davon ausginge, im Pool mit einem gehackten Kollegen vom Mailserver zusammen mit dem Filteratribut "spam/phishing" (Header der Bouncemails) belegt zu werden. Der Mitarbeiter kommentierte das nicht außer mit dem Hinweis, mir nicht weiter helfen zu können. Ich verabschiedete mich dann mit den Worten, dass ich davon ausginge, dass die Funktionalität (die ja nicht durch einen bei mir liegenden Fehler beeinträchtigt wurde) mit dem Entfernen des Verursachers aus dem Pool wieder hergestellt werden würde. Obwohl ich denke, dass dieser Wink mit dem Zaunpfahl verstanden wurde, glaube ich zwar nicht, dass dieser wirklich umgesetzt wurde (sprich: nach Blick ins Log eine Neuaufteilung des Pools vorzunehmen), aber...

... seit heute trudeln Hunderte von Testmails und Bouncemails wieder ein und mail() über PHP funktioniert so wie zuvor.

Ich bin mir nicht ganz sicher, aber ich glaube, dass die Blockade ziemlich genau 5 Tage nach Änderung der Einstellung Domains/Domainverwaltung/Rädchen bei meinserver.de/DNS/TXT und CNAME Records inklusive SPF- und DKIM-Einstellungen der STRATO SPF-Regel auf "Standard STRATO Mailserver" erfolgt ist. War diese Einstellung noch nicht vorgenommen, hat es also 5 Tage Geduld erfordert, bis sie letztlich wirksam wurde. Das ist aber reine Spekulation und es könnte auch sein, dass die Einstellungen rein garnichts damit zu tun hatten; schließlich waren die SMTP-Mails nie betroffen.

Jedenfalls danke ich euch für eure Anteilnahme und Hilfe und wünsche allen, die später auf diesen Thread stoßen, viel Erfolg bei der Beseitigung dieses Problems.

[Rolf B]

Hallo fietur,

oder der Supportnik (oder -nike) hat dich zwar abtropfen lassen, die Info aber trotzdem weitergeflüstert.

Das erlebe ich bei unseren Dienstleistern auch gerne mal: Wir meckern, die sagen „bei uns ist alles grün“, irgendwann später geht's wieder, manchmal mit einem Anruf „probier doch noch mal“. Und dann ist's doch Kirschgrün gewesen.

So wie der Kollege, der einem was zuliefern soll und überraschend schnell „fertig!“ meldet. Und es funktioniert bestenfalls halb. Nach Reklamation kommt dann „war ja auch noch nicht fertig fertig…“

Rolf