Netz - Rettung - Recht

"Cleanfeed" ist, wie der Name bereits nahelegt, ein Filter für den Newsserver INN, der auf per Feed von anderen Newsservern (Peers) empfangene Artikel wirkt, also den Feed "säubert", vor allem von Spam, böswilligen Massenpostings (als Form des "Angriffs" auf bestimmte Newsgroups) und anderen unerwünschten Erscheinungen. Nachdem die ursprünglich in den Neunzigern von Jeremy Nixon begonnene Entwicklung lange eingeschlafen erschien (und der Filter wie auch die mit ihm ausgelieferte Konfiguration zunehmend überaltert wirkten), hat sich seit 2007 nunmehr Steven Crook der Sache angenommen, einige Updates herausgebracht, die Konfiguration weiter modularisiert und eine Webseite mit entsprechender Dokumentation aufgesetzt.

Dieser "neue" Cleanfeed werkelt jetzt nach der einfachen Installation auf news.szaf.org; nur die Konfiguration bedarf sicherlich noch weiter der Verfeinerung (nachdem ich bisher wie mit dem Vorgänger in den vergangenen Jahren primär auf die Defaults setze).

Im Rahmen der notwendigen Umbaumaßnahmen und der Neueinrichtung von news.szaf.org habe ich endlich auch die Unterstützung von Cancel-Lock und Cancel-Key umgesetzt.

Cancel sind Steuernachrichten zur Löschung anderer Nachrichten im Usenet, vorgesehen zur Löschung eigener Beiträge (oder ggf. noch zur Löschung von Beiträgen durch den Newsadministrator des einspeisenden Servers). Das Protokoll sieht aber keine Verifizierung dieser Nachrichten vor; grundsätzlich kann also jeder Teilnehmer Nachrichten von jedem anderen Teilnehmer löschen, was zwar unzulässig ist und auf breite Ablehnung stößt, aber dennoch in der Vergangenheit gerne vieltausendfach genutzt wurde, nicht nur für von der Netzgemeinschaft akzeptierte Spamcancel, sondern auch für Attacken gegen bestimmte Newsgroups ("leercanceln") oder Netzteilnehmer. Die als Reaktion oft erfolgte Abschaltung der Cancel-Funktionalität war aber auch nicht der Weisheit letzter Schluß.

Daher wurden bereits Ende der Neunziger Vorschläge gemacht, wie das Canceln von Beiträgen nur für Befugte ermöglicht werden kann, nämlich durch das Hinzufügen eines kryptographischen Cancel-Locks in jedem Beitrag, zu dem eine Cancelnachricht den passenden Cancel-Key enthalten muß, wenn sie ausgeführt werden soll. Cancel-Lock und -Key sind dabei zusammengesetzt aus einem geheimen Schlüssel und der Message-ID des jeweiligen (bzw. zu cancelnden) Postings. Nachdem diese Vorschläge jedenfalls auf Client-Seite nie breite Umsetzung - außerhalb einiger unixoider Newsreader - fanden (und sich das Prinzio vermutlich deshalb auch auf Serverseite nicht durchsetzte), bekamen Cancel-Lock und -Key Ende Juni 2007 durch deren verpflichtende Einführung bei dem bedeutenden deutschen Newsserver news.individual.de neuen Auftrieb. Dort hat man nämlich nicht nur die Überprüfung von Cancel-Locks aktiviert, sondern zugleich hinsichtlich der fehlenden Unterstützung im Client zumindest für die eigenen Nutzer insoweit Abhilfe geschaffen als Cancel-Locks durch den Server (!) automatisch allen Beiträgen hinzugefügt werden (und bei berechtigten Canceln wird in gleicher Weise automatisch der passende Cancel-Key eingetragen).

Bereits kurz danach wurden in de.comm.software.newsserver - namentlich durch Alexander Bartolich - erste Implementationen sowohl zum Einfügen als auch zum Prüfen von Cancel-Lock und -Key für den INN veröffentlicht:

• Cancel-Lock in filter_nnrpd.pl setzen
• Cancel-Lock in filter_nnrpd.pl/cleanfeed.local überprüfen
  

Grundsätzlich sind für die Überprüfung von Cancel-Lock und -Key zwei Varianten denkbar: Entweder läßt man die Cancelverarbeitung in Betrieb und filtert unerwünschte Cancel (und Supersedes!) im filter_innd aus, oder man deaktiviert die Cancel-Verarbeitung komplett und führt nur erwünschte Cancel aus filter_innd heraus aus. Letzteres ermöglicht die weitere Unterscheidung, ob man Cancel ablehnen oder zwar annehmen und weiterverbreiten, aber nicht ausführen oder annehmen und ausführen möchte. Weiterhin muß man sich entscheiden, wie man mit Postings ohne Cancel-Lock umgehen will. Für diese Postings kann man weiterhin alle Cancel akzeptieren - oder keinen. (Und man muß sich eine Lösung für Spamcancel überlegen; entweder akzeptiert man signierte Cancel aus vertrauenswürdiger Quelle, oder man implementiert zugleich NoCeM als Ergänzung.)

"INN: Cancel-Lock und Cancel-Key" vollständig lesen

Bereits gestern abend hatte ich bis heute in der Früh störungsbedingt die ersten Dienste (einen semi-öffentlichen bitlbee-Server, die Mailinglisten, den secondary MX für einige Domains) auf die neue Maschine umgezogen; heute war dann der Newsserver dran, der inzwischen auch provisorisch seinen Dienst aufgenommen hat. "Provisorisch" insofern, als er bislang seinen Feed von der alten Maschine bekommt und auch primär nach dort feedet, aber die ersten Peers haben erfreulich schnell auf meine Bitte per E-Mail reagiert und ihren Feed geschwenkt.

Diesmal bemühe ich mich überdies, die Konfiguration des INN direkt von Anfang an "sauber" aufzusetzen und zugleich die ersten Punkte auf (m)einer Liste der geplanten Änderungen und Verbesserungen umzusetzen. Auf dieser Liste finden sich Dinge wie

• die reproduzierbar funktionsfähige Verifikation von Steuernachrichten,
• ein aktueller Cleanfeed,
• das automatische Setzen und das Auswerten von Cancel-Lock/Cancel-Key,
• die Auswertung (ggf. auch Generierung) von NoCeMs,
• das Überarbeiten des Gruppenangebots,
• das Zuweisen von jeweils eigenen Hostnamen pro Feed, um diese ggf. gezielt schwenken zu können
• usw. usf.

Inbesondere letzteres dürfte sich bei künftigen IP-Änderungen bewähren, weil man dann erst einmal einige Feeds auf die neue Maschine schwenken und sie dabei beobachten kann (laufen Hardware und Software stabil? ist alles richtig konfiguriert? …), und bei Bedarf auch Lastmanagement, also die Verteilung der Feeds auf verschiedenen Maschinen, ermöglichen.

Mit dem Umzug des Newsservers sollte dann die Migration von haystack, der alten Maschine, auf den Nachfolger pasture abgeschlossen sein.

Heute ist Freitag der 13.

Natürlich sind wir nicht abergläubisch, aber es ist in gewisser Weise schon passend, daß sich ausgerechnet am heutigen Morgen die Maschine, auf der u.a. der Newsserver news.szaf.org und der Mailinglistenserver laufen, weggehängt hat. Offenbar nähern sich die verbauten Platten rapide ihrem EOL; diesen Schluß läßt jedenfalls das zeitliche Zusammenfallen mit I/O-lastigen Aktivitäten wie dem Durchlauf von news.daily und dem automatisierten Backup zu, bestätigt durch den Blick auf die serielle Konsole zu, auf der sich die Maschine logmäßig gesehen entsprechend "erleichtert" hatte (man könnte auch "ausgekotzt" sagen …). Einen Reboot später war sie wieder da, aber das Raid-Array wirkte in gewisser Weise etwas unsortiert:

Personalities : [raid1]
md7 : active raid1 sdb7[1]
      65898496 blocks [2/1] [\_U]
md6 : active raid1 sda6[0]
      4891648 blocks [2/1] [U\_] 
md5 : active raid1 sda5[0] sdb5[1]
      4891648 blocks [2/2] [UU] 
md1 : active raid1 sda1[0]
      505920 blocks [2/1] [U\_]

Interessant vor allem, daß sich (je nach Partition) teilweise die eine, teilweise die andere Platte weggehängt hat. (Besser gar nicht darüber nachdenken!)

Die gute Nachricht: ein Umzug der Maschine ist schon länger geplant, und der Nachfolger ist bereits seit August gebucht (und zumindest teilweise auch schon eingerichtet). Nur der Umzug der Dienste wartete noch auf das berühmte "freie Wochenende" oder "mal eine Woche Urlaub". Insofern dürfte es sich empfehlen, die Kiste nach Möglichkeit nicht mehr als unbedingt nötig anzufassen (insbesondere I/O-lastige Aktivitäten zu unterlassen) und den Umzug zu forcieren. Jetzt ist ja zumindest mal Wochenende …

Man sagt, E-Mail sei in früheren Zeiten technisch bedingt ein eher unzuverlässiges Medium gewesen: schmale Anbindungen, schwachbrüstige oder unter Leistungsgesichtspunkten knapp kalkulierte Server, Auslieferung über viele verschiedene Zwischenstationen (Hops), teilweise über Systeme, die nicht permanent ans Internet angebunden sind (store-and-forward), teilweise auch unzuverlässige Software, zumindest bei einem hinreichend breit gefaßten Begriff von E-Mail auch viele verschiedene, zueinander inkompatible Formate (Internet-E-Mail, X.400, Mail über UUCP, private Nachrichten in Mailboxnetzen, …), die untereinander umgesetzt werden mußten, teilweise über Netzgrenzen hinweg.

Das ist heute Vergangenheit. E-Mail wird in der Regel nur noch als "Internet-E-Mail" ausgetauscht, die betreffenden Server sind per ausreichend dimensionierter Standleitung ans Netz angebunden und entsprechend leistungsmäßig - wenn sich natürlich auch jede Infrastruktur durch genügend E-Mails, meistens im Rahmen der Versendung von Spam oder Malware, in die Knie zwingen läßt -, die Protokolle sind verfeinert und erweitert und man muß nicht mehr damit rechnen, daß irgendwelche Konvertierungen zu Informationsverlusten führen oder sich zwingend auf den ASCII-Zeichensatzvorrat (ohne Umlaute o.ä. oder gar "Anhänge") beschränken.

Dieser Zugewinn an technischer Sicherheit wird m.E. aber leider oft durch administrative Maßnahmen mehr als aufgewogen: technisch mag es zwar trivial sein, E-Mail auszuliefern, aber administrativ führen Abwehrmaßnahmen gegen tatsächliche oder vermeintliche Bedrohungen (Blacklists, Filterung jenseits technisch zwingender Notwendigkeit, Greylisting, Sender-Verification-Callouts, SPF und Co., BATV, DKIM und Co., Spam-, Viren- und andere Contentfilter etc. pp.) und nicht selten auch bloße Inkompetenz derjenigen, die "mal eben" einen Mailserver aufsetzen, dazu, daß die Mailzustellung faktisch langsamer und schwieriger wird und teilweise für den Absender noch nicht einmal erkenbbar wird, daß seine E-Mail den Adressaten nicht erreicht hat). Das gilt insbesondere, wenn verschiedene Filtertechniken oder Konfigurationen auf Absender- und Empfängerseite miteinander interagieren, was zu unerwarteten Folgen führen kann.

"Zuverlässigkeit von E-Mail als Medium" vollständig lesen

Schon seit vielen Jahren verwende ich eine Subdomain zur Vergabe von personalisierten E-Mail-Adressen, die ich dann für Zwecke verwenden kann, bei denen ich meine normale E-Mail-Adresse nicht preisgeben möchte, bspw. das Abonnieren von Newslettern, an deren Seriösität ich Zweifel habe, für Webshops etc. pp. Das hat den Vorteil, daß sich über diese personalisierten E-Mail-Adressen nachvollziehen läßt, aus welcher Quelle bspw. Spammer ihre Adressen bezogen haben, und, viel wichtiger, daß sich diese Adressen rückstandslos entsorgen lassen, wenn sie missbraucht werden. Insgesamt eine gute Idee; die Frage ist immer nur, wie man sich diese Adressen erzeugt.

Meine erste Lösung war ein Catch-All, was aber den Zweck der Übung letztlich konterkarierte, weil man auf diese Weise eine unbegrenzte Anzahl valider E-Mail-Adressen erzeugt und Spam potentiell potenziert. Zwar kann man bestimmte Adressen selektiv deaktivieren, bspw. über eine Aliases-Datei, in der sie explizit geerdet werden und ein Catch-All als Fallback für nicht explizit definierte Adressen verwendet wird, aber Spammer permutieren Adressen gerne; wenn man abashop@domain.example deaktiviert, bekommt man stattdessen vielleicht Mail an abasho@domain.example und an abash@domain.example und an … So hat sich das nicht bewährt.

Also habe ich die Adressen stattdessen in einer Aliases-Datei explizit definiert (und für eine Übergangszeit doch einen Catch-All als Fallback verwendet, für den Fall, daß ich eine bereits verwendete Adresse vergessen hatte …). Das tat etliche Jahre seinen Zweck, hatte aber den Nachteil, daß ich mich für Änderungen immer erst auf dem entsprechenden Host einloggen und die Datei ändern mußte. Unbequem und, wenn man gerade unterwegs ist und nur Webzugriff hat, erst gar nicht möglich. Also habe ich reichlich oft doch meine Hauptadresse für diverse Anmeldungen verwendet; diesen Nachteil gab es bei der Verwendung des Catch-All nicht.

Die Lösung wäre - so war mir ebenfalls seit langer Zeit klar - die Verwendung eines bequemen, nach Möglichkeit webbasierten Interfaces zur Anlage neuer solcher Adressen, damit der innere Schweinehund nicht mehr dazwischenkommen kann. Und diese Lösung habe ich jetzt endlich umgesetzt. Zumindest provisorisch, aber das wird vermutlich wieder so ein langlebiges Provisorium werden …

"Personalisierte Mailadressen" vollständig lesen

Ich hatte bereits am 20.05.2009 über die bemerkenswerte Entscheidung des BGH zur Beschlagnahme von E-Mails beim Provider ("in der Mailbox") berichtet, nach der die Vorschriften über die Postbeschlagnahme einschlägig sind, nicht etwa § 100a StPO, mit der Folge, daß weder eine Katalogtat noch ein gesteigerter Tatverdacht ("bestimmte Tatsachen") noch eine ultima-ratio-Situation vorliegen müssen. Ich hatte dabei auch bereits (vielleicht etwas süffisant) angemerkt, daß das BVerfG schon seit Ende 2006 anläßlich einer Verfassungsbeschwerde über dieser Frage brütet.

Nunmehr hat man dort zu Ende gebrütet und im Ergebnis die Ansicht des BGH bestätigt bzw. ist noch über diese Ansicht hinausgegangen. Mit Beschluß vom 16.06.2009 - 2 BvR 902/06 - hat das BVerfG festgehalten, daß die Beschlagnahme von E-Mails, die beim Provider gelagert sind, zwar in das Grundrecht aus Art. 10 GG eingreift, die allgemeinen Beschlagnahmevorschriften aber (bei besonderer Beachtung des Verhältnismäßigkeitsgrundsatzes) zur Rechtfertigung des Eingriffs genügen, und die Verfassungsbeschwerde zurückgewiesen.

"Beschlagnahme von E-Mails: BVerfG bestätigt BGH" vollständig lesen

Leider nehmen mich Job und Privatleben weiterhin so intensiv in Anspruch, daß ich weder in der vergangenen Woche Gelegenheit zu umfangreichen Blogeinträgen hatte noch dies voraussichtlich in der kommenden Woche haben werde - hier muß also leider weiterhin Sendepause herrschen, was umso ärgerlicher ist, als es mir an Themen derzeit beileibe nicht mangeln würde … Ich kann auch nicht versprechen, daß es in der übernächsten Woche besser wird, aber vielleicht im kommenden Monat wieder?

Stay tuned!

Am Wochenende habe ich mich - endlich - mal wieder meiner Ablage gewidmet und Kontoauszüge, Rechnungen, Bestellungen, Gehaltsabrechungen, Steuerbescheide und was einem sonst noch so die sommerlichen Temperaturen verderben kann sortiert und abgelegt. Dabei stellte ich fest, daß mir für diverse Accounts bei 1&1 die Rechnungen aus dem Juni fehlten: Mai war da, Juli auch, Juni fehlt. Nachdem die Rechnungen per E-Mail versandt wurden, habe ich natürlich als erstes einmal nachgesehen, ob ich wohl vergessen hatte, sie auszudrucken; aber nein, es liegen auch keine E-Mails vor.

Eine genauere Untersuchung ergab dann, daß die Rechnungs-E-Mails nicht angenommen wurden, weil die entsprechenden E-Mails eine nicht-existente Absenderadresse aufwiesen:

2009-06-05 16:39:55 H=mbulk.1and1.com [212.227.126.221] F=<bill-iid-***-200906051626-***@bounce.kundenserver.de> rejected RCPT <thh@***.de>: Sender verify failed

Sehr nervig. Hilft also nur, den entsprechenden Mailserver (hier wohl mbulk.1and1.com) zu whitelisten. *brummel*

Manchmal läßt sich die Qualität der Netzwerkverbindung durch simples Umstöpseln des Netzwerkkabels geradezu durchschlagend verbessern:

Inter-|   Receive                                                      
 face |     bytes   packets   errs drop fifo frame compressed multicast
  eth0: 208559761  23066399 819028    0    0     0          0         0
  eth1:  43253328    452956      0    0    0   510          0         0

Inter-|   Transmit
 face |      bytes  packets errs drop fifo   colls carrier compressed
  eth0: 2096539748 21039275 1840    0    0 3360058    3680          0
  eth1: 1767124698  1210761    0    0    0       0       0          0

Sieht so aus, als habe es die Netzwerkkarte im wesentlichen hinter sich:

Jul 5 14:13:32 xerxes kernel: [2762629.588855] eth0: link up, 10Mbps, half-duplex, lpa 0x0000
Jul 5 14:14:50 xerxes kernel: [2762707.126012] eth1: link up, 100Mbps, full-duplex, lpa 0x45E1

(Ja, es ist natürlich in Wirklichkeit eine 100Mb-Vollduplex-Verbindung.)

Das Solitude-Chor, das Sinfonieorchester der Universität Hohenheim und die New York City Dance School haben gestern abend (u.a.) Gloria und Magnificat von Rutter aufgeführt - letzteres durch die tänzerischen Einlagen zunächst etwas gewöhnungsbedürftig, aber nicht schlecht! Nachdem die Aufführung im Theaterhaus und nicht in einer Kirche stattfand, war allerdings die Orgel teilweise etwas piepsig besetzt …

Da ich als Konzertkritiker sicherlich eine Fehlbesetzung wäre, nur so viel: das Konzert hat mir sehr gut gefallen (auch der zweite Teil, nachdem eine energische Besucherin den Photographen mit Spiegelreflexkamera zur Ruhe gebracht hatte - das ständige Klicken störte den musikalischen Genuß doch nicht unwesentlich), und ich kann einen Besuch der nächsten - und letzten - Aufführung heute abend um 20 Uhr nur empfehlen.

Das Schlimmste am Tod von Michael Jackson ist, daß sie im Radio unablässig Musik von ihm spielen.

Als "Verkehrsrichter" hat man es nicht leicht, weder in Straf- noch in Bußgeldsachen. Auf der einen Seite soll man die Sünder strafen, auf daß sie sich bessern und im Verkehr nicht wie die Axt im Walde aufführen und neben ihrem eigenen auch Leib und Leben ihrer Mitmenschen gefährden; auf der anderen Seite scheint das "Heilig’s Blechle" und damit auch die Erlaubnis, ein solches zu lenken, oft der Deutschen liebstes Kind, und es hängen nicht nur bei Berufskraftfahrern oft Arbeit und Lebensgestaltung am Führerschein. So haben sich verschiedene Möglichkeiten entwickelt, insbesondere dem Fahrverbot in Bußgeldsachen noch einmal zu entkommen, unter Ausnutzung der Unverbindlichkeit des Verwarnungs- und Bußgeldkatalogs, der nur Behörden binden kann, aber nicht die unabhängigen Gerichte, für die er allenfalls Richtliniencharakter hat. Verbreitet ist bspw. die Erhöhung - Verdoppelung - der Geldbuße, um dafür dann vom Fahrverbot abzusehen (§ 4 Abs. 4 BKatV). Ob eine solche Vorgehensweise vom Zweck der Norm her - Strafe und Prävention - sinnvoll ist, sei dahingestellt.

Das OLG Hamm - 2 Ss OWi 803/08 - hatte im vergangenen November einen Fall zu entscheiden, bei dem der erstinstanzlich erkennende Amtsrichter aus Recklinghausen noch kreativer wurde:

"Der Betroffene ist bislang verkehrsrechtlich nicht in Erscheinung getreten, insoweit wird auf die Auskunft des Kraftfahrt-Bundesamtes vom 14.04.2008 verwiesen.

Am 18.07.2007 erließ der Landrat des Kreises S einen Bußgeldbescheid gegen den Betroffenen.

Dem Betroffenen wurde zur Last gelegt, am 09.06.2007 gegen 14.51 Uhr in S die B-Allee mit dem Pkw […] Fabrikat VW befahren zu haben und dabei die zulässige Höchstgeschwindigkeit innerhalb geschlossener Ortschaften um 23 km/h überschritten zu haben, § 3 Abs. 3, 49 StVO, 24 StVG. Gegen den Betroffenen wurde ein Bußgeld in Höhe von 50,- Euro festgesetzt sowie 1 Punkt.

Der Betroffene wandte sich nicht gegen das Messergebnis.

Das Gericht verdoppelte die Geldbuße auf einen Betrag in Höhe von 100,- Euro und ließ den Punkt, der ansonsten beim Kraftfahrt-Bundesamt einzutragen gewesen wäre entfallen.

Das Gericht hat dabei die Grundsätze der Festsetzung einer Geldbuße in Verbindung mit einem Fahrverbot (Bußgeldkatalog-Verordnung-BKatV) in analoger Anwendung zu Grunde gelegt.

Bezüglich der Festsetzung von Punkten besteht nach Ansicht des Gerichts insofern eine planwidrige Regelungslücke, die im Gesetz keine Stütze findet.

Es liegt jedoch eine vergleichbare Interessenlage vor, die zu Gunsten des Betroffenen gegeben ist.

Das Gericht hat daher die Geldbuße verdoppelt und den Punkt entfallen lassen. Dabei hat das Gericht auch berücksichtigt, dass der Betroffene bislang keine Eintragungen beim Kraftfahrt-Bundesamt hat und in der Tat oder der Persönlichkeit des Betroffenen keine Umstände hervorgetreten sind, die darauf schließen lassen, dass gerade bei diesem Betroffenen eine Besinnung auf seine Pflichten als Kraftfahrzeugführer durch eine Geldbuße nicht zu erwarten ist."

"Die Grenzen richterlicher Rechtsentwicklung" vollständig lesen

Anfang der Woche hatte ich kurz das Instrument des "Verdeckten Ermittlers" angesprochen. Aber was ist ein "Verdeckter Ermittler", kurz "VE"?

Es handelt sich beim "Verdeckten Ermittler" (in der StPO geregelt in §§ 110a-110c) um einen entsprechend geschulten und qualifizierten Polizeibeamten, der unter einer sog. "Legende", also einer falschen Identität mit falschem Namen und falscher Lebensgeschichte, auch mit falschen Papieren, insbesondere im Bereich der Organisierten Kriminalität ermittelt. Der Einsatz als VE ist nicht ungefährlich; er wird daher oft durch Begleitmaßnahmen wie Observation durch ein Mobiles Einsatzkommando (MEK), Einsatz technischer Mittel oder das Abhören des nicht-öffentlich gesprochenen Wortes abgesichert. Der VE tritt im Strafverfahren aufgrund der Gefahren, die bei einer Aufdeckung seiner Identität für seine weitere Einsetzbarkeit, aber auch für ihn persönlich drohen, in der Regel nicht selbst auf; wenn, dann wird er in einem anderen Raum vernommen und seine Vernehmung audiovisuell unter Verfremdung von Bild und Ton in den Gerichtssaal übertragen. In der Regel tritt aber sein Führungsbeamter als "Zeuge vom Hörensagen" auf. Die Vernehmung eines VE kann durch das Gericht nicht erzwungen werden; die Polizeibehörden können sich weigern, dessen Identität aufzudecken (§ 96 StPO).

Neben VEs kennt die polizeiliche Praxis auch sog. "nicht offen ermittelnde (Polizei-)Beamte", kurz noeP oder noeB. Das sind Polizeibeamte, die ebenfalls in zivil und ohne Aufdeckung ihrer polizeilichen Tätigkeit ermitteln, aber weder über eine auf Dauer angelegte falsche Identität ("Legende") noch falsche Papiere o.ä. oder besondere Rechte verfügen; ihr Einsatz ist nicht gesetzlich geregelt. Eingesetzt werden sie bspw. als Scheinkäufer in der offenen Drogenszene.

Im Unterschied dazu sind sogenannte "Vertrauenspersonen" (VP, auch "V-Leute" oder schlicht "Spitzel") weder Polizeibeamte noch besonders geschult. Es handelt sich um Privatpersonen, denen von der Staatsanwaltschaft Vertraulichkeit zugesagt wurde, deren Identität also im Strafverfahren nicht aufgedeckt wird (und die auch in der Regel nur der Polizei, nicht der Staatsanwaltschaft bekannt ist), und die aus den verschiedensten Gründen bereit sind, der Polizei Informationen zu liefern, oft auch gegen Geld. Entsprechend ist auch ihre Glaubwürdigkeit zu beurteilen, zumal VP oft selbst aus dem entsprechenden (kriminellen) Milieu stammen.

Schon gestern hatte ich über eine Entscheidung des BGH aus dem Januar berichtet, der ein eher ungewöhnliches Vorgehen der Ermittlungsbehörden zugrunde lag. Damit aber nicht genug; auch im April hatte der BGH über durchaus eigenartige Ermittlungsmaßnahmen zu entscheiden. Auch wenn das Urteil vom 29. April 2009 – 1 StR 701/08 - bei der Dokumentationsstelle des BGH derzeit noch nicht vorliegt, läßt schon die Pressemitteilung erahnen, daß der Sachverhalt nicht alltäglich ist:

Der aus Marokko stammende Angeklagte wurde wegen Mordes zu einer lebenslangen Freiheitsstrafe verurteilt. Er heiratete eine in Deutschland lebende Marokkanerin, zog zu ihr und besuchte einen Deutschkurs; mit der gleichfalls verheirateten Lehrerin begann er ein außereheliches Verhältnis. Als diese seine plötzlich gestellte Forderung, ihren Mann zu verlassen und mit ihm ins Ausland zu gehen, zurückwies, erpresste er sie mit heimlich hergestellten Aufnahmen des gemeinsamen Geschlechtsverkehrs. Bei einem späteren Treffen entchloss er sich, sie wegen ihrer weiteren Weigerung zu töten, und erwürgte sie. Nach Entdeckung des Verschwindens der Lehrerin geriet der Angeklagte durch Auswertung der Verbindungsdaten der Verstorbenen in Verdacht, diese getötet zu haben, weil sie zuletzt mit ihm telefoniert hatte. Er räumte das Treffen ein, bestritt aber die Tat.

"Beweisverwertungsverbote II: Heimliches Abhören in der Haft" vollständig lesen