Support-Forum Mirko Böer Softwareentwicklungen

Hallo Volkmar,

du hast in deinem Post viele interessante und richtige Argumente gebracht. Ich möchte für diesen Thread die rechtliche Seite nicht vertiefen, da wir uns da leicht verennen können und dann am eigentlichen Sachverhalt vorbeireden. Es wäre sicher ein interessantes Thema für einen separaten Thread. So einfach ist das mit dem TimeStamp und dem \"besonders\" jedenfalls nicht.

Vielleicht habe ich mich in meinem letzten Post missverständlich ausgedrückt, aber ich habe dies Mirko gegenüber in einem früheren Post schon einmal ausführlich dargelegt. Das eigentliche Problem liegt nicht in der Gestaltung des Opt-In Formulars. SWM hat Sicherheitsprobleme aufgrund der Implementierung. Diese betreffen den Einsatz von Single-Opt-In beim Löschen und die Änderungsfunktion (Gruppe oder E-Mail-Adresse). Der rechtliche Aspekt war nur eine mögliche Auswirkung dieser Lücken.

Der Aufruf dieser Funktionalitäten kann auf zweierelei Art geschehen. Der Kunde wählt ein Formular auf der Website oder er klickt auf einen Link in einer an ihn gerichteten E-Mail. In jedem Fall muss der Kunde authentisiert werden. Da (ohne größere Manipulationen) nur der Kunde die E-Mail erhält und der Link (hoffentlich) nicht vorhersagbar ist, ist der eindeutige Link nach heutigem Stand der Technik als ausreichende Authentisierung zu betrachten.

Die Problematik liegt beim direkten Aufruf der Webformulare. Hier wird der Kunde nicht authentisiert (er muss ja kein Login und Passwort eingeben). Ist, wie ich glaube sogar standardmäßig, Löschen ohne Bestätigung eingestelt, kann ein Angreifer (Hacker) E-Mails einer SWM-Mailingliste von außen löschen. Man lässt per Bruteforce einfach E-Mails durchprobieren oder läuft bekannte Adressen durch. Der Kunde bekommt nichts mit und ist keine Meldung an den Administrator eingerichtet auch der Betreiber der Mailingliste nicht. Hier hat ein Betreiber einer SWM-Liste die Möglichkeit über Doppel-Opt-In beim Löschen das zu unterbinden. Ein entprechender Hinweis wäre in der Dokumentation sicherlich angebracht.

Beim Ändern ist es analog. Man kann eine SWM-Mailingliste von außen verändern, sowohl die Adressen, als auch die Gruppenzuordnungen. Mirko hat die Notwendigkeit eines Doppel-Opt-Ins bei direkten Änderungen über ein Webformular verstanden. Ich selbst habe Mirko so verstanden, dass er ein Doppel-Opt-In für Änderungen in die nächste Version implementieren wird. In seiner letzten Anmerkung hat er aber geschrieben, dass er kein Doppel-Opt-In implementieren möchte, wenn nur Gruppen geändert werden. Dies ist nicht verständlich. Das Authentisierungsproblem bleibt. Auch wenn die Wahrscheinlichkeit für diese Angriffsfläche geringer ist, als beim Ändern der E-Mailadresse, verstehe ich nicht, warum hier nicht gleich die Authentisierung konsequent implementiert wird. Ein Kunde, der sich die Arbeit macht und seine E-Mail-Änderung einträgt, klickt auch noch auf einen Link. Hier wird aus Angst, eine vermeintlich einfache Bedienung für den Kunden zu erhalten, die Sicherheit vernachlässigt. Mirko sollte letztendlich doch seinen Kunden die Entscheidung überlassen, ob sie auch bei einer Gruppenänderung eine Authentisierung möchten oder nicht. Programmtechnisch ist das doch kein Aufwand, wenn das Doppel-Opt-In schon für die Änderung der E-Mail-Adresse implementiert wird.

Marcus

Original von MarcusK:

Mit der Bestätigungs-E-Mail gibt es keine Probleme, denn ist der Empfänger enthalten, wird keine E-Mail versendet, nur die Gruppe zugeordnet. Das bleibt so und wird sich nicht ändern.

Das ist für einen Import OK. Ich möchte natürlich einen Kunden, den ich von Hand eintrage, z.B. weil er sich vor Ort handschriftlich in eine Mailingliste eingetragen hat, mit der Bestätigungs-E-Mail die Möglichkeit geben, seine Preferenzen, sprich Gruppen, auszuwählen. Das funktioniert natürlich nur, wenn er bereits in alle Gruppen importiert ist, bevor er das Änderungsformular aufruft. Ist er sehr schnell und antwortet gleich, wird er durch den späteren Import wieder in evtl. abgewählte Gruppen eingetragen. Sehr doof.

...

Das ist OK, wenn die Änderungsseite über einen Link in einer erhaltenen E-Mail aufgerufen wird und dieser Link eine eindeutige nicht vorhersehbare ID enhält. Wird das Änderungsformular aber direkt, z.B. über die Website, aufgerufen, ist dies eine erhebliche Schwachstelle. Aus rechtlicher Sicht wird damit kein Double-Opt-In-Verfahren vollzogen und ein außenstehender Angreifer kann eine SWM-Mailingliste manipulieren. Bei deiner Implementierung könnte man sogar alle Gruppen abwählen und damit die Adresse löschen. Rechtlich schlimmer ist es, wenn jemand so manipuliert, dass eine andere Gruppe hinzugenommen wird. Wenn der Kunde dann für eine andere Gruppe unerwünschte Werbung erhält, kann er nach deutschem Gesetzt eine Abmahnung erwirken. Das kann ganz schön teuer werden. Ich finde die aktuelle Gesetzelage auch weltfremd und einen Blödsinn, aber es interessiert ein Gericht leider nicht, was ich davon halte. Das Problem vor Gericht ist, das der Mailinglistenbetreiber in der Nachweispflicht ist, dass die Änderung vom Kunden stammt. IP-Adressen werden nicht annerkannt. Da der Kunde nicht bestätigen musste, hat der Betreiber von SWM keinen Nachweis. Der Fall wird sicher nicht sehr häufig sein, aber wenn ich auch nur einmal 2000 Euro zahlen muss, weil die Softwarefirma, die mein Mailinglistenprogramm herstellt wissentlich eine Sicherheits- und eine rechtliche Lücke nicht schließt, wäre ich sehr verärgert. Warum weigerst du dich so wehement, SWM konsequent und rechtlich sauber zu implementieren? Ãœbrigens, bei unserem Testlauf waren alle unsere Tester verwundert, warum sie nach einer Änderung keine Bestätigungs-E-Mail erhalten haben.

Das kann man so nicht stehen lassen, da sträuben sich dem Juristen in mir die Nackenhaare. Hier wird eindeutig Ursache und Wirkung verwechselt. Aber der Reihe nach...

Zunächst einmal ist zwar richtig, dass die IP-Adresse allein keinen gerichtsfesten Beweis darstellt. Anders sieht es bei einer IP-Adresse mit Timestamp aus, denn dann lässt sich auch bei einer dynamsich vergebenen IP-Adresse ermitteln, wem die Adresse zur fraglichen Zeit gehört hat. Ist etwas aufweniger, aber es geht. Das mal nur am Rande.

Dein Problem, Markus, liegt an einer anderen Stelle, und ist auch nur dort zu lösen, und das ist nicht die Implementierung der Änderungsfunktion durch Mirko bzw. deren Ergänzung um den Versand einer weiteren Bestätigungsmail.

Dein Problem steht und entfällt nämlich mit einer korrekten Ausgestaltung des Opt-in-Formulars und ggf. dem Bestätigungsmail. Alle Deine Probleme lösen sich auch bei einer Änderung in Luft auf, wenn Du Dir bei der Anmeldung zum Newsletter vom Empfänger die generelle Erlaubnis geben lässt, ihm einen Newsletter zu senden. Wenn Du hingegen dies von Anfang so aufbaust, dass Du Dir nur die Erlaubnis zum Newsletterversand anhand der Gruppenzuordnung geben lässt, hast Du all die Probleme, die Du geschildert hast.

Also: Generelle Erlaubnis per Double-opt-In einholen, im Formular reinschreiben (so in der Art): \"Ich - der Newsletterempfänger - interessiere mich besonders für diese Themen: \", dann die Gruppenauswahl.

Der Trick ist die Verwendung des Wortes \"besonders\". Das impliziert nämlich, dass er auch damit einverstanden ist, mal was zu anderen Themen zu erhalten. Und schon sind alle Probleme entschwunden, sogar bei dem - sicherlich seltenen - Fall, dass ein anderer als der Newsletterempfänger rumpfuscht. Denn auch bei geänderter Gruppenzuordnung wird immer noch das verschickt, worin eingewilligt wurde: ein Newsletter von Dir an einen Empfänger, für den Du ein valides Double-Opt-In hast.

Das ist ein vielfach anzutreffendes Verhalten, von Programmierern die Lösung von Problemen zu verlangen, die man selber verursacht hat bzw. ganz einfach hätte vermeiden können.

LG, Volkmar

Hallo Mirko,

es ist sehr Schade, dass du die Sache so siehst. Es geht um keine Spezialfunktion oder Hacks.

SWM bietet eine Änderungsfunktion. Diese ist nur nicht konstistent und vollständig implementiert. Gerade das macht es ja so schwierig. Wenn ich schon als Fachmann, der übrigens Handbücher meist sogar von vorn bis hinten liest, drei Wochen brauche, um es einzurichten, dann erfüllt SWM gerade deine Kriterien von einfacher Benutzung für unerfahrene Anwender und Einsatzmöglichkeit für viele Bedürfnisse nicht.

Konsequent wäre es dann, gar keine Änderungsfunktion einzubauen. Also entweder gescheit oder gar nicht. Das gleiche betrifft die Gruppenimplementation. Entweder gescheit oder gar nicht. Du bietest aber Funktionen, die den Eindruck erwecken, dass man etwas bestimmtets mit der Software machen kann, was aber dann nicht wirklich geht. Siehe meine Liste in einem der anderen Posts.

Ich werde in den nächsten Wochen SWM noch einsetzen müssen, bis ich eine andere Lösung habe, aber dann hast du Ruhe vor mir

Marcus

Ich bin ein Mensch und ich verstehe es. Ich glaube Mirko, du solltest nicht immer vom DAU ausgehen. Es gibt genügend versierte Leute, die deine Software einsetzen und denen solltest du mehr zutrauen. Insgesamt ist SWM so kompliziert, dass ein unerfahrener Nutzer sowieso keine Möglichkeit hat, es vernünftig einzusetzen. Die ganze Sache ist generell schon kompliziert und SWM hat viel zu viele Fallstricke. Es wäre viel besser eine gutes und ausführliches Handbuch zuerstellen, das auch mal das Warum erklärt, statt nur das wie.

Das Handbuch liest aber keiner, ich lese auch keine Handbücher und versuche die Sache so hinzubekommen, weil es einfach zu zeitaufwändig ist. Aus dem Grund muss man versuchen das so einfach wie nur möglich zu machen, um mögliche Fehlerquellen auszuschließen. Auf viele Fehlerquellen kommt man auch erst, wenn der Nutzer es einsetzt, d.h. man sieht dann die Fallstricke und versucht diese irgendwie wegzubekommen.

Wie wäre es mit einem Pipe-Zeichen als Trennzeichen oder einem Leerzeichen, wenn die Gruppennamen in Anführungszeihen stehen oder man schreibt die Gruppennamen in eckige Klammern (ob mit oder ohne Leerzeichen ist dann egal). Das ist vom Dateisystem oder von Feldnamen in Datenbanken schon bekannt. Du musst es doch nur in der Dokumentation beschreiben.
Wenn man eine Adresse mit mehrere Gruppenzuordnungen importieren möchte, muss man eh die Daten in das passende Format bringen und muss die ganzen Feldzuordnungen machen. Da ist es doch kein Problem, in der Hilfe, bzw. im Formular eine Zeile Text stehen zu haben, die erklärt, wie man im Gruppenfeld, mehrere Gruppennamen zu trennen hat.

Ja das sind wieder diese \"Hacks\" für die Profis und davon hat SuperWebMailer eigentlich schon wieder viel zu viele. Solche speziellen Dinge könnten wieder zu Fehlern führen z.B. wenn der Nutzer als Trennzeichen das Pipe-Zeichen verwenden will.

Mit der Bestätigungs-E-Mail gibt es keine Probleme, denn ist der Empfänger enthalten, wird keine E-Mail versendet, nur die Gruppe zugeordnet. Das bleibt so und wird sich nicht ändern.

Das ist für einen Import OK. Ich möchte natürlich einen Kunden, den ich von Hand eintrage, z.B. weil er sich vor Ort handschriftlich in eine Mailingliste eingetragen hat, mit der Bestätigungs-E-Mail die Möglichkeit geben, seine Preferenzen, sprich Gruppen, auszuwählen. Das funktioniert natürlich nur, wenn er bereits in alle Gruppen importiert ist, bevor er das Änderungsformular aufruft. Ist er sehr schnell und antwortet gleich, wird er durch den späteren Import wieder in evtl. abgewählte Gruppen eingetragen. Sehr doof.

Ja es gibt immer spezielle Anforderungen jedes einzelnen, die kann ich aber mit einer Standard-Software nicht umsetzen. Ich muss eine Lösung entwickeln, die möglichst viele Bedürfnisse abdeckt. Alles andere ist Individual-Software, d.h. du müsstest dir selbst ein Script entwickeln (lassen), das dann genau deine Bedürfnisse abdeckt. Kommen Anforderungen hinzu, kann man das dann wieder erweitern usw....

.... rechtlich sauber zu implementieren? Ãœbrigens, bei unserem Testlauf waren alle unsere Tester verwundert, warum sie nach einer Änderung keine Bestätigungs-E-Mail erhalten haben.

Die Änderungsfunktion interessiert wirklich kaum jemanden, die wenigsten setzen diese Funktion ein. In den 10 Jahren SuperMailer gab es vielleicht 2 oder 3 Anfragen zum Thema wie man eine Änderungsfunktion implementieren könnte, mehr waren es nicht. Es interessiert wie man neue Empfänger hinzubekommt, d.h. Anmeldungen müssen her, Änderungen meldet sowieso kaum jemand.

Die Gruppen mit Trennzeichen kann man nicht angeben, das versteht kein Mensch. Wenn das Trennzeichen bei den Daten selbst Komma ist und die Gruppen sind auch noch mit Komma getrennt, dann kannst es gleich vergessen.

Ich bin ein Mensch und ich verstehe es. Ich glaube Mirko, du solltest nicht immer vom DAU ausgehen. Es gibt genügend versierte Leute, die deine Software einsetzen und denen solltest du mehr zutrauen. Insgesamt ist SWM so kompliziert, dass ein unerfahrener Nutzer sowieso keine Möglichkeit hat, es vernünftig einzusetzen. Die ganze Sache ist generell schon kompliziert und SWM hat viel zu viele Fallstricke. Es wäre viel besser eine gutes und ausführliches Handbuch zuerstellen, das auch mal das Warum erklärt, statt nur das wie.

Wie wäre es mit einem Pipe-Zeichen als Trennzeichen oder einem Leerzeichen, wenn die Gruppennamen in Anführungszeihen stehen oder man schreibt die Gruppennamen in eckige Klammern (ob mit oder ohne Leerzeichen ist dann egal). Das ist vom Dateisystem oder von Feldnamen in Datenbanken schon bekannt. Du musst es doch nur in der Dokumentation beschreiben.
Wenn man eine Adresse mit mehrere Gruppenzuordnungen importieren möchte, muss man eh die Daten in das passende Format bringen und muss die ganzen Feldzuordnungen machen. Da ist es doch kein Problem, in der Hilfe, bzw. im Formular eine Zeile Text stehen zu haben, die erklärt, wie man im Gruppenfeld, mehrere Gruppennamen zu trennen hat.

Mit der Bestätigungs-E-Mail gibt es keine Probleme, denn ist der Empfänger enthalten, wird keine E-Mail versendet, nur die Gruppe zugeordnet. Das bleibt so und wird sich nicht ändern.

Das ist für einen Import OK. Ich möchte natürlich einen Kunden, den ich von Hand eintrage, z.B. weil er sich vor Ort handschriftlich in eine Mailingliste eingetragen hat, mit der Bestätigungs-E-Mail die Möglichkeit geben, seine Preferenzen, sprich Gruppen, auszuwählen. Das funktioniert natürlich nur, wenn er bereits in alle Gruppen importiert ist, bevor er das Änderungsformular aufruft. Ist er sehr schnell und antwortet gleich, wird er durch den späteren Import wieder in evtl. abgewählte Gruppen eingetragen. Sehr doof.

Und so wird das übrigens auch bei der Änderung der Daten sein, ändert sich die E-Mail-Adresse nicht, gibt es auch keine Bestätigungs-E-Mail.

Das ist OK, wenn die Änderungsseite über einen Link in einer erhaltenen E-Mail aufgerufen wird und dieser Link eine eindeutige nicht vorhersehbare ID enhält. Wird das Änderungsformular aber direkt, z.B. über die Website, aufgerufen, ist dies eine erhebliche Schwachstelle. Aus rechtlicher Sicht wird damit kein Double-Opt-In-Verfahren vollzogen und ein außenstehender Angreifer kann eine SWM-Mailingliste manipulieren. Bei deiner Implementierung könnte man sogar alle Gruppen abwählen und damit die Adresse löschen. Rechtlich schlimmer ist es, wenn jemand so manipuliert, dass eine andere Gruppe hinzugenommen wird. Wenn der Kunde dann für eine andere Gruppe unerwünschte Werbung erhält, kann er nach deutschem Gesetzt eine Abmahnung erwirken. Das kann ganz schön teuer werden. Ich finde die aktuelle Gesetzelage auch weltfremd und einen Blödsinn, aber es interessiert ein Gericht leider nicht, was ich davon halte. Das Problem vor Gericht ist, das der Mailinglistenbetreiber in der Nachweispflicht ist, dass die Änderung vom Kunden stammt. IP-Adressen werden nicht annerkannt. Da der Kunde nicht bestätigen musste, hat der Betreiber von SWM keinen Nachweis. Der Fall wird sicher nicht sehr häufig sein, aber wenn ich auch nur einmal 2000 Euro zahlen muss, weil die Softwarefirma, die mein Mailinglistenprogramm herstellt wissentlich eine Sicherheits- und eine rechtliche Lücke nicht schließt, wäre ich sehr verärgert. Warum weigerst du dich so wehement, SWM konsequent und rechtlich sauber zu implementieren? Ãœbrigens, bei unserem Testlauf waren alle unsere Tester verwundert, warum sie nach einer Änderung keine Bestätigungs-E-Mail erhalten haben.

Ich hatte mich für SWM entschieden, weil ich mit SuperMailer viele Jahre lang weitgehenst zufrieden war, hatte aber eine Serverlösung gesucht. Mit fehlte die Zeit sowas selber zu programmieren, obwohl ich schon vor vielen Jahren entsprechende Designs entworfen hatte.
Aus Termingründen konnte ich, nachdem ich die ganzen Probleme mit SWM entdeckt hatte, nicht mehr umschwenken und musste mit zwei Wochen unerwarteter Mehrarbeit, SWM so hinbiegen, dass es halbwegs funktioniert. Als ich das System unseren Mitarbeiten zeigte, kamen sofort die gleichen Einwände, wie ich sie in den vielen Posts beschrieben habe. Ich setze starke Hoffnung auf das kommende Update. Wir evaluieren aber im Moment bereits andere Systeme, so dass wir dann notfalls umsteigen können. Ich schreibe dir so ausführlich, damit du die Probleme und die möglichen Lösungen besser beurteilen kannst und auch eine gute Entscheidung treffen kannst.

Es gibt Dinge, die sind nice to have, weil sie einem die Arbeit erleichtern und es einem ermöglichen mal nicht wieder zu spät zum Essen nach Hause zu kommen. Es gibt aber auch Dinge, die sind essential und ein KO-Kriterium. Dazu zähle ich absolut die nicht durchgängig vorhandene Nachweismöglichkeit des Requestursprungs und die Gruppenverwaltung. Ein großer Vorteil von SWM ist natürlich der Preis. Der macht SWM so attraktiv. Es gibt zehntausende von kleiner Firmen, die alle mit Mailings kämpfen. SWM könnte hier eine tolle und günstige Lösung sein. Wenn es aber nicht konsequent designed und implementiert ist, dann kann man nur davon abraten. Die Hoffnung stirbt zwar zuletzt, und ich wünsche mir natürlich, dass ich nicht auf eine anderes Mailingsystem wechseln muss, vor allem nach dem erheblichen Aufwand, aber meine Hoffnung kann leider nur noch bis zum nächsten Update warten.

LG Marcus

Die 200er Schritte sind meine Vorgabe, das muss man nicht, kannst auch mehr machen, wenn du das für richtig hälst. Ich selbst mache das immer in 1000er Schritten aber es ist auch mein Server, der muss mit der Last leben.

Die Gruppen mit Trennzeichen kann man nicht angeben, das versteht kein Mensch. Wenn das Trennzeichen bei den Daten selbst Komma ist und die Gruppen sind auch noch mit Komma getrennt, dann kannst es gleich vergessen.

Mit der Bestätigungs-E-Mail gibt es keine Probleme, denn ist der Empfänger enthalten, wird keine E-Mail versendet, nur die Gruppe zugeordnet. Das bleibt so und wird sich nicht ändern. Und so wird das übrigens auch bei der Änderung der Daten sein, ändert sich die E-Mail-Adresse nicht, gibt es auch keine Bestätigungs-E-Mail.

Ãœber das Datumsfeld habe ich anfangs auch mal nachgedacht aber eigentlich braucht das kein Mensch. Ist auch schwer die Daten zu importieren, denn stimmt das Datumsformat nicht, wird es nicht importiert. Du kannst natürlich das Geburtsdatum missbrauchen, das natürlich nur, wenn du es nicht brauchst. Aber an das korrekte Datumsformat denken, sonst wird es nicht übernommen.

Mirko,

ich habe beim Testen festgsellt und im Forum gelesen, dass man beim Import von Adressen, die Adressen nicht mehreren Gruppen zuordnen kann, sondern die Adressen mehrmals mit jeder Gruppe importieren muss. Dies ist aus zweierlei Hinsicht ein Problem.

Imports werden standardmäßig in 200 Schritten importiert, um die Serverlast zu reduzieren. Jetzt muss ich aber 3000 Adressen acht mal (!) (wir haben acht Gruppen) importieren. Das macht überhaupt keinen Sinn.

Das größere Problem ist aber, dass man die Option für die Versendung einer Bestätigungsemail nicht nutzen kann. Hier würde der Kunde acht E-Mails bekommen, die er jeweils bestätigen muss! Das macht kein Kunde. Die Implementierung ist also nicht praktikabel.
Hier wäre es dringend notwendig, dass man alle Gruppen in einem zu importierenden Feld mit einem Trennzeichen gentrennt angeben kann. Ist hier etwas in Planung?

Praktisch wäre auch ein Feld in der Feldliste vom Typ Datum. Importiert man alte Bestände sollte man das Eintragsdatum importieren können, da dies evtl. von rechtlilcher Bedeutung sein kann. Man kann zwar ein Zeichenkettenfeld verwenden, aber ein Datumsfeld wäre gerade bei Mehrsprachigkeit und der verschiedenen Schreibweise von Dati besser.

Marcus