nicht angemeldet
php mail()
0 0 
Der Martin
0
php mail()
Hallo zusammen!
Habe hier ein php-Script um Mails zu verschicken.
Funktioniert auch wunderbar. Nur wenn ich mir eine Mail zu Testzwecken schicke zeigt mir mein Mail-Programm immer
eine Büroklammer (also Mail mit Anhang) an obwohl ja gar kein
Anhang mitgeschickt wird.
Muss ich da was bei den headern ändern?
Hier der Code:
##########################Schnipp####################################
<?php
$db->query("SELECT * FROM fitzefatze WHERE blubblub = 1");
while ($db->next_record())
{
$Name = $db->f('Name');
$EMail = $db->f('EMail');
$from = 'blablablabla@web.de';
$to = $EMail;
$subject = 'Neuigkeiten aus bla';
$textemailcontent = 'blablabla';
$boundary = md5(uniqid(time()));
$header = "From: $from\n";
$header .= "Reply-To: $from\n";
$header .= "Cc: $cc\n";
$header .= "Bcc: $bcc\n";
$header .= "X-Mailer: PHP/" .phpversion(). "\n";
$header .= "X-Sender-IP: $REMOTE_ADDR\n";
$header .= "MIME-Version: 1.0";
$header .= "\nContent-Type: multipart/mixed; boundary=$boundary";
$header .= "\n\nThis is a multi-part message in MIME format";
$header .= "\n--$boundary";
$header .= "\nContent-Type: text/plain;charset=iso-8859-1";
$header .= "\nContent-Transfer-Encoding: quoted-printable";
$header .= "\n\n$textemailcontent";
$header .= "\n\n--$boundary--";
mail($to,$subject,"",$header);
}
?>
##########################Schnapp####################################
-
hi,
Nur wenn ich mir eine Mail zu Testzwecken schicke zeigt mir mein Mail-Programm immer
eine Büroklammer (also Mail mit Anhang) an obwohl ja gar kein
Anhang mitgeschickt wird.Ja, weil dein Script aber so tut, als wäre dies der Fall.
Muss ich da was bei den headern ändern?
Ändere den Content-type in text/plain, und schmeiße die Teile mit den Boundarys raus (Inhalt inklusive).
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
Danke für die schnelle Antwort!
Das war die Lösung.
Grüße aus München
Flo
-
-
Hallo Flo,
Funktioniert auch wunderbar. Nur wenn ich mir eine Mail zu Testzwecken schicke zeigt mir mein Mail-Programm immer eine Büroklammer (also Mail mit Anhang) an obwohl ja gar kein Anhang mitgeschickt wird.
die Boundaries wegzulassen hat wahsage dir ja schon empfohlen; die sind mir beim Durchlesen auch schon "sauer aufgestoßen".
Aber noch etwas ist mir aufgefallen. Gemäß der SMTP-Spec müssen die Headerzeilen mit CR/LF (\r\n) abgeschlossen werden anstatt nur mit einem Linefeed \n wie in deinem Script. Auch wenn das einige Mailserver wohl akzeptieren - es ist falsch.
$header = "From: $from\n";
$header .= "Reply-To: $from\n";
[...]
$header .= "X-Sender-IP: $REMOTE_ADDR\n";
$header .= "MIME-Version: 1.0";
$header .= "\nContent-Type: multipart/mixed; boundary=$boundary";und hier gehst du plötzlich dazu über, das Linefeed an den Zeilenanfang zu schreiben. Warum das? Das irritiert und schafft zusätzliche mögliche Fehlerquellen.
Schönen Abend noch,
Martin--
Wer im Glashaus sitzt, sollte Spaß am Fensterputzen haben.-
Hallo Martin,
Aber noch etwas ist mir aufgefallen. Gemäß der SMTP-Spec müssen die Headerzeilen mit CR/LF (\r\n) abgeschlossen werden anstatt nur mit einem Linefeed \n wie in deinem Script. Auch wenn das einige Mailserver wohl akzeptieren - es ist falsch.
1.) Die hier von Dir gerügten Header haben allesamt nichts mit SMTP zu tun.
2.) Sieh Dir bitte mit einem Programm, das aus dem
stdinliest, an, was beim
Ausführen der PHP-Funktion mail() wirklich passiert!
Denn ob es wirklich falsch ist, wird durch die zur Kompilierungszeit PHPs
eingebundenen C-Header-Datein des sendmail-Programmes bestimmt, und ich
erlaube mir anzumerken, daß <LF> in der überwiegenden Mehrzahl korrekt
ist.Hallo flo,
$header .= "Reply-To: $from\n";
da Du bereits mit "From:" arbeitest, wofür Du ansich besser den fünften Parameter der Funktion mail() nutzen solltest, ist hier "Reply-To:" unnötig.
Gruß aus Berlin!
eddi--
Wer Rechtschreibfehler findet, darf sie behalten.-
Hallo eddi,
1.) Die hier von Dir gerügten Header haben allesamt nichts mit SMTP zu tun.
wie meinen? Es geht um den Mailversand. Der erfolgt in den allermeisten Fällen über SMTP - also sind auch die dort definierten Regeln zur "Anatomie" einer Mailnachricht anzuwenden.
2.) Sieh Dir bitte mit einem Programm, das aus dem
stdinliest, an, was beim Ausführen der PHP-Funktion mail() wirklich passiert!Schwierig. Wie? An welcher Stelle? Schließlich baut PHP direkt mit dem im System konfigurierten SMTP-Server eine Socket-Verbindung auf, üblicherweise über Port 25. Wie fange ich diese Datenübertragung ab? Okay, vielleicht mit Ethereal o.ä. Tools. Ich habe aber angenommen, dass der als $message übergebene String direkt an den SMTP-Server weitergereicht wird.
So long,
Martin--
Einer aktuellen Erhebung zufolge sind zehn von neun Ehefrauen eifersüchtig auf ihren Mann.-
Re:
1.) Die hier von Dir gerügten Header haben allesamt nichts mit SMTP zu tun.
wie meinen? Es geht um den Mailversand. Der erfolgt in den allermeisten Fällen über SMTP - also sind auch die dort definierten Regeln zur "Anatomie" einer Mailnachricht anzuwenden.
Na dann will ich mal versuchen etwas ausführlicher zu werden:
Es ist richtig. Es geht um den Versand von mails. Auch richtig ist, daß sie via SMTP versendent werden. Das SMT-Protokoll wird zwischen einem Client und einem Server eingestzt, wobei in den allermeisten Fällen von zwei unterschiedlichen Maschinen ausgegaben werden kann, die durch das Internet miteinander verbunden sind. Der Standard-Mail-Client auf *NIX-Systemen heißt sendmail. Sendmail liest (so jedenfalls beim Beispiel mit der PHP-Funktion mail()) vom
stdinDaten ein. Diese Daten sind durch <CRLF> abgetrennt Message-Header und Message-body (kurz die Gesamtheit der zu versendenden Mail). Dabei werden die Daten aus mit "To:", "Cc:", "Bcc:", "From:" (und ähnliche) beginnenden Zeilen für SMTP aufbereitet.Message-Header besteht dabei aus einer Reihe von Zeilen, die mit der Transaktion zwischen Client und Server in Angaben und Wortlaut nichts gemein hat. Ich glaube das wird aus RFC 2821 / Seine 75 - Anhang D.3 / "Step 2" am deutlichsten. Die Message-Header subsummieren sich dort zum Content, der auf die Anfrage "DATA" bei Statuscode "354" als Antwort gesendet wird. SMTP kennt die "Befehle" DATA|EHLO|EXPN|HELO|HELP|MAIL|NOOP|RCPT|QUIT|RSET|VRFY "From" und der gleichen ist nicht dabei, wohlaber, wie oben beschrieben, werden sie von der Client-Software zu versenden (insbesondere von Anworten) benötigt.
Es ist richtig. "From:" (und der gleichen) wird durch RFC 822 Abs. 4.4.1 definiert, strenggenommen hat es aber nichts mit den protokollerhelbichen Commands zu tun.
Hinzu kommt auch, daß der von flo angegebene MIME-Header "MIME-Version: 1.0" der RFC 2045 Abs. 4 entspringt.2.) Sieh Dir bitte mit einem Programm, das aus dem
stdinliest, an, was beim Ausführen der PHP-Funktion mail() wirklich passiert!Schwierig. Wie? An welcher Stelle? Schließlich baut PHP direkt mit dem im System konfigurierten SMTP-Server eine Socket-Verbindung auf, üblicherweise über Port 25. Wie fange ich diese Datenübertragung ab? Okay, vielleicht mit Ethereal o.ä. Tools. Ich habe aber angenommen, dass der als $message übergebene String direkt an den SMTP-Server weitergereicht wird.
PHP baut meines Wissen auf *NIX keinen Socket zu einem SMTP-Server wärend der Ausführung der Funktion mail() auf. Das macht bestenfalls sendmail; und dann auch eher zu einem entfernten SMTP-Server, der seinerseits an Port 25 auf eingehende Verbindungen wartet, um Mails zu empfangen. Dieses Verhalten ist sicher auf den Gebrauch von PHP auf Windows gemünzt. Da kenne ich mich nicht genug mit aus; weiß aber, daß dort ein SMTP-Server zum versenden von Mails zu konfigurieren ist.
Solltest Du über ein *NIX-System verfügen, dann schreibe Dir ein kleines Programm, das vom
stdinliest und konfiguriere PHP durch sendmail_path so, daß der angegebene Pfad auf das neue Programm zeigt.So long,
BTW: Schade eigentlich, daß Christoph Zurnieden nicht mehr postet.
Gruß aus Berlin!
eddi--
Wer Rechtschreibfehler findet, darf sie behalten.-
Hallo,
Na dann will ich mal versuchen etwas ausführlicher zu werden:
Es ist richtig. Es geht um den Versand von mails. Auch richtig ist, daß sie via SMTP versendent werden. Das SMT-Protokoll wird zwischen einem Client und einem Server eingestzt, wobei in den allermeisten Fällen von zwei unterschiedlichen Maschinen ausgegaben werden kann, die durch das Internet miteinander verbunden sind.
yo, bis hierher lausche ich und bin 100% einverstanden.
Der Standard-Mail-Client auf *NIX-Systemen heißt sendmail. Sendmail liest (so jedenfalls beim Beispiel mit der PHP-Funktion mail()) vom
stdinDaten ein. Diese Daten sind durch <CRLF> abgetrennt Message-Header und Message-body (kurz die Gesamtheit der zu versendenden Mail). Dabei werden die Daten aus mit "To:", "Cc:", "Bcc:", "From:" (und ähnliche) beginnenden Zeilen für SMTP aufbereitet.Moment, Moment. Verstehe ich das richtig: Du willst damit sagen, dass Unix zwischen PHP und dem SMTP-Server eine weitere Zwischenstation in Gestalt dieses Programms sendmail einfügt? Wie uneffizient ...
Message-Header besteht dabei aus einer Reihe von Zeilen, die mit der Transaktion zwischen Client und Server in Angaben und Wortlaut nichts gemein hat. Ich glaube das wird aus RFC 2821 / Seine 75 - Anhang D.3 / "Step 2" am deutlichsten. Die Message-Header subsummieren sich dort zum Content, der auf die Anfrage "DATA" bei Statuscode "354" als Antwort gesendet wird. SMTP kennt die "Befehle" DATA|EHLO|EXPN|HELO|HELP|MAIL|NOOP|RCPT|QUIT|RSET|VRFY "From" und der gleichen ist nicht dabei, wohlaber, wie oben beschrieben, werden sie von der Client-Software zu versenden (insbesondere von Anworten) benötigt.
Okay, der Aufbau der Headerzeilen hat strenggenommen nichts mit dem SMTP-Protokoll zu tun, da habe ich mich etwas ungenau ausgedrückt. Ich wollte nur auf das standardisierte Format der Mail-Headerzeilen hinaus, auch wenn das in einem anderen RFC definiert ist, sorry.
Es ist richtig. "From:" (und der gleichen) wird durch RFC 822 Abs. 4.4.1 definiert, strenggenommen hat es aber nichts mit den protokollerhelbichen Commands zu tun.
Einverstanden.
PHP baut meines Wissen auf *NIX keinen Socket zu einem SMTP-Server wärend der Ausführung der Funktion mail() auf.
Unter Windows tut es das (PHP kontaktiert direkt den SMTP-Server, der in der php.ini vereinbart ist), und da mir dieses Vorgehen vertraut ist und sinnvoll erscheint, habe ich es unbewusst verallgemeinert.
Solltest Du über ein *NIX-System verfügen, ...
Negativ.
BTW: Schade eigentlich, daß Christoph Zurnieden nicht mehr postet.
Stimmt, den vermisse ich auch schon seit geraumer Zeit.
Schönen Abend noch,
Martin--
TEAM: Toll, Ein Anderer Macht's.-
Re:
Moment, Moment. Verstehe ich das richtig: Du willst damit sagen, dass Unix zwischen PHP und dem SMTP-Server eine weitere Zwischenstation in Gestalt dieses Programms sendmail einfügt? Wie uneffizient ...
Ansich ja. PHP währe Durchaus in der Lage selbst (auch aus einem PHP-Script direkt und nicht aus dem Binär) SMTP-Server zu kontakten. Es nimmt sich aber im Vergleich zu Windows nichts, da dort auch ein SMTP-Server (entweder local oder der des Providers zwecks dynamischer IP-Adresse) zwischengeschaltet wird/werden muß.
Okay, der Aufbau der Headerzeilen hat strenggenommen nichts mit dem SMTP-Protokoll zu tun, da habe ich mich etwas ungenau ausgedrückt. Ich wollte nur auf das standardisierte Format der Mail-Headerzeilen hinaus, auch wenn das in einem anderen RFC definiert ist, sorry.
Da ist der eigentliche Knackpunkt. Mir sind schon Newsletterscripte um die Ohren geflogen, weil ich mit "\r\n" gearbeitet habe, unterschiedliche sendmailprogramme/-Versionen aber mit einer Portirung des PHP-Scripts nicht zurecht kommen. Seit dem Teste ich immer vorher an ^^
Solltest Du über ein *NIX-System verfügen, ...
Negativ.
Pinguiene sind soooooooo toll :)))
Gruß aus Berlin!
eddi--
Wer Rechtschreibfehler findet, darf sie behalten.-
Nachtrag:
Ansich ja. PHP währe Durchaus in der Lage selbst (auch aus einem PHP-Script direkt und nicht aus dem Binär) SMTP-Server zu kontakten. Es nimmt sich aber im Vergleich zu Windows nichts, da dort auch ein SMTP-Server (entweder local oder der des Providers zwecks dynamischer IP-Adresse) zwischengeschaltet wird/werden muß.
Es macht aber Sinn, daß ein weiteres Programm zwischengeschaltet wird. Server können kurzfristig ausfallen. Sendmail ist aber so eingerichtet, daß es über mehrere Stunden immer wieder versucht den/die MX-Server einer E-Mail zugehörigen Domain zu kontakten, bis entweder ein bestimmbares Zeitlimit überschritten ist, oder die Nachrichten erfolgreich versandt wurden.
Zum einen müßte man diese Routinen in PHP implementieren, zum anderen gäbe es dann zwei Programme, selber Arbeitsweise ;)
Gruß aus Berlin!
eddi--
Wer Rechtschreibfehler findet, darf sie behalten. -
Moin!
Moment, Moment. Verstehe ich das richtig: Du willst damit sagen, dass Unix zwischen PHP und dem SMTP-Server eine weitere Zwischenstation in Gestalt dieses Programms sendmail einfügt? Wie uneffizient ...
Ansich ja. PHP währe Durchaus in der Lage selbst (auch aus einem PHP-Script direkt und nicht aus dem Binär) SMTP-Server zu kontakten. Es nimmt sich aber im Vergleich zu Windows nichts, da dort auch ein SMTP-Server (entweder local oder der des Providers zwecks dynamischer IP-Adresse) zwischengeschaltet wird/werden muß.
Nein, das ist ganz und gar nicht uneffizient.
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.
Eine Direktauslieferung der Mail direkt an den Zielserver verbietet sich daher. Das kostet viel zuviel Zeit: DNS-Lookup nach den MX-Records - wenn kein MX da ist, dann Lookup nach dem A-Record. Kontakt zum MX mit der höchsten Priorität. Wenn der nicht antwortet (TCP-Timeout), Kontakt mit dem nächsten MX... Bei erfolgreichem Kontakt Versandversuch. Problem: Was ist, wenn der SMTP-Server temporär den Mailempfang ablehnt (4xx-Status, z.B. durch Greylisting) - wer verwaltet dann die Warteschlange?
Deshalb ist es sehr schlau, wenn PHP die Mail einem lokalen Mailserver übergibt, und danach sofort weiter im Skript machen kann. Der lokale Mailserver kann dann im Hintergrund die Auslieferung der Mail übernehmen.
Und die Benutzung eines sendmail-Programms ist ebenfalls sehr effizient im Gegensatz zum TCP- oder Unix-Socket-Gehampel. Denn das sendmail gehört zum lokal installierten Mailserver und kennt sehr wahrscheinlich den schnellsten Weg, um über interne Interfaces die zu sendende Mail direkt in die Queue zu stellen. Genau deswegen liefern doch alle Sendmail-Ersatzserver ein sendmail-Programm mit, welches sich nach außen kommandokompatibel verhält.
Unter Linux ist eigentlich immer ein lokaler Mailserver installiert und verfügbar (nicht zwingend ist er auch korrekt konfiguriert, aber das ist das Problem des Admins). Unter Windows hingegen ist ein installierter Mailserver die absolute Ausnahme. Deshalb kontaktiert PHP unter Windows einen externen, aber im Verhältnis dennoch als "lokal" anzusehenden Mailserver über TCP/SMTP. PHP spricht nämlich für alle Mails immer den gleichen Mailserver an, und benötigt dort auch irgendeine Art von Einlieferungsberechtigung (SMTP-Auth oder IP-basiert, sofern der Server öffentlich erreichbar ist), ansonsten kommen die Mails nicht an.
- Sven Rautenberg
--
My sssignature, my preciousssss!-
Moi moin!
Ansich ja. PHP währe Durchaus in der Lage selbst (auch aus einem PHP-Script direkt und nicht aus dem Binär) SMTP-Server zu kontakten. Es nimmt sich aber im Vergleich zu Windows nichts, da dort auch ein SMTP-Server (entweder local oder der des Providers zwecks dynamischer IP-Adresse) zwischengeschaltet wird/werden muß.
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
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.
Deshalb ist es sehr schlau, wenn PHP die Mail einem lokalen Mailserver übergibt, und danach sofort weiter im Skript machen kann. Der lokale Mailserver kann dann im Hintergrund die Auslieferung der Mail übernehmen.
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? (Wie Du sicher nicht mehr weißt, schreibe ich mir gerade meine eigenen Programme zum versenden von Mails. Daher bin ich an genau solchen Informationen interessiert.)
Unter Linux ist eigentlich immer ein lokaler Mailserver installiert und verfügbar (nicht zwingend ist er auch korrekt konfiguriert, aber das ist das Problem des Admins).
*lol* ;)
Gruß aus Berlin!
eddi--
Wer Rechtschreibfehler findet, darf sie behalten.-
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
--
My sssignature, my preciousssss!-
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.-
Moin!
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.
Sag ich doch. Hast du nur nicht verstanden.
Hilfsmittel: s/über/durch/g
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.
Du schreibst ernsthaft einen eigenen Mail_SERVER_ in PHP? Na dann viel Spaß - ich bevorzuge dann doch lieber komfortable Standardsoftware wie Postfix. Der vertraue ich mehr, als meinen eigenen Demon-Programmierkünsten (die sind nicht existent). Und zumindest PHP4 hat mit Demons so seine Probleme, würde ich behaupten (basierend auf den Erfahrungen mit einem Demon, der auf den SELF-Servern läuft und nicht sehr stabil ist).
- 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.
Dass PHP eigene Logs erstellen kann, hilft nicht bei dem Versuch, die erfolgreiche Auslieferung einer Mail an den Zielserver festzustellen, weil PHP mit mail() diese Aufgabe gar nicht selbst erledigt.
Und auf die Logfiles vom Mailserver darf PHP mit Sicherheit nicht lesend zugreifen - abgesehen davon, dass Logfileformate auch immer softwarespezifisch sind (Sendmail schreibt ein anderes Format als Exim), und deren Position systemspezifisch (je nachdem, wie der Admin den syslog konfiguriert hat, tauchen die Meldungen entweder in einer separaten Datei, u.U. noch getrennt nach Logleveln, auf, oder zusammen mit sämtlichen Logmeldungen aller anderen Prozesse in einer gemeinsamen und einzigen /var/log/messages).
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.
Die Klasse Net_SMTP ist erstens gut dokumentiert, zweitens im Quelltext erhältlich, drittens nicht so wahnsinnig riesig, als dass man sie nicht selbst mal durchlesen könnte, und hat viertens ja absolut keine remote ausnutzbare Schwachstelle, da sie selbst nur beim Senden der Mail an ein Ziel in Erscheinung tritt.
Inwiefern du Requests auf Net_SMTP feststellen konntest, scheint mir da doch etwas rätselhaft.
- Sven Rautenberg
--
My sssignature, my preciousssss!-
Morgen,
Sag ich doch. Hast du nur nicht verstanden.
Hilfsmittel: s/über/durch/g
vorhin war zu spät und jetzt ist noch zu früh - ich glaub Dir einfach mal.
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.
Und zumindest PHP4 hat mit Demons so seine Probleme, würde ich behaupten (basierend auf den Erfahrungen mit einem Demon, der auf den SELF-Servern läuft und nicht sehr stabil ist).
Kann man den Quellcode einsehen?
- 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.
Dass PHP eigene Logs erstellen kann, hilft nicht bei dem Versuch, die erfolgreiche Auslieferung einer Mail an den Zielserver festzustellen, weil PHP mit mail() diese Aufgabe gar nicht selbst erledigt.
Die ursprüngliche Diskussion ging vom Ansatz aus, daß sendmail als Mittler genutzt wird, es aber auch möglich wäre, Mailversand direkt von PHP erledigen zu lassen. In dem Fall wirst Du alles andere, als mail(), welches ja explizit auf sendmail zugreift, nutzen.
Vielleicht bin ich jetzt ein wenig im Vorteil, da ich schon 3 h schlafen konnte - verkneifen kann ich mir die Fragen dennoch nicht: Was glaubst Du warum ich einen eigenen Child-Prozeß forke, wenn der nicht via SMTP Mails transferieren soll? Warum soll der nicht den Erfolg mitnotieren können?Unten verweißt Du selbst noch auf eine Klasse, die _ohne_ die Funktion mail() arbeitet um Mails durch die Leitung zu jagen...
Und auf die Logfiles vom Mailserver darf PHP mit Sicherheit nicht lesend zugreifen
Warum soll PHP, das Erfolg/Mißerfolg notiert, auf Logfiles des Mailservers _lesend_ zugreifen? Es bleibt also dabei: Na und? PHP kann _eigene_ Logs erstellen.
- abgesehen davon, dass Logfileformate auch immer softwarespezifisch sind (Sendmail schreibt ein anderes Format als Exim), und deren Position systemspezifisch (je nachdem, wie der Admin den syslog konfiguriert hat, tauchen die Meldungen entweder in einer separaten Datei, u.U. noch getrennt nach Logleveln, auf, oder zusammen mit sämtlichen Logmeldungen aller anderen Prozesse in einer gemeinsamen und einzigen /var/log/messages).
Mir scheint, Du hast noch nicht so viel mit syslog() und Geschwistern an einem CLI-Script gearbeitet. Dennoch sollte Dir die mit PHP recht simple Art verschiedene Formatierungen vorzudefinieren und per Parameter auszuwählen, nachvollziehbar erscheinen. Also ist das auch kein Argument!
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.
Die Klasse Net_SMTP ist erstens gut dokumentiert, zweitens im Quelltext erhältlich, drittens nicht so wahnsinnig riesig, als dass man sie nicht selbst mal durchlesen könnte, und hat viertens ja absolut keine remote ausnutzbare Schwachstelle, da sie selbst nur beim Senden der Mail an ein Ziel in Erscheinung tritt.
Die einzigen Erweiterungen, die ich nebst AUTH gefunden habe, sind SIZE und eine MAIL-FROM-Erweiterung, für die es weder auf faqs.org noch auf ietf.org eine Spezifikation gibt. Nicht sehr prickelnd - und das insbesondere dahingehend, daß Postfix auch so konfigurierbar ist, Trasfers ohne 8BITMIME-Erweiterung abzulehnen.
Da kannst Du mir den auf 1006 Zeilen aufgeblähten und auf drei weitere Klassen, die ich mir jetzt nicht angesehen habe, aufsetzende Net_SMTP-Klasse mit einem Smily schmackhaft. Helfen wird es nicht.Gruß aus Berlin!
eddi--
Wer Rechtschreibfehler findet, darf sie behalten.
-
-
-
-
-
-
-
-