[php] OT newsletter

[Björn Schotte]

* Ringo Großer wrote:
> 1.ich habe ein kleines redaktionssystem gebaut und
> bin nicht gewillt, von dessen layout abzuweichen, also
> ich möchte ungern die fremde oberfläche eines listservers
> einbinden.

Ja. Die Oberfläche von Mailman ist auch Optional, d.h.
wesentliche An-/Abmeldefunktionen können auch normal per
Mail geschehen (Ralf, korrigiere mich bitte, falls ich
falsch liege).
 
> 2.sowohl kunde (redakteur) als auch benutzer der webseite
> sollen so automatisiert wie möglich arbeiten können,
> d.h. die benutzer geben ihre emailadresse ein und entscheiden
> entweder anmelden oder abmelden, wobei die anmeldung eine
> mail mit der bestätigung zur folge hat.

Ganz einfach, das ist ein kleines Form2Mail, das eine
E-Mail an den Listserver mit dem Subscribe/Unsubscribe-
Wunsch und der E-Mail Adresse schickt. Darauf hin arbeitet
der Listserver alleine weiter.   

> verifizierung von anmel-
> dungen (per gegen- und bestätigungsmail) sollte nicht sein.

Ist Quasi-Pflicht, wenn du dir keinen Ärger einhandeln willst.
Double-OptIn und Double-OptOut sind seit dem Spam-Aufkommen
Standard und du solltest dich tunlichst daran halten, wenn du
bzw. dein Kunde keinen Ärger bekommen willst. Sonst kann jeder
(also auch Fremde) beliebige Mail-adressen auf den Newsletter
des Kunden subscriben und dann kann der Kunde unter Umständen
ganz schnell (auch juristischen) Ärger bekommen.

Vom entstehenden Image-Schaden ("Was haben Sie da programmiert,
wieso bekomme ich Ärger und wieso haben Sie mich nicht vorher
gewarnt, was auf mich zukommen kann!?") für dich ganz zu schweigen.

> der
> redakteur soll auch nur den inhalt des newsletters eingeben und
> auf absenden klicken müssen.

Ja, das ist dann wieder ein Form2Mail an die Newsletter-Adresse.
 
> 3. der newsletter soll wöchentlich an schätzungsweise über 500
> leute versendet werden, ohne zusätzliche kosten oder ärger beim
> provider zu verursachen.

Listserver verwenden. Bitte bei der Planung auch das Skalieren
beachten, sonst können die Entwicklungskosten mittel- bis
langfristig exponenziell steigen. Was bei 500 Leuten funktioniert,
kann bei 5000 Leuten in die Hose gehen. 

> 4. um den text des redakteurs herum wird automatisch ein html-
> layout mit dynamischen daten aus der db generiert und als html-
> newsletter versendet

Ja:

1. Text eingeben
2. Applikation baut HTML-Code herum
3. Mit PEAR::Mail_MIME baust du daraus eine konforme multipart/html-
   Mail
4. den so entstandenen Mailrumpf an newsletteradresse_(at)_domain.de
   schicken.
   
> 5. gegen eine personalisierung hätte ich nichts einzuwenden, solange
> der aufwand dafür nicht wesentlich höher ist.

Ich halte den Aufwand (je nachdem, welche Funktionen verlangt
werden) für weitaus höher, zumal dann die vorgestellten Lösungen
wie ezmlm, listar, mailman, majordomo nicht mehr brauchbar sind
und du dir dann sehr viel Gedanken über Design und noch mehr
Gedanken über Skalierung, Bounce-Handling (insbesondere dass
die Bounces von einem anderen SMTP-Prozess abgehandelt werden
als vom Sendeprozess, sonst kann man sich damit den Mailverkehr
des Servers lahm legen) etc. machen.

In den meisten Fällen wird es dann günstiger sein, die Subscriber-
liste zusammen mit dem personalisierten Mailtemplate über diverse
Schnittstellen (SOAP, XML-RPC, ftp, foobar) an einen Dienstleister
zu schicken, der das komplette Versenden übernimmt. Dienstleister
hierfür sind zum Beispiel MessageMedia oder Llynch, als Berater
hier kann ich Klaus Arnhold (hat u.a. mal für MessageMedia gearbeitet
und arbeitet gegenwärtig für eCircle), http://www.klaus-arnhold.de/,
empfehlen.

"Uh, Beratung, klingt nach teuer" - Rechne dem Kunden vor, wie teuer
es werden wird, wenn du die personalisierte Lösung selbst programmierst
und wenn der Kunde juristische Schwierigkeiten aufgrund z.B. fehlender Quasi-
Standards (Double-OptIn/-OptOut) bekommt. Da sind dann eine Beratung
und das Outsourcing an einen Dienstleister Peanuts. Vom Kostenvorteil,
der bei Schonung der eigenen Nerven eintritt, ganz zu schweigen.

> 6. ein vernünftiges bouncehandling wäre sehr zu begrüssen, aber
> ein grundsätzliches aussortieren von nicht zustellbaren adressen
> würde ausreichen.

Das halte ich für ein gefährliches und nicht sinnvolles Kriterium.
Das macht zum Einen die Sache (in meinen Augen, ist nicht maßgeblich)
sehr amateurhaft, zum Anderen kann der Arbeitsaufwand hierfür
potenziell massiv ansteigen. Das ist dann für beide Seiten (weder
für den Kunden noch für dich) bezahlbar und wirtschaftlich sinnvoll.
 
> worauf ich also hinaus will ist, dass die listserver sicher das meiste
> davon spielend schaffen. nur mit der bedienung suche ich einen
> einfachen weg, den möglichst nur ICH per script steuern muss.

Jep, s.o.

> ausserdem sollten einige sachen (wie die o.g. anmeldeverifizierung)
> nur optional also abschaltbar sein.

Damit kann sich dein Kunde massiven Ärger einhandeln und ich
warne davor, Double-OptIn/-OptOut weg zu lassen.

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