[php] OT newsletter

[Björn Schotte]

Hi,

[für die gesamten Beiträge meinerseits zur NL-Diskussion
gilt: ich betrachte nur den Fall von "normalen", d.h.
nicht voll dynamisch personalisierten Newslettern.]

* Ringo Großer wrote:
> ich wollt nochmal nachfragen, wie es sich nun
> tatsächlich mit den möglichkeiten um einen
> newsletter verhält.

Listsoftware verwenden. Mit allem anderen handelt
man sich nur Schwierigkeiten ein.

> ich hatte bisher auch den ansatz verwendet,
> dass alle adressen aus der db ins BCC: geschrieben
> werden und dann die mail weggeht.

Da können unter Umständen die Sysadmins deines
Providers dir aufs Dach steigen bzw. du kannst
gar nicht alle Adressen ins Bcc: schreiben, weil
die Mailserver das (aufgrunder der negativen
Erfahrung mit Kinder-Scriptnewslettern) limitiert
haben.

Außerdem hast du das Problem des Bounce-Handlings.
In der Regel/Durchschnitt sind so 20% bis 30% (IIRC,
Zahl stammt vom E-Mail Marketing Guru Klaus Arnhold)
Bounces, d.h. die E-Mails sind aus verschiedenen
Gründen nicht zustellbar und kommen zurück (Mailbox
full, Account gibt's nicht mehr etc.).

"kommen zurück" heißt bei den meisten Kinderscripten
an den Account, unter dem der Webserver läuft, weil
das Kinderscript vergessen hat, den Envelope-From
zu setzen. Dann werden die Sysadmins deines Hosters
sauer, wenn sie bei jeder deiner Aussendungen 500
Bounce-Mails im E-Mail Postfach haben.

Das kann man verhindern, indem man den Envelope-From
selbst setzt (5. Parameter von mail() oder direkt im
SMTP-Dialog). Dann gehen die Bounces zwar an die von
dir angegebene Adresse, du hast aber immer noch das
Problem, diese Bounces analysieren zu *müssen*.

Listserver erledigen all diese Arbeit für dich schnell,
effizient und automatisch, denn dafür wurden sie gemacht.
Listar schickt z.B. eine Statistikmail an den Admin,
welche Mailadressen denn aus welchen Gründen nicht funktionierten
und wie lange diese Adresse noch unter Beobachtung steht
bevor sie entfernt wird etc.

Wie du siehst, ist ein Bounce-Handling wichtig für den
reibungslosen Betrieb. Die Kindernewsletterscripte betrachten
diese Fälle gar nicht, weil sich die Entwickler zumeist
nicht richtig mit dem Versenden von E-Mails und den damit
verbundenen Implikationen auskennen.

Ein guter Listserver wird also z.B. für Bounces mit
"mailbox full" den Benutzer auf on-hold setzen und
bei X weiteren erfolglosen Versuchen ihn komplett aus
der Rezipientenliste streichen, ein "User unknown" wird
in der Regel ein direktes Entfernen aus der Liste zur
Folge haben etc.pp.

Das Bounce-Handling kann man auch mit PHP machen,
indem man ein CGI-PHP compiliert und in die MTA-
Empfangsqueue einbindet, die ankommende E-Mail
analysiert und entsprechend handhabt. Aber das ist
für den Normalfall viel zu aufwändig, weil man hier
wieder getreu NIH etwas macht, was es bereits tausendfach
erprobt und in reichhaltiger Auswahl gibt. Ich würde
das nicht unbedingt empfehlen, zumal die Entwicklungszeit
und -kosten sicherlich höher liegen als das Verwenden
von bereits fertigen Lösungen. PHP ist halt nicht für
alles zu gebrauchen und das ist auch gut so.

> nun hab ich aber in der diskussion mitbekommen,
> dass bei etwa 500 der ofen aus ist?

Nein, das wurde nicht behauptet.

> ich benötige also einen ansatz für ein cms, wo der
> kunde nur EINEN newsletter administriert, der an
> alle abonnenten geht. das ganze ohne timeouts oder
> abonnentenanzahlbeschränkung.

Listsoftware verwenden. Und dann in der Admin-Oberfläche
eine E-Mail an die Newsletter-Adresse verschicken. Den
Rest macht die Listsoftware.

-- 
PHP-Support * realitätsnahe Performance-Messungen mit Code-Analyse
    Webapplikationsentwicklung * PHP-Schulungen * Consulting
    
             0700-THINKPHP -*- bjoern_(at)_thinkphp.de