Get Adobe Flash player

E-Mail

Prefilling – gängiger Praxis fehlt oft der kritische Blick

Im E-Mail-Marketing, oder direkter gesagt im Bereich des Newsletterversandes, da hat das Prefilling eine lange Tradition.

Als Prefilling wird das Vor-Ausfüllen von Formularfeldern auf der Landingpage des beworbenen Produktes durch die Übermittlung von Parametern aus einem Newsletter heraus bezeichnet.

Es werden also die Daten, die die versendende Firma in ihren Listen gespeichert haben, verwendet, um auf der Seite des beworbenen Produktes Formularfelder automatisch mit den Daten des Nutzers zu befüllen. So muss er sich zur Registrierung dort nicht mehr die Mühe machen, Anrede, Vorname, Nachname, E-Mail-Adresse, Straße, Hausnummer, Postleitzahl, Ort, Land, Geburtsdatum oder was sonst noch gefordert ist, manuell einzutippen.

Dieses Beispiel bezieht sich auf den Versuch einer Kaltakquise und nicht darauf, dass eine Firma eigene Kunden mit einem eigenen Angebot beschicken will. Hier wäre die Ausgangssituation eine andere.

Über ein solches Prefilling, so kann man es sehen, freuen sich drei Parteien:

  1. Der User selbst über seinen verringerten Aufwand
  2. Der Eigentüber des beworbenen Produktes, denn die Conversion-Rate (das Verhältnis von Registrierungen zu Besuchern) steigt, da die Hemmschwelle zur Teilnahme abgesenkt wurde
  3. Der Listeigner, der den Newsletter im Auftrag des Produkteigners verschickt hat: er liefert bessere Performanceraten, muss weniger Volumen versenden, schont seinen Verteiler und wird gerne wieder gebucht

Win-win-win – was will man mehr!?

Aber da gibt es mehr. Das Recht jedes Einzelnen darauf, dass mit seinen personenbezogenen Daten schutzwürdig umgegangen wird, wird hierbei verletzt. Dieser Vorgang ist zweifellos als eine Verarbeitung von personenbezogenen Daten ohne Einwilligung zu sehen. Denn als Verarbeitung ist gemäß § 3 Absatz 4 Satz 2 Nr. 3 und Nr. 3a BDSG bereits das Übermitteln der Daten in der einfachen Form des Bekanntgebens der Daten.

In dem geschilderten Fall hat der Betroffene nicht eingewilligt, dass seine Daten an den Produkteigner, also die dritte Firma, weitergegeben werden dürfen. Wäre dem so, dann bräuchte ein solche Kampagne nicht durchgeführt werden. Denn es ist ja eben das Ziel des Produkteigners, die Daten (im Einzelfall betrachtet) dieses noch unbekannten Users berechtigter Weise in seinen eigenen Datenbestand aufnehmen zu dürfen.

Also halten wir fest: dieses Prefilling, das Alltagspraxis in diesem Werbebereich ist, ist datenschutzrechtlich unzulässig.

 Doch welche Alternativlösungen gibt es hierfür?

Nun ja, die einfachste und bitterste ist, das Prefilling einfach zu unterlassen. Wirtschaftlich gesehen wäre damit ein Schaden für diese Branche verbunden.
Des weiteren wäre es wohl einen Versuch wert, ob die Methode einer gerichtlichen Prüfung standhalten kann, wenn nahe bei dem Klick-Button, der auf die Landingpage des beworbenen Produktes deutlich hervorgehoben vermerkt wird, dass die persönlichen Daten des Nutzers durch den Klick zum Zwecke der Vor-Ausfüllung der Formulare an die Zielseite übermittelt werden.

Bleibt zu hoffen, dass sich eine Lösung etabliert, die den teilnahmewilligen User nicht von seinem Ziel abhält. Sonst stünden wir vor einer loose-loose-loose-Situation.

MTA – Standards müssen her

Wer sich viel mit Email-Technik beschäftigt, der muss sich zwangsweis auch mit MTA’s befassen. Je nachdem, ob man einen Server selbst aufsetzt oder einen fertigen in Gebrauch nimmt, muss man sich selbst für einen Mail-Transfer-Agent entscheiden oder sich mit dem vorgesetzten auseinandersetzen.

Lange Zeit war Sendmail die Nummer 1 der Mailabwickler. Dies lag auch daran, dass seine Wurzeln bis in die 80er Jahre zurückreichen und es lange schlicht keine Alternative gab. Es gab ja auch keinen Grund dazu, denn Sendmail war zuverlässig und erfüllte alle Anforderungen.  In den 90er Jahren kamen dann aber doch Konkurrenten auf den Markt, die viele Kritikpunkte in Sendmail sahen, allen voran Aspekte der Sicherheit. Immerhin gab es zu Entstehungszeiten von Sendmail noch keine Spam-Problematik

Eine dieser Entstehungen ist Qmail. Qmail ist streng modular aufgebaut und wird auch nicht standardmäßig im Root-Verzeichnis des Servers installiert (wie etwa Sendmail).  Die Verankerung im Root-Verzeichnis legt einem Angreifer alle Wege offen, sobald er die Hürde des MTA genommen hat. Der modulare Aufbau sorgt zusätzlich dafür, dass der Assistent stabiler läuft und ein ausfallender Abschnitt, also ein Modul, nicht gleich für den Absturz des Mailservers sorgt.

Aber ich will hier eigentlich gar keinen MTA-Vergleich oder sonst eine Bewertung abliefern. Auch ist die Liste der aktiven MTA’s weit länger als die zwei bisher genannten. Dazu ist aber Wikipedia da.Wie der Titel schon sagt, möchte ich mich für eine Standardisierung aussprechen. Jeder Mail-Server gibt für jeden Task eine Antwort ab. Diese finden sich etwa in den zugehörigen Logfiles. Sie werden aber auch etwa bei Bounce-Mails an den Versender einer Email abgeschickt. Hierfür nutzt jeder MTA bestimmte Codes, Ausdrücke oder ganze Sätze. Liest man diese Responses durch, wirkt es oft schon sympathisch menschlich, was der Server da so von sich gibt. Leider nur ist es so, dass unterschiedliche Systeme für die gleichen Szenarien auch unterschiedliches Feedback geben.

Für den Fall, dass der eigene Server beobachtet werden soll, ist das ja nicht weiter schlimm: man lernt, mit seinem Mailer zu kommunizieren. Was aber machen diejenigen unter uns, die etwa groß im Email-Marketing-Geschäft stecken? Werden zahlreich Newsletter verschickt, so ist ein anständiges Bounce-Management eine bereichernde Geschichte und für jeden PHP-Entwickler auch leicht automatisierbar, wäre da nicht diese Unterschiedlichkeit! Das ankommende Feedback sollte für einen Mailprofi in Softbounce und Hardbounce kategorisiert werden können. Denn abhängig davon müsste auf unterschiedliche Weise mit dem potentiellen Empfänger bzw. seiner Email-Adresse umgegangen werden.

Leider kommt man dabei nicht drum herum, Versuche und Ausnahmen zu programmieren, in der Hoffnun, jeden Fall abfangen zu können. Perfekt wird das aber kaum werden können.

Dabei ist es sogar so, dass es einen RFC-Standard dafür gibt, er sollte halt nur auch konsequent genutzt werden: RFC 1893.  Von Qmail wird dieser Standard beispielsweise eingesetzt. Das schöne daran ist auch: ein bestimmtes Ereignis wird nicht nur in einem festgelegten Wortlaut beschrieben, es erhält auch einen festgelegten numerischen Code.

Eine einheitliche Orientierung würde viel Ärger, Arbeit und Ungewissheit ersparen.