Newsletter-System mit 5- bis 6-stelliger Empfängerzahl

[Günther S]

Hallo zusammen,

ich habe da zwei Fragen zu Newsletter-Versand mit momentan ca 10000 Empfängern (der Newsletter sollte aber auch das 10fache aushalten):

Zur generellen Vorgehensweise: Es werden immer X Emails als BCC im Header angehängt, d.h. pro Aufruf der PHP-Funktion mail() werden im Optimalfall (alle Mails kommen an) X Benutzer versorgt.

1. Performance:
   Wie viele Email-Adressen kann man grob als BCC anhängen, damit die normalerweise noch zuverlässig ankommen? (Mir geht's hier mehr um Größenordnungen als um eine sehr präzise Auskunft)
   Und wie oft kann man die Funktion mail() typischerweise pro Scriptaufruf aufrufen?

2. Wie speichere ich die bereits verschickten Adressen?
   Ich hatte bisher einige Ansätze, die meisten davon habe ich aber wieder verworfen (z.b. die email-adressen (oder zumindest Benutzer-IDs) der bereits versendeten Exemplare als String zusammengekettet in eine MySQL-Spalte schreiben).

Momentan halte ich an folgender Variante fest:
Die Newsletter werden nach aufsteigender Benutzer-ID verschickt. Die ID, an die der letzte Newsletter rausging, wird in der DB gespeichert und ab der nächsten dann wieder begonnen (evtl. beim nächsten Seitenaufruf - ich denke alles auf einmal wird nicht gehen, oder?)

Was haltet ihr davon? Hat jemand einen Denkanstoß, wie man das besser machen könnte?

Gruß,
Günther

[DeWitt]

Hi Günther,

Ich bin momentan mit demselben Problem beschäftigt (auch wenn mein Verteiler gerade mal an der Grenze zur Vierstelligkeit angekommen ist), allerdings erstelle ich das Ganze in Perl, deswegen kann ich nur auf allgemeine Dinge eingehen.

Und wie oft kann man die Funktion mail() typischerweise pro Scriptaufruf aufrufen?

Das weiß ich weder bei PHP noch bei Perl, allerdings habe ich vor, das Problem anders zu lösen: Wenn ich alle Emails auf einmal (also in einer langen Schleife in einem Script) verschicken will, bekomme ich nach einiger Zeit einen Timeout Error, da das Script zu lange rechnet. Deswegen habe ich vor, bei jeder Iteration der Schleife zu prüfen, wie lange das Script bereits läuft und dann ggf. abzubrechen.
Anschließend wäre meine Idee, einen HTTP-Forward auf das Script auszugeben, und es somit erneut zu starten.
Nachteil ist natürlich, dass der User sein Browserfenster solange offen halten muss, bis der Versand abgeschlossen ist. Aber da solche Funktionen ja wohl nur vom Webmaster o.ä. durchgeführt werden, sollte dieser ja sowieso Bescheid wissen.

Momentan halte ich an folgender Variante fest:
Die Newsletter werden nach aufsteigender Benutzer-ID verschickt. Die ID, an die der letzte Newsletter rausging, wird in der DB gespeichert und ab der nächsten dann wieder begonnen.

Ich überlege mir, ob es nicht genügen würde, beim Neuaufruf der Seite das Script mit einem Übergabeparameter zu starten, also
UrlDesScripts?start=startid.

Natürlich hat ein derartiger Aufruf einige Sicherheits-Aspekte, die zu bedenken sind. Am sinnvollsten ist es aber wohl sowieso, die betroffenen Scripte in einem mit .htaccess-Datei geschützten Verzeichnis abzulegen. (Soweit ich weiß die sicherste Methode, Web-Verzeichnisse vor öffentlichen Zugriffen zu schützen?)

Hoffe ich konnte ein paar "Denkanstöße" liefern ;)

[Dennis]

Hi DeWitt,

Natürlich hat ein derartiger Aufruf einige Sicherheits-Aspekte, die zu bedenken sind. Am sinnvollsten ist es aber wohl sowieso, die betroffenen Scripte in einem mit .htaccess-Datei geschützten Verzeichnis abzulegen. (Soweit ich weiß die sicherste Methode, Web-Verzeichnisse vor öffentlichen Zugriffen zu schützen?)

Eine HTTP-Basic-Authentication durch den Apache (darum handelt es sich bei dem ".htaccess-Zugriffsschutz" nämlich) ist eine Benutzer-Autentifizierung mit Benutzername und Passwort. Du kannst so etwas genauso gut selber mit einer beliebigen serverseitigen Scriptsprache selber basteln - deshalb ist die HTTP-Basic-Auth des Apaches noch lange nicht "sicherer" oder "besser".

Egal was du machst - für alle Zugriffs-Kontroll-Mechanismen müssen irgendwie Benutzername und Passwort übermittelt werden. Geschieht dies über HTTP, so besteht grundsätzlich immer die Möglichkeit, dass jemand "in der Mitte" steht, die übertragenen Daten mitliest und somit die Zugangsdaten erhält.

Dieses Problem kannst nur umgehen, indem du die HTTP-Verbindung mit SSL verschlüsselt, sprich: indem du HTTPS benutzt. Dann sind die übertragenen Daten verschlüsselt - zwar könnte das theoretisch immer noch jemand knacken, allerdings ist dies mit heutiger Rechnerleistung äußerst unwahrscheinlich.

Viele Grüße aus Kanada,
  ~ Dennis.