SMTP/sendmail

[Sven Rautenberg]

Moin!

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.

Da ist mir allerdings der jetzige Zustand schon irgendwie lieber: PHP liefert die Mail über eine Standardschnittstelle an ein zuständiges Subsystem aus, und kümmert sich nicht um den Rest. Eigene Mailserver zu schreiben ist nämlich auch eine aufwendige Geschichte. Warum das Rad mehrfach erfinden? 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.

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? :)

Und die Benutzung eines sendmail-Programms ist ebenfalls sehr effizient im Gegensatz zum TCP- oder Unix-Socket-Gehampel.

Was meinst Du damit genau, wenn Du von "TCP- oder Unix-Socket-Gehampel" sprichst?

TCP-Socket-Gehampel = Nutzung von TCP-Verbindungen zu Remote-Rechnern (u.U. auch localhost)
Unix-Socket-Gehampel = Nutzung von Unix Domain Sockets zum lokalen Rechner.

Beide Methoden sind zwar sehr universell einsetzbar und hinreichend flexibel, haben aber auch einen gewissen Overhead.

Insbesondere dürfte die spannendste Frage sein, wie sich das System bei großen Mengen parallel versandter Mails verhält. Übergibt man die Mail per sendmail der Queue des Servers, kann dieser autonom über den Versandzeitpunkt entscheiden und auch konfigurierte oder im Standard definierte Beschränkungen (z.B. die Zahl gleichzeitig zu einem Zielserver bestehenden Verbindungen) beim Mailversand einhalten - oder zumindest angemessen darauf reagieren.

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)

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

- Sven Rautenberg