Diskussion:Piratenmagazin/Vorratsdatenspeicherung

Ich werde mir den Text mal durchlesen und versuchen ihn zu verbessern. Allerdings würde ich die Gegenmaßnahmen eher sehr kurz halten oder ganz ausgliedern, da dafür noch eigene Artikel geplant sind. --Hoshpak 19:45, 23. Dez. 2007 (CET)

zwecks Zerlegung des Artikels

Es erscheint mir auch sinnvoll, den Artikel in mehrere kleine Teile zu zerlegen, er wird sonst tendenziell zu lang — den technischen Teil zu emails sollten wir wohl auch besser woanders hin verschieben... Orca, 23.12.2007, 21:56

Ich habe jetzt mal angefangen, den Artikel zu überarbeiten. Tendenziell würde ich jetzt noch den technischen Teil über Emails ganz weglassen. Das mag zwar für uns ganz interessant sein, aber die Zielgruppe des Piratenmagazins ist in der Regel weniger technisch versiert. Ansonsten würde ich wie gesagt die Umgehungsmaßnahmen in mehrere Einzelartikel auslagern (Anonymisierungsdienste, Mailboxen etc.) und am Ende des Artikels nur noch eine kurze Zusammenfassung und Erläuterung der rechtlichen Gegebenheiten stehen lassen. Ich werde im Laufe des Tages den Artikel weiter überarbeiten. --Hoshpak 11:37, 26. Dez. 2007 (CET)

Überarbeitung der Gegenmaßnahmen des BVerfG und Europäischen Gerichtshofs

Hallo Jamasi, ich bin kein Jurist, aber völlig mit Deinen Änderungen einverstanden — und froh, dass jemand das redigiert ;) Orca, 25.12.2007, 10:59 CET

Ich bin zwar auch kein Prargraphenreiter, aber wir wollen ja schon sachlich korrekt bleiben bei diesem Artikel. Man könnte auch die Rolle von Fr. Zypries noch etwas genauer beleuchten. --Jamasi 13:47, 25. Dez. 2007 (CET)

Das ist richtig: die Zypries ist eine richtig hinterhältige und verlogene Heuchlerin, wie auf Telepolis schon mehrmals treffend heraus gestellt wurde, und sachliche Korrektheit ist wichtig, wir wollen klären, nicht verwirren. Orca, 25.12.2007, 19:25 CET

Mail-Adressen-Paar-Speicherung

Diesen Absatz würde ich aus dem endgültigen Artikel herauslassen. Er ist zu technisch und überschneidet sich teilweise mit dem vorhergehenden. Deswegen vorerst hier her verschoben.--Hoshpak

Diesen ersten, technischen Absatz mögen einige einfach überspringen, ich kann mir ihn jedoch nicht verkneifen (Zusammenfassung folgt danach ab Kurz gefasst): eine email besteht als TCP-session des SMT(P)-Protokoll aus mehreren wesentlichen Teilen mit folgender Bedeutung und Reihenfolge (Mindestanforderung):

Envelope-Teil (wird vom Mailserver geloggt):

• banner/handshake (EHLO oder älter, einfacher HELO): FQDN des Mail client/server, viele Mailserver akzeptieren hier allerdings entgegen dem RFC auch beliebige oder sogar leere Strings, manche sogar das Weglassen; bsp.: mail.example.com

• mail from: Absender als reine email-Adresse (Info-Strings sind hier verboten, vgl.u., body), z.B. <smith@example.com>, kann aber auch leer bleiben (für delivery notifications), also nur <> stattdessen (RFC-konform!)

• rcpt to: zwingend erforderlich ist hier die reine email-Adresse des Empfängers (s.o. und vgl.u., keine Info-Strings!), sonst ist die Zustellung nicht möglich! Bsp: <doe@example2.com>

Nun folgt ein Schalter ohne Parameter, der vom envelope in den body der email wechseln lässt:

• data

Body-Teil (Mischmasch aus client Headern und dem eigentlichen Mail-Inhalt! Wird von Mailservern nicht geloggt!):

• from: Wiederholung (?) des Absenders, auch mit Info-String, z.B. "Joe Smith <smith@example.com>", das wird später vom Mail-Client angezeigt

• to: Wiederholung (?) des Empfängers, ebenfalls mit Info-String möglich, Bsp.: "John Doe <doe@example2.com>"

• subject: Betreff der email als freier Text, kann nicht regulär verschlüsselt werden

• der eigentliche email-Text, wenn man verschlüsselt, wird nur dieser Teil verschlüsselt!

Man sieht, dass das Mailserver-Logging der Sender-Adresse sich unterbinden lässt, wenn man als mail from: <> nimmt und die email sozusagen als bounce tarnt (dafür ist diese Möglichkeit wie erwähnt eigentlich gedacht).

Kurz gefasst: wenn man es schafft, den für die Zustellung nicht nötigen (envelope=Umschlag-)Absender-Header zu unterdrücken, den DNS-Namen des client anonym anzugeben und zudem noch den Mail-body mit Absenderinformationen zu verschlüsseln, besteht für die VDS keine Möglichkeit mehr, den Sender zu erkennen. Details s.u. unter Gegenmaßnahmen.

Das Ziel dieser Maßnahme ist die Erfassung sozialer Netzwerke, was eine äußerst gefährliche Sache ist, weil wie im Web auch für email-Beziehungen gilt: über relativ wenige Leute, mit denen man emails tauscht, deren Mail-Partner usw. lassen sich weite, indirekte Verknüpfungen zu völlig Fremden bilden, von denen nicht einmal der email-Versender etwas weiss. Wenn jemand auf diese Weise versucht, die Angehörigen eines Terror-Netzwerks zu ermitteln, werden zweifellos unzählige Unschuldige hier mit hinein gezogen.

Ein weiteres Problem stellt der allgegenwärtige Spam dar: zum Einen entwertet er die Logs der Mailserver durch zahlreiche Fehleinträge (die email-Adressen in spams sind praktisch immer gefälscht/Fantasie), zum Anderen gefährdet er diejenigen, deren echte email-Adressen von Spammern missbraucht werden sowie diejenigen, die emails von solchen gefälschten Adressen erhalten, die anders auffällig geworden sind. Hier können Dritte Unschuldige problemlos bis in den Terrorverdacht bringen!