XaraX: SMTP/sendmail

Beitrag lesen

Re:

Das Problem von PHP ist ja ganz grundsätzlich, dass im Normalfall ein User auf die Ausgabe des Skriptes wartet - und der ist ungeduldig. Abgesehen von der normalerweise eingeschränkten Laufzeit von Skripten.

Auch wenn das nur marginal ist: PHP ist (nicht standardmäßig) der Prozessspaltung (aber) mächtig. PCNTL

Im Ergebnis käme genau das heraus, was jetzt auch heraus kommt: PHP informiert über das Ergebnis von mail() über die erfolgreiche Abspaltung eines Subprozesses, der unabhängig irgendwann die Mail zugestellt kriegt - oder eben auch nicht - und das Hauptskript läuft weiter.

Wiebitte?!? mail() informiert über die Ausgabe des Scripts sonst auch nicht, ob die Mail erfolgreich zugestellt wurde, sondern parst nur den Status des aufgerufenen sendmail und gibt etweder true oder false zurück.

Eigene Mailserver zu schreiben ist nämlich auch eine aufwendige Geschichte.

Allerdings!

...Zumal PHP ja sowieso nur sehr eingeschränkt den ausführenden Benutzer wechseln kann, während ein komplett externer Mailserver unter einem ganz anderen User läuft, und deshalb besser abschottbar ist.

Was auch nicht großartig notwenig ist, da, selbst wenn man von PHP als CGI oder Modul ausgehen würde, die bereits bestehende Konfiguration ausreichend ist.

Problem: Was ist, wenn der SMTP-Server temporär den Mailempfang ablehnt (4xx-Status, z.B. durch Greylisting) - wer verwaltet dann die Warteschlange?

Dazu hatte ich bereits nachtragent Stellung genommen. Direkt auf Deine Frage geantwortet: Ein eigens dafür abgespaltener Prozeß. Auch wäre eine viertelstündlich abgearbeiteter Cron-Job denkbar, der eine auf der Platte abgelegte Warteschlange bedient.

Wie oben erwähnt: Warum das zweimal auf einem Webserver mit Mailserver unterbringen, wenn die gesamte Queue-Funktionalität und SMTP-Kenntnis schon existiert? :)

Wenn alles sicher laufen wird, gibt es keinen Mailserver mehr von der Stange _zusätzlich_. Er soll durch eigenes ersetzt werden. Die Argumentation verstehe ich ansich. Es ging nur um die Beleuchtung dessen, was wirklich möglich ist. Und bei mir im Speziellen um eigene Programmierung.

Ich gebe gerne zu, dass mail() nicht in allen Fällen die ideale Lösung für den Mailversand ist - wobei sich das "besser" nicht aus dem zu sendenden Mailinhalt ergibt, sondern aus der Tatsache, dass man mit PHP

  • nicht immer garantiert einen funktionierenden Mailserver antrifft (ich habe da schon so meine Erfahrungen mit T-Systems-Webservern machen dürfen)
  • den Versanderfolg auf Basis eines SMTP-Statuscodes wissen möchte (Mailverifizierung)

Na und? PHP kann eigene Logs erstellen, oder sich mit /dev/log in Verbindung setzen.

PEARs Mail oder auch Net_SMTP sind da durchaus hilfreich. :)

Nein danke! Die Webserverlogs quellen über von lauter Requests auf Schwachstellen von sooooooo "hilfreichen" Programmmen. Was ich verzapfe, dafür halte ich auch meinen Kopf für hin. Dazu bin ich bei Programmen anderer nicht bereit.

Gruß aus Berlin!
eddi

--
Wer Rechtschreibfehler findet, darf sie behalten.