Re: Server fuer Newsletter

[Raphael Eiselstein <rabe@xxxxxxxxx>]

Hallo Werner,

On Fri, Jan 14, 2011 at 09:29:09PM +0100, Werner Holtfreter wrote:
> Am Mittwoch, 2011-01-12 21:16:30 schrieb Marc Haber:
> > unprofessionelles Rumgefrickel
> ja, genau darum geht es. Verzeiht meine Ahnungslosigkeit:
> 
> Kann man Mailman auf dem Desktop-PC installieren, der keine Dienste 
> im Internet anbietet und dies aus Sicherheits- und Kompetenzgruenden 
> des Benutzers auch nicht soll? Wie schwierig/aufwendig ist die 
> Administration, wenn man bei Null Ahnung beginnt?

Du hast eingangs geschrieben, dass opt-in/opt-out/admin-in etc gehen
soll. Fuer mich liest sich das erstmal so, dass da (mindestens) ein 
Webfrontend verwendet werden soll, d.h. Du benoetigst also einen aus dem
Internet erreichbaren Rechner.

Das zu mindest fuer die Pflege der Verteilerlisten. Wieviele Verteiler 
sind zu pflegen und wieviele Empfaenger sind es (jeweils)?

Die Generierung und der Versand von Mails ist dann der andere Part. 


Minimalistisch betrachtet kannst Du mit einem Mailprogramm Mails
verschicken. Ganz normal ueber den Mailserver der fuer die Domain
zustaendig ist, also Provider. Hier sind ggf. AGB (ja, ohne 's) zu lesen,
was das Thema Massenmails angeht.

Das Mailprogramm sollte ein Adressbuch haben, die Pflege der
Verteilerlisten waere hier im einfachsten Fall manuell. Auf der Webseite
braeuchte man dann nur ein Formular, was eine entsprechende
(un)-subscribe-Benachrichtigung an den Owner schickt.

"Webserver" ist leider etwas zu mager als Information. Mailman kann man
betreiben, wenn man einen eigenen *richtigen* Server hat, also
wenigstens einen Root-Server als vServer oder auf echter Hardware mit
einem Linux/Unix darunter. Mailman wird ueber CGI integriert, sieht aber
nicht wirklich huebsch aus. Ein begabter Webdesigner koennte die
mitglieferten html-Templates aufhuebschen, wenn es professioneller
aussehen soll.

Newsletterversand via Mailman geht, indem man eine (oder mehrere)
Mailinglisten einrichtet und so einstellt, dass nur bestimmte Absender
an die Liste schreiben duerfen und Antworten an den Listowner zugestellt
werden. Der Aufwand Mailman sinnvoll aufzubauen und in Apache zu
integrieren ist je nach Distribution mehr oder weniger aufwendig. Ich
hab es bisher nur mit FreeBSD gemacht, da muss man halt Mailman
grundkonfigurieren, die Integration mit sendmail ist da aber schon
erledigt. 

Was man tun muss ist, dass man fuer jede Mailingliste einen Strauss an
Mailaliases eintraegt. Was man genau zu tun hat schickt einem Mailman
dann praktischerweise per E-Mail.

Man kommt aber nicht drumherum ein x100-zeiliges README zu
lesen und zu verstehen. Mailman ist ein Biest und Doku ist langwierig
und so aufgebaut, dass man wirklich nahezu alles lesen muss, um alle
Stellen zu finden, die man wirklich braucht.

Ich koennte das Setup von Mailman mal an von mir betreuten Mailinglisten
zeigen, zB auf einem kommenden FIXME. Ich betreibe ein paar
Mailman-Installationen mit jeweils einer oder mehreren Mailinglisten
darauf. 

Es gibt (hab leider vergessen wie es heisst, Bert?) ein Javabasiertes
Newslettertool, was nicht nur Listenverwaltung erlaubt, sondern auch in
Richtung Kampagnenmanagement geht. Darin enthalten auch Moeglichkeiten,
Trackinginformationen in Weblinks zu verarbeiten, zB als
Redirect-Service. Das was ich da mal gesehen habe ist leider zwar Java,
liefert aber Linux-ELF-Code mit und war unter FreeBSD nicht zum Laufen
zu bringen. Die Installation war eine Reihe von "Hacks", die die
hartcodierten Defaultwerte etwa durch SQL-Statements auf der
MySQL-Datenbank bedeutet haben. Nicht sehr schoen. Das Demo der Software
war ganz okay, der Betrieb auf einem eigenen Server beansprucht sehr
viel Motivation ;)

Unter dem Stichwort "E-Mail Marketing" findet man bei heise.de eine
schoene Liste von Newslettertools: 
http://www.heise.de/software/download/o0g1s3l11k285


Es gibt also verschiedene Wege zum Ziel. Wenn die Mailingliste rein
Workstation-basiert betrieben werden soll, dann wird es sicher nicht so
einfach, einen automatisierten (un)subscribe-Mechanismus ueber eine
Webseite zu bekommen. 

Darf es etwas professioneller aufgebaut sein und im Eigenbetrieb (also
eigener Root-Server, kein Dienstleister dazwischen), dann sollte man
neben dem sicheren Betrieb eines Mailservers auch in der Lage sein
Zusatzsoftware zu installieren und zu integrieren, etwa Apache
verstehen, MySQL/Postgres sicher betreiben. 

Wichtiger ist aber noch ein Verstaendnis dafuer zu haben, welche
Eigenschaften von Massenmails den SPAM-Score erhoehen und somit zum
Beispiel bei den "groesseren" Mailprovidern dazu fuehren werden, dass Mails
wenn sie ueberhaupt angenommen werden nicht bei den Benutzern im
"Spamordner" landen. 

Wichtige Aspekte von "wir kommen in Frieden" sind zum Beispiel:  
* Absenderdomain und der verwendete Mailserver "passen zusammen" 
  - Der versendende Mailserver ist MX fuer die Absenderdomain
  - Der MX-Record in der DNS-Zone zeigt auf einen echten Namen, nicht
    auf einen CNAME
  - Der Name des Mailservers loest zu einer IP auf, die wiederum auf den
    (gleichen) Namen des Mailservers aufloest, zB

mail.uugrn.org has address 195.49.138.123

123.138.49.195.in-addr.arpa is an alias for 123.96-127.138.49.195.in-addr.arpa.
123.96-127.138.49.195.in-addr.arpa domain name pointer mail.uugrn.org.

  Das ist alles nicht *notwendig*, aber durchaus sinnvoll, es richtig 
  zu machen

* Mails im HTML-Format ...
  - sind multimpart messages und liefern auch einen plain text teil mit,
    der dem Text der html-Mail entspricht (Spammer machen das nicht
    immer)
  - Bilder und CSS werden nicht von einem Webserver gezogen sondern sind
    Anhaenge zur Mail, CSS am besten nur inline, Bilder am besten ganz
    weglassen.
  - Weblinks werden nur sparsam verwendet und verweisen direkt auf das
    Ziel und nicht erst als auf Redirect-URLs mit Trackinginformationen. 
  - Weblinks taeuschen vor allem nicht vor auf eine bestimmte Seite zu
    verweisen und verweisen in Wirkichkeit woanders hin. 

    boese Beispiele:

    <a href="http://spammer.com/tracking/redirect.php?id=asdfljasdfjh";>http://www.meinefirma.de/</a>
    oder
    <a href="http://www.meinefirma.de/produkt/"; 
       onClick="(javascript-code, der bei klick erst noch auf spammer.com umleitet)"
      >http://www.meinefirma.de/produkt/</a>

* Rechtliches ... IANAL!
  - Gewerbliche Mails sollten (muessen?) einen Anhang haben, aus dem die
    Firma hervorgeht. Link auf Datenschutzbestimmungen und
    Ansprechpartner, unsubscribe etc sollte dort zu finden sein.
    Impressum.
  - opt-out ist nur B2B erlaubt (AFAIK, IANAL)
  - ...
  - "Zu Risiken und Nebenwirkungen fragen Sie am besten die eigene 
    Rechtsabteilung oder einen erfahrenen Anwalt." 

Besonders beim Betrieb von opt-out-Verteilern sollte man IMHO sehr
darauf achten, dass die Empfaenger wirklich handverlesen sind und dass da
ganz sicher keine privaten Mailadressen dabei sind. info@xxxxxxxxxxx ist
meistens gut, walter.maria.schmitt@xxxxxx vermutlich eher nicht. Auch
wenn beide Mailadressen beim gleichen Mensch ankommen.

Es empfiehlt sich die Herkunft aller Adressen (auch bei opt-in!) moeglichst 
genau zu speichern, d.h. Datum+Uhrzeit, IP-Adresse (Browserkennung,
Referer, ... ), genauer  Weg, wie die Adresse in den Pool gekommen ist. 
Im Zweifel muss(?) man auf Nachfrage das naemlich beantworten koennen und je
sauberer Man das belegen kann, umso besser. 

Das ganze geht natuerlich weit ueber die Frage nach dem richtigen Tool
hinaus. Aber das sind Dinge, die man bei der Wahl des Tools beachten
sollte, wenn man nicht schon aufgrund technischer Maengel als unserioes 
beim Kunden ankommen will (wenn man nicht vorher schon im Spamfilter
gelandet ist).

Gruss
Raphael

-- 
Raphael Eiselstein <rabe@xxxxxxxxx>               http://rabe.uugrn.org/
xmpp:freibyterægmx.de  | https://www.xing.com/profile/Raphael_Eiselstein   
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..



-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/