Reliable - Benutzerhandbuch

Übersetzt: Michael Uplawski <der_ups@gmx.net>
Stand: 09. März 1999 (Reliable 1.0.h / i / j)

Inhalt

Einführung

Was ist Reliable?

Nachrichten-Formate

Informationen anfordern
Cypherpunk Nachrichten-Format
Format PGP-verschlüsselter Nachrichten
Mixmaster-Format

Remailer-Kommandos und Header

Remailer-Kommandos:

Anon-To:
Anon-Post-To:
Remix-To:
Encrypt-To:
Remail-To:
Test-To:
Encrypt-Test:
Null:
Rand-Hop:
Latent-Time:
Cutmarks:
Encrypt-Key:
Inflate:
Max-Size:
Max-Count:
Max-Date:
Encrypted:


Mail-Header
:

Subject:
Newsgroups:
Followup-To:
From:
CC:, Bcc:
Reply-To:

Besondere Funktionen

Max-Size, Max-Count, Max-Date
RePGP
Remix
Gewichtung von Kommandos
Beispiele

Konfigurationen

Remailer-Optionen
Eigenheiten der Reliable-Remailer

Verweise

Glossar
Administratorenhandbuch
Linksammlung der Potato Software Homesite
" Potato Software Knowledge Base "
Deutsche Dokumentation: Reliable
Reliable Homepage
Remailer und Pseudonymserver, Anleitungen


Was ist Reliable

Reliable ist ein anonymer, Typ I / Typ II -Hybrid- Remailer, der auf Windows-Systemen läuft
Das Benutzerhandbuch soll ein Leitfaden für Nutzer und Betreiber von Reliable-Remailern sein. Es beschreibt die Nachrichtenformate, die vom Remailer akzeptiert werden und erklärt die Remailer- Kommandos, mit deren Hilfe die Art und Weise kontrolliert wird, wie Nachrichten verarbeitet werden.

Dieses Handbuch kann auch als Nachschlagewerk zu Remailern im Allgemeinen dienen. Die meisten Informationen, die hier zu finden sind, gelten für alle Remailer. Trotzdem sollten sich Nutzer die Eigenheiten von Reliable-Remailern verdeutlichen.

Wenn Sie Interesse daran haben, auf Ihrem eigenen System einen öffentlichen oder privaten Reliable-Remailer zu betreiben, arbeiten Sie bitte zusätzlich zu diesem Text auch mit dem Administratorenhandbuch. Reliable kann sowohl einen öffentlichen Remailer darstellen, der die Nachrichten von Remailer- Nutzern akzeptiert, als auch einen privaten, lokalen Remailer, der Nachrichten ansammelt ("poolt"), umsortiert und zusätzlichen Datenverkehr zur Tarnung erzeugt.

Reliable-Remailer sind Cypherpunk / Mixmaster - Hybride.
Cypherpunk-Anweisungen (Latent-Time, Encrypt-Key, etc.) können in allen Nachrichten zur Anwendung kommen. Cypherpunk- und Mixmaster-Nachrichten werden zusammen verarbeitet und gesammelt. Der Betreiber kann den Remailer so konfigurieren, dass er ausschließlich Cypherpunk-Nachrichten-, nur Mixmaster-Nachrichten oder beides akzeptiert.

Mit Reliable werden einige neue Remailer- Anweisungen eingeführt und mehrere der existierenden Kommandos erweitert, um die Sicherheit von Reply-Blöcken und die Zuverlässigkeit von Remailern zu verbessern. Eine eingebaute Test-Funktion ermöglicht es Nutzern, die Qualität von Test-Nachrichten zu ermitteln. So soll die Anzahl von Test-Nachrichten reduziert werden, die bisher erforderlich war, um Problemen auf die Spur zu kommen. Einsteiger erhalten schneller konkrete Hinweise zur korrekten Handhabung.


Informationen anfordern

Reliable-Remailer beantworten Anfragen. Um Informationen abzufragen, senden Sie eine leere Nachricht direkt an die Remailer-Adresse. Notieren Sie eines der folgenden Kommandos im Betreff (Subject) Ihrer Nachricht. Der Remailer antwortet mit der bestellten Information.

Subject Funktion
remailer-conf
oder
reliable-conf
oder
freedom-conf
Gibt zusammengefasst die Konfigurationseinstellungen des Remailers zurück. Darin enthalten sind die Remailer- Kommandos und Optionen, die unterstützt werden aber auch andere verwertbare Hinweise. Nicht alle Betreiber von Remailern aktivieren jede Option, die im vorliegenden Text erwähnt wird. Die Information aus remailer-conf beschreibt die Fähigkeiten des Remailers
remailer-help Gibt den Hilfetext für den Remailer zurück. Betreiber passen im Idealfall die Hilfedateien der Remailer-Software an ihren speziellen Dienst an.
remailer-key Gibt den Remailer-Schlüssel zurück (Cypherpunk und/oder Mixmaster). Diese Schlüssel werden dazu verwendet, den Remailer zur verschlüsselten Weiterleitung von Nachrichten anzuweisen.
remailer-stats Gibt die Anzahl der Nachrichten zurück, die der Remailer während der letzten Woche verarbeitet hat (Beachten Sie: diese Funktion ist in Reliable 0.9 noch nicht eingebaut).

Cypherpunk Nachrichten-Format

Remailer werden dazu verwendet, Email anonym zu versenden. Schicken Sie dazu einen "Remail-Request" an den Remailer. Die darin enthaltene Nachricht wird anonym an die Adresse gesendet, die Sie bestimmen. Alle originalen Email-Header werden entfernt und der Ursprung der Nachricht wird dem Empfänger nicht bekannt.

Die einfachste Form des Remail-Request ist Cypherpunk. Cypherpunk-Nachrichten können mit jedem standardmäßigen Email-Programm erzeugt werden (Wenn Ihre Software MIME anwendet, stellen Sie die MIME-Kodierung vorher ab, oder Ihre Nachricht kann verloren gehen). Um Fehler zu vermeiden und zur größeren Bequemlichkeit, ziehen Sie die Verwendung eines Remailer-Clients in Betracht, um Ihre Remail-Requests automatisch zu erzeugen.

Es folgt ein Beispiel für das grundlegende Format von Cypherpunk-Nachrichten (Stellen Sie sich den Rahmen als Begrenzung Ihres Text-Programmes oder des Text-Feldes Ihres Email-Programmes vor):

::
[Remailer-Kommandos]

[Nachrichtentext]

Remailer- Kommandos fordern den Remailer auf, die Nachricht so zu behandeln, wie Sie es wünschen. Sie müssen mindestens eine Anweisung notieren, um dem Remailer mitzuteilen, wohin er die Nachricht weiterleiten soll. Die leere Zeile vor dem Nachrichtentext ist zwingend notwendig.

Der folgende Cyphperpunk Remail-Request zeigt zusätzlich die Bedeutung von " Hash-Headern ":

::
[Remailer-Kommandos]

##
[Hash-Header]

[Nachrichtentext]

Hash-Header sind zusätzliche, Mail-Header, die Sie der Nachricht hinzufügen wollen, wie z.B. ein Betreff (Subject).

Es folgt beispielhaft ein Remail-Request mit Headern und Text:

::
Anon-To: empfaenger@zieldomain.de
Latent-Time: +1:00

##
Subject: Beispiel einer anonymen Nachricht

Dies ist der Text der Nachricht, die weitergeleitet wird.
Der Empfänger wird mit dem Kommando "Anon-To:" benannt.

Die letzte Nachricht weist den Remailer an, den Nachrichtentext anonym an den Endempfänger (empfaenger@zieldomain.de) zu senden. Der Betreff-Header ist "Beispiel einer anonymen Nachricht". Das Kommando Latent-Time fordert den Remailer auf, die Nachricht um ein Stunde zurückzuhalten (was die Sicherheit erhöht).

Zum Versenden eines Cypherpunk Remail-Requests mit einem Standard Email-Programm (nicht mit einem Remailer-Client), setzen Sie die Remailer-Adresse ins To-Feld der abgehenden Nachricht ein. Sie können das Subject freilassen. Kopieren Sie den obigen Text in den Nachrichtenkörper. Die Zeile "::" sollte die allererste der Nachricht sein.

Zur Beachtung:


Format PGP-verschlüsselter Nachrichten

Sollte der Cypherpunk -Remailer, an den Ihr Remail-Request geht, PGP zu seinen Optionen zählen, können Sie die Nachricht mit dem öffentlichen PGP-Schlüssel des Remailers verschlüsseln. Dadurch wird Ihr Remail-Request für die Strecke zwischen Ihrem Computer und dem Remailer verschlüsselt, was seine Sicherheit und Ihre Anonymität erhöht. Jemand, der die Nachricht abfängt, kann den Endempfänger Ihres Nachrichtentextes nicht ermitteln. Wenn der Remailer einen PGP-verschlüsselten Remail-Request empfängt, entschlüsselt er ihn und verarbeitet die darin enthaltene Nachricht.

Um einen PGP-verschlüsselten Remail-Request zu erzeugen, schreiben Sie zunächst eine Klartext-Version des Remail-Request, wie im vorigen Abschnitt gezeigt. Zum Beispiel:

::
Anon-To: end.empfaenger@sein.isp.com
Latent:Time: +1:00

##
Subject: Beispiel einer anonymen Nachricht

Das ist der Text der Nachricht, die zum genannten
Endempfänger (Anon-To Kommando) gesendet werden soll.

Sichern Sie diesen Text in einer Datei und verschlüsseln Sie sie im Anschluss mit dem öffentlichen PGP- Schlüssel des Remailers unter Verwendung von PGP 2.6.x oder kompatiblen. Die verschlüsselte Ausgabedatei wird irgendwie so aussehen:

-----BEGIN PGP MESSAGE-----
Version: 2.6.3in

owEdjk1OxDAMRrtEkXKH7wBtLoDEArGADSsukLTu1NCxR4kznV6K+7Ej7cbyz6f3
/Nt13Z89CbEEe1ibuncO3nn3qbCFC7j00Bmj1lyoh6i1PYFkzPvNaMKdcmEV71rq
uMSkd4LRwwJeq+EDWywYa2atjcUzouxJp927Tet6AnjeQ2jaYRi8e4uH1SDRKuWV
xwXSimGijK/G7c9OEwmK0WK9d0doixlp1QKheuEGvbTPE6jgm65RJlwp/9jp8e55
ePHuHw==
=j/F+
-----END PGP MESSAGE-----

Achtung : Beim Verschlüsseln sollten Sie bedenken, dass die Ausgabedatei ASCII-Text sein muss und dass die örtlichen Übertragungsrichtlinien eingehalten werden. Sollten Sie Ihren originalen Request als EXAMPLE.TXT gespeichert haben, würde Ihr PGP-Kommando lauten: pgp -eat EXAMPLE.TXT remailer@adresse

Das Ergebnis wäre EXAMPLE.ASC, eine PGP-Nachricht, wie die oben gezeigte.

Zuletzt komplettieren Sie den Request, indem Sie die folgenden drei Zeilen vor der PGP-Nachricht einfügen:

::
Encrypted: PGP

-----BEGIN PGP MESSAGE-----
Version: 2.6.3in

owEdjk1OxDAMRrtEkXKH7wBtLoDEArGADSsukLTu1NCxR4kznV6K+7Ej7cbyz6f3
/Nt13Z89CbEEe1ibuncO3nn3qbCFC7j00Bmj1lyoh6i1PYFkzPvNaMKdcmEV71rq
uMSkd4LRwwJeq+EDWywYa2atjcUzouxJp927Tet6AnjeQ2jaYRi8e4uH1SDRKuWV
xwXSimGijK/G7c9OEwmK0WK9d0doixlp1QKheuEGvbTPE6jgm65RJlwp/9jp8e55
ePHuHw==
=j/F+
-----END PGP MESSAGE-----

Achten Sie auf die Leerzeile nach dem Kommando Encrypted: PGP. Senden Sie diesen Remail-Request an die Remailer-Adresse.


Mixmaster-Format

Mixmaster Remail-Requests müssen mit dem Mixmaster-Client erzeugt werden. Reliable-Remailer sind mit Mixmaster 2.0.3 und 2.0.4 kompatibel. Wenn Sie DOS oder Windows benutzen, wird der Umgang mit Mixmaster durch ein spezielles Remailer-Programm erleichtert.

Um eine Remailer- Anweisung in einen Mixmaster Remail-Request einzubauen, fügen Sie sie bei der Erzeugung der Nachricht als Mail-Header ein.

Beachten Sie ,

Zusätzlich können Hash-Header im Nachrichtenkörper von Mixmaster-Nachrichten platziert werden. Sie werden als Mail-Header hinzugefügt. Das Hauptziel dabei ist, die Beschränkung von Standard Mixmaster-Headern auf 80 Zeichen zu umgehen. Header, die im Hash-Abschnitt platziert werden, unterliegen dieser Beschränkung nicht. Als Beispiel der folgende Nachrichtenkörper:

##
Newsgroups: de.ein.sehr.langer.hierarchie.name.gruppe,de.noch.eine.
sehr.lange.gruppen.hierarchie.und.die.gruppe

Das ist der Text eines News-Artikels

Hier würde ein überlanger Newsgroups -Header verwendet. Die anderen Header der Nachricht, wie Subject, würden als Mail-Header vom Mixmaster-Client eingebaut.

Der Mixmaster-Client erzeugt eine oder mehr Ausgabedateien, die verschlüsselte Remail-Requests darstellen. Sie sollten an den ersten Remailer der Kette gesendet werden.


Remailer-Kommandos

Remailer- Kommandos zeigen an, wie eine Nachricht behandelt werden soll,wohin Sie weitergeleitet werden soll, usw. Sie werden dem Endempfänger nicht angezeigt.

In Cypherpunk Remail-Requests werden Remailer-Kommandos im" :: "-Abschnitt platziert. Ein Cypherpunk Remail-Request muss eine Anweisung enthalten, die die Zieladresse bestimmt (also Anon-To, Anon-Post-To, Remix-To, usw.)

In Mixmaster Remail-Requests, sind Kommandos optional. Sie werden als Mail-Header einer Nachricht eingebaut, wenn der Remail-Request vom Mixmaster-Client erzeugt wird [Das ist eine Eigenschaft von Hybrid -Remailern]

Beachten Sie: Ein bestehender Remailer muss nicht notwendigerweise alle der unten aufgeführten Kommandos unterstützen. Überprüfen Sie die Remailer- Optionen und fordern Sie spezifische Informationen zu einem Remailer mit Hilfe des remailer-conf Request an.

Remailer-Kommandos

Kommando Anon-To:
Beispiel Anon-To: adresse1@irgendwo.de
Die Nachricht soll anonym an adresse1@irgendwo.de weitergeleitet werden
Beispiel Anon-To: adresse1@irgendwo.de,adresse2@sonstwo.de Nachricht soll anonym an Adresse1 und an Adresse2 weitergeleitet werden
Maximal Wird vom Betreiber festgelegt
Äquivalent Request-Remailing-To
Konfiguration Standard (Von allen Reliable-Remailern unterstützt)
Bemerkungen Ist die einzige Zieladresse die eines unterstützten Remailers und sind transparentes repgp oder transparentes remix aktiviert, wird die Nachricht mit dem öffentlichen Schlüssel des (Ziel-)Remailers-oder Mixmaster-verschlüsselt an den (Ziel-)Remailer übertragen. Um diese Funktion zu deaktivieren, benutzen Sie Remail-To
Wird eine der Adressen hinter dem Anon-To Kommando blockiert oder die Mail dorthin vom Betreiber nicht erlaubt, wird sie aus der Anweisung entfernt. Sollten keine Adressen oder keine gültigen Anweisungen übrigbleiben, wird die Nachricht vernichted.
Kommando Anon-Post-To:
Beispiel Anon-Post-To: alt.test
Postet die Nachricht anonym in die Gruppe alt.test
Beispiel Anon-Post-To: alt.test,de.test
Postet die Nachricht anonym in mehrere Newsgroups
Maximum Wird vom Betreiber festgelegt
Konfiguration Post
Optional. Posting kann über NNTP oder einen Mail2News-Gateway erfolgen. Es kann auch deaktiviert sein. Wenn Anon-Post nicht unterstützt wird, wird die Anweisung ignoriert und jedes Anon-To oder andere Kommando erhält Vorrang.
Bemerkungen Ein Anon-Post-To Kommando kann bewirken, dass einer Nachricht eine News-Signatur hinzugefügt wird. Darin wird bekanntgegeben, dass sie über Remailer gesendet worden ist. Abhängig von der Konfiguration, wird diese Signatur vielleicht nur dann angehängt, wenn Sie einen benutzerdefinierten From-Header angeben
Wenn eine der Newsgruppen in der Anon-To Anweisung blockiert ist oder vom Betreiber nicht erlaubt wird, wird sie gelöscht. Bleiben keine Newsgruppen oder gültige Anweisungen mehr übrig, geht die Nachricht verloren
Soll ein Artikel über Mixmaster versendet werden, verwenden Sie einen Post: Header anstelle des Empfängers. Zum Beispiel: Post: alt.test
Kommando Remix-To:
Beispiel Remix-To: remailer1@irgendwo.com
Weist Reliable dazu an, die Nachricht mixmasterverschlüsselt an den genannten Remailer zu senden. Die angezeigte Adresse muss eine einfache Remailer-Adresse sein (Keine Namen oder Text) oder ein Remailer-Name ohne Adresse. Der Remailer muss in der Liste der unterstützten Mixmaster-Remailer aufgeführt sein (Reliable muss den Schlüssel für den Remailer besitzen).
Beispiel Remix-To: remailer1@irgendwo.com, remailer2@sonstwo.de, remailer3@nirgends.net
Weist Reliable dazu an, die Nachricht über eine Mixmaster- Kette an Remailer3 zu senden:
Remailer1 ---> Remailer2 ---> Remailer3
[das ist eine Erweiterung des Remix-To Kommandos]
Beispiel Remix-To: random, remailer1@irgendwo.com, random
Mixmaster wählt anstelle von "random" jeweils einen zufälligen Remailer aus.
[das ist eine Erweiterung des Remix-To Kommandos]
Maximum Wird vom Betreiber festgelegt
Konfiguration remix2, ext
Optional. Wenn transparentes Remix aktiviert ist, ist Remix-To aktiviert. Remix-To kann auch davon unabhängig angewendet werden. In Zeiten hoher Systemauslastung können Remix-To Nachrichten zur späteren Verarbeitung zurückgestellt werden, abhängig von der Konfiguration
Bemerkungen Kann die gewünschte Remix-Kette nicht verwendet werden, entweder, weil Remix-To nicht aktiviert ist oder weil Schlüssel einzelner oder mehrerer Remailer fehlen, wird die Remix-To Anweisung ignoriert. Andere Kommandos, wie Encrypt-To oder Anon-To, erhalten dann gegebenenfalls Priorität. Bleiben keine gültigen Kommandos übrig, ist die Nachricht verloren.
Zufällige Remailer werden von Mixmaster auf der Basis von Statistikdateien und Einstellungen des Betreibers ausgewählt.
Kommando Encrypt-To:
Beispiel Encrypt-To: remailer1@irgendwo.com
Reliable soll die Nachricht vor dem Versenden mit dem öffentlichen PGP- Schlüssel des angegebenen Remailers verschlüsseln (RePGP). Die genannte Adresse muss eine einfache Remailer-Adresse sein (ohne Namen oder Text) oder ein Remailer-Name ohne Adresse. Sie sollte in der Liste unterstützter RePGP-Remailer enthalten sein (Reliable muss den PGP-Schlüssel des Remailers haben).
Beispiel Encrypt-To: remailer1@irgendwo.com, remailer2@sonstwo.de, remailer3@nirgends.net
Reliable sendet die Nachricht PGP-verschlüsselt über eine verschlüsselte Cypherpunk-Kette (RePGP):
remailer1 ---> remailer2 ---> remailer3
Nur der letzte Remailer muss RePGP-fähig und in der Liste unterstützter RePGP-Remailer enthalten sein. Die anderen Remailer der Kette brauchen lediglich PGP zu unterstützen (Reliable braucht den Schlüssel jedes der verketteten Remailer).
[Das ist eine Erweiterung der RePGP-Funktion]
Beispiel Encrypt-To: random, remailer1@irgendwo.com, random
Reliable wählt für jedes "random" in der Kette jeweils einen zufälligen Remailer aus. Der letzte Remailer muss in der Liste unterstützter RePGP-Remailer enthalten sein.
[Das ist eine Erweiterung der RePGP-Funktion]
Maximum Wird vom Betreiber gesetzt
Konfiguration repgp2, ext
Optional. Wenn transparentes repgp aktiviert ist, wird Encrypt-To unterstützt. Encrypt-To kann auch davon unabhängig eingesetzt werden.
Bemerkungen Kann die gewünschte RePGP-Kette nicht angewendet werden, weil entweder Encrypt-To deaktiviert ist oder weil einer oder mehr der erforderlichen Remailer-Schlüssel nicht verfügbar ist, wird die Encrypt-To Anweisung ignoriert. Andere Kommandos, wie Anon-To oder Remail-To, erhalten dann gegebenenfalls Priorität. Bleiben keine gültigen Kommandos übrig, geht die Nachricht verloren.
Zufällige Remailer werden von Reliable auf der Basis von Statistiken und Einstellungen des Betreibers ausgewählt. Sie müssen die RePGP-Voraussetzungen erfüllen. Reliable verwendet eine Distanz-Einstellung von 3
Kommando Remail-To:
Beispiel Remail-To: adresse1@irgendwo.de
Die Nachricht soll anonym an Adresse1 weitergeleitet und dabei nicht mit dem öffentlichen Schlüssel verschlüsselt werden. Die Nachicht wird weder PGP-(RePGP), noch Mixmaster-verschlüsselt (Remix), auch nicht, wenn transparentes repep oder remix unterstützt werden.
Beispiel Remail-To: adresse1@irgendwo.de, adresse2@sonstwo.com
Die Nachricht soll anonym an zwei Adressen gesendet werden.
Maximum Wird vom Betreiber festgelegt (gleiche Anzahl wie für Anon-To:)
Konfiguration Standard (wird von allen Reliable-Remailern unterstützt).
Bemerkungen Remail-To arbeitet genau wie Anon-To, außer, dass transparentes remix und repgp deaktiviert werden
Anders als Encrypt-To und Remix-To, erzeugt Remail-To keine Ketten. Werden mehrere Adressen genannt, erhält jede eine Kopie der Mail
Kommando Test-To:
Beispiel Test-To: deine.adresse@hier.de
Wenn sie eine Test-To Anweisung enthält, wird die Nachricht normal verarbeitet. Allerdings wird sie nicht weitergeleitet. Statt dessen erhält die Test-To Adresse einen Test-Bericht, in dem Fehler oder Verarbeitungsprobleme angezeigt werden: Kommandos und Header, die entfernt oder verändert worden sind, solche, die nicht unterstützt werden, genauso Funktionen, die nicht zur Verfügung stehen, ob Remix oder RePGP wie gewünscht vorgenommen wurden, ob Newsgruppen oder Zieladressen blockiert sind und interne Fehlfunktionen, die die erfolgreiche Verarbeitung verhindern.
Beispiel Test-To: me
Genau wie oben, nur wird das Schlüsselwort "me" durch Ihre Email-Adresse ersetzt (entweder aus der From oder Reply-To Kopfzeile Ihrer Mail).
( Zur Beachtung: Das Schlüsselwort "me" funktioniert nur in Test-To Kommandos!)
Maximum Eine Adresse
Konfiguration Test
Standard (wir von allen Reliable-Remailern unterstützt)
Bemerkungen Wenn die Test-To Adresse eine geblockte Zieladresse ist, wird kein Test-Bericht gesendet
Test-To sollte die erste aller aufgeführten Anweisungen sein. Wird sie im Anschluss an andere Kommandos genannt, kann eines davon die Verarbeitung unterbrechen und die Versendung eines Test-To Berichtes verhindern.
Kommando Encrypt-Test:
Beispiel Encrypt-Test: konventionelle_passphrase
Weist Reliable an, einen Test-To -Bericht mit der genannten konventionellen PGP -Passphrase zu verschlüsseln
Maximum Bei Reliable-Remailern, die mit PGP 2.6.x arbeiten, variiert die maximale Länge mit der System-Konfiguration, darf aber 68 Zeichen nicht überschreiten. Remailer, die mit PGP 5.x betrieben werden, können bis 255 Zeichen verarbeiten.
Konfiguration test
Standard (wird von allen Reliable-Remailern unterstützt)
Bemerkungen Funktioniert nur, wenn eine Test-To Anweisung vorhanden ist
Kommando Null:
Beispiel Null: jedeadresse
Reliable vernichtet die Nachricht (zum Erzeugen von zusätzlichem Datenverkehr)
Konfiguration Standard (wird von allen Reliable-Remailern unterstützt)
Kommando Rand-Hop:
Beispiel Rand-Hop: 3
Fügt eine Kette von drei zufälligen Remailern vor dem Endempfänger ein
Beispiel Rand-Hop: 4r
Fügt eine Kette aus einem bis vier zufälligen Remailern vor dem Endempfänger ein. Die tatsächliche Länge der Kette wird zufällig bestimmt.
Maximum Wird vom Betreiber festgelegt. Wenn die gewünschte Anzahl von Remailern den Maximalwert überschreitet, wird sie reduziert
Äquivalent RHop
Konfiguration rhop
Optional. Wenn das Maximum auf Null gesetzt ist, ist die Funktion abgestellt und Rand-Hop Kommandos werden ignoriert.
Bemerkungen Die zufällige Kette ist vom gleichen Typ, wie für die restliche Nachricht vorgesehen: Ist RePGP aktiv (transparent oder explizit), wird die Kette PGP-verschlüsselt; wenn remix aktiv ist (transparent oder explizit), wird die Kette aus Mixmaster-Remailern bestehen. Sind weder RePGP noch Remix aktiv, wird die Kette nicht verschlüsselt.
Zufällige Cypherpunk-Remailer werden von Reliable auf der Basis von Statistiken und Einstellungen des Betreibers ausgewählt. Mixmaster-Remailer werden von Mixmaster auf der Basis seiner Statistik-Dateien und den Einstellungen des Betreibers ausgewählt.
Sollten nicht genügend zufällige Remailer zur Verfügung stehen, wird die Nachricht zurückgestellt, bis der Betreiber die Konfiguration korrigiert. Dann wird die Nachricht erneut verarbeitet und versendet
Kommando Latent-Time:
Beispiel Latent-Time: 14:35
Setzt den Zeitpunkt der Versendung einer Mail auf 14 Uhr 35 fest.
Beispiel: Latent-Time: +00:48
Versendet die Nachricht, nachdem 48 Stunden vergangen sind.
Beispiel Latent-Time: +1:30r
Versendet die Nachricht nachdem zwischen 0 und 90 Minuten (zufälliger Wert) seit ihrer Verarbeitung vergangen sind
Maximum 23:59 / +99:99
Äquivalent LatentTime, Latent
Konfiguration latent
Optional. Wenn deaktiviert, werden Latent-Time Anweisungen ignoriert.
Bemerkungen Wurde kein Latent-Time Kommando in die Nachricht eingebaut, wird die Nachricht um eine zufällige Zeitspanne verzögert.
Der tatsächliche Zeitpunkt, zu dem Reliable eine Mail versendet, wird von der Auslastung und anderen Faktoren beeinflusst. Obwohl keine Nachricht früher als 5 Minuten vor der gedachten Zeit abgeschickt wird, kann sie durch hohen Datenverkehr auf einen späteren Zeitpunkt verzögert werden. Jedenfalls werden Nachrichten in der vorgegebenen Reihenfolge verschickt.
Im Falle, dass die Zieladresse der Remailer selbst ist, wird die Nachricht intern weitergeleitet und Latent-Time Anweisungen werden ignoriert.
Kommando Cutmarks:
Beispiel: Cutmarks: ====
Jeder Text, der hinter einer Zeile steht, die nur " ==== " enthält, wird gelöscht.
Konfiguration cut
Standard (Wird von allen Reliable-Remailern unterstützt)
Bemerkung Anders als manche Remailer, behandelt Reliable Abschnitte, die sich an eine Cutmarks-Zeile anschließen nicht als weitere Remailer-Nachricht. Text, der dort erscheint, geht verloren.
Kommando Encrypt-Key:
Beispiel Encrypt-Key: konventionelle_Passphrase
Verschlüsselt jeden Text nach "**" mit der konventionellen Passphrase unter Verwendung von PGP. Wenn keine Zeile "**" gefunden wird, wird die komplette Nachricht verschlüsselt und zu Beginn wird "**" eingefügt.
Beispiel: Encrypt-Key: konventionelle Passphrase
Maximum Bei Reliable-Remailern, die mit PGP 2.6.x arbeiten, variiert die maximale Länge mit der System-Konfiguration, darf aber 68 Zeichen nicht überschreiten. Remailer, die mit PGP 5.x betrieben werden, können bis 255 Zeichen verarbeiten.
Äquivalent EncryptKey
Konfiguration ek
Optional. Wird ek nicht unterstützt, wird die Nachricht gelöscht
Kommando Inflate:
Beispiel Inflate: 5
Vergrößert eine Nachricht um 5 Kilobytes zufälliger Fülldaten.
Beispiel Inflate: 7r
Vergrößert die Nachricht um einen Wert zwischen 1 und 7 Kilobytes (Zufallswert) an zufälligem Datenmüll.
Maximum Wird vom Betreiber festgelegt. Übersteigt das gewünschte Maß dieses Maximum, wird es reduziert
Konfiguration inflt
Optional. Wird das Maximum auf Null gesetzt, ist die Funktion deaktiviert und Inflate-Kommandos werden ignoriert.
Bemerkungen Existiert eine Encrypt-Key Anweisung, wird der Datenmüll innerhalb des verschlüsselten Bereiches platziert.
Befindet sich der Datenmüll außerhalb des verschlüsselten Bereiches, kann er durch den folgenden Remailer entfernt werden, indem die Cutmarks -Anweisung verwendet wird: Cutmarks: -----Begin Garbage-----
Beachten Sie, dass beim Entschlüsseln von Mail mit Decrypt oder Jack B. Nymble der Datenmüll aus eingehender Mail automatisch entfernt werden kann.
Kommando Max-Size
Beispiel Max-Size: 15
Ist die Nachrichte größer als 15K, wird sie beseitigt.
Maximum Keines (Ein Wert, der höher liegt, als die vom Remailer unterstützte Nachrichtengröße, hat keinerlei Auswirkungen).
Äquivalent MaxSize
Konfiguration max
Standard (wird von allen Reliable-Remailern unterstützt)
Bemerkung Wenn der Remail-Request PGP-verschlüsselt ist, entspricht der Wert in Max-Size der Größe der entschlüsselten Nachricht (vor der Verarbeitung). Ist der Remail-Request nicht PGP-verschlüsselt, ist die komplette Nachricht inklusive der Header, wie sie vom Remailer empfangen wurde, betroffen.
Mehr Informationen stehen im Kapitel über besondere Funktionen
Siehe auch Max-Count und Max-Date.
Kommando Max-Count:
Beispiel Max-Count: 20
Wenn der Remail-Request öfter als (ungefähr) 20 Mal am gleichen Tag empfangen wurde, wird die Nachricht beseitigt.
Äquivalent MaxCount
Konfiguration max
Standard (Wird von allen Reliable-Remailern unterstützt)
Bemerkung Ein Remail-Request, der eine Max-Count Anweisung enthält, muss PGP-verschlüsselt sein. Wenn nicht, wird die Nachricht beseitigt.
Die Max-Count Anweisung wird annähernd exakt befolgt, die tatsächliche Anzahl der täglich weitergeleiteten Nachrichten kann etwas höher ausfallen (aber nicht geringer). Das geschieht mit Absicht, um Datenflussanalysen zu vereiteln. Eine Max-Count Anweisung mit Werten von 5 und weniger, wird dagegen genau ausgeführt.
Weitere Informationen stehen im Kapitel über besondere Funktionen
Siehe auch Max-Size und Max-Date
Kommando Max-Date:
Beispiele Max-Date: Thu, 21 Jan 1999 17:00:00 -0800
Max-Date: 21 Jan 1999 17:00:00 -0000
Max-Date: 21 Jan 1999 17:00
Soll der Remail-Request nach dem festgelegten Zeitpunkt verarbeitet werden, wird er beseitigt. Wird keine Zeitzone genannt, wird UTC (-0000) angenommen.
Beispiele Max-Date: 21 Jan 1999
Soll der Remail-Request später als am genannten Tag verarbeitet werden, wird er beseitigt. Wird keine Uhrzeit genannt, darf auch keine Zeitzone erscheinen.
Maximum Keines
Äquivalent MaxDate
Konfiguration max
Standard (Wird von allen Reliable-Remailern unterstützt)
Bemerkung Das Datums- und Zeitformat, das in Max-Date erlaubt ist, ist das gleiche wie in den Datumsheadern von Email. Enthält die Anweisung einen ungültigen Eintrag, wird die Nachricht beseitigt.
Weitere Informationen stehen im Kapitel über besondere Funktionen
Siehe auch Max-Size und Max-Count
Kommando Encrypted:
Beispiel Encrypted: PGP
Informiert Reliable, dass der Nachrichtentext einen PGP -verschlüsselten Remail-Request darstellt. Reliable entschlüsselt die Nachricht und verarbeitet den darin enthaltenen Remail-Request.
Konfiguration PGP
Standard bei allen Cpunk -Remailern. PGPonly -Remailer benötigen die Anweisung Encrypted: PGP
Bemerkung Der einzig mögliche Text, der auf das Kommando folgen darf, ist "PGP" (wie im Beispiel).

Weitere Hinweise:

Folgendes gilt für Reliable Remailer, muss aber nicht auf andere, aktive Remailer zutreffen.


Mail-Header

Mail-Header (endgültige Header) sind jene Header, die in der Nachricht zu sehen sind, wenn sie an den Endempfänger übermittelt wird, wie Subject - oder Newsgroups -Header. In Cypherpunk-Nachrichten, werden Mail-Header im Hash ("##")-Abschnitt eines Cypherpunk Remail-Requestes eingebaut. In Mixmaster-Nachrichten, können Mail-Header entweder im Mixmaster-Client oder in einem Hash-Abschnitt hinzugefügt werden, wie oben erklärt (siehe Mixmaster-Format)

Im Allgemeinen wird jeder Header erlaubt. In der Praxis sind einige Header in abgehenden Nachrichten nicht zulässig (und werden entfernt). Rufen Sie eine remailer-conf Nachricht von Remailern ab, um zu sehen, welche Header betroffen sind.

Die folgende Tabelle listet endgültige Header auf, die eine spezielle Funktion haben oder von Reliable-Remailern abweichend behandelt werden.

Header Subject:
Beispiel Subject: Betreff der Nachricht
Bemerkungen Betreff-Header sind optional, müssen aber in Nachrichten enthalten sein, die an Mail2News-Gateways gesendet werden. Fehlen sie in einer Anon-Post-To Nachricht, wird automatisch ein Subject-Header eingefügt.
Header Newsgroups:
Beispiel Newsgroups: alt.test, alt.alt.test
Maximum Wird vom Betreiber festgelegt (Gleiche Anzahl wie bei Anon-To)
Konfiguration Ein Newsgroups-Header kann bewirken, dass der Nachricht eine News-Signatur angehängt wird, die feststellt, dass sie über einen anonymen Remailer geleitet worden ist. Abhängig von der Konfiguration sind nur Postings mit benutzerdefinierter From-Zeile betroffen.
Bemerkungen Nachrichten an Mail2News-Gateways sollten einen Newsgroups-Header erhalten, es sei denn, der Gateway verarbeitet Gruppennamen als Teil der Email-Adresse.
Wird eine der Newsgroups im Newsgroups-Header vom Betreiber geblockt, wird sie aus dem Header-Eintrag entfernt. Bleiben keine Newsgruppen übrig, wird der Header gelöscht. Newsgroups-Header und Gruppen im Anon-Post-To Kommando, werden unabhängig voneinander blockiert. Um herauszufinden, ob eine Newsgroup blockiert wird, verwenden Sie die Test-To Anweisung.
Header Followup-To:
Beispiel Followup-To: alt.test
Zeigt an, wo Followups auf Ihren Newsgruppen-Artikel erscheinen sollen. Dieser Header wird nicht gefiltert.
Maximum Keines
Header From:
Beispiel From: ihremail@adresse.de (Ihr Kurzname)
oder
From: "Ihr Kurzname"
oder
From: Ihr Kurzname
Der Standard From- Header des Remailers "Anonymous" kann durch Ihren eigenen Eintrag ersetzt werden. Abhängig von der Konfiguration kann auch evtl. nur der Kurzname akzeptiert werden. Werden From-Header nicht akzeptiert, werden sie gelöscht.
Beispiel From: (Ihr Kurzname)
oder
From: "Ihr Kurzname"
oder
From: Ihr Kurzname
Der Standard-Name "Anonymous" kann durch Ihren Kurznamen ersetzt werden oder der gesamte Header wird, abhängig von der Konfiguration, gelöscht.
Konfiguration Benutzerdefinierte From-Header können vom Betreiber in folgenden Fällen akzeptiert werden:
  • In allen Nachrichten, Name und Adresse
  • In allen Nachrichten, nur der Name
  • Nur in Anon-Post-To Artikeln, Name und Adresse
  • Nur in Anon-Post-To Artikeln, nur der Name
  • Niemals
Der Betreiber kann sich auch dazu entscheiden, Nachrichten mit benutzerdefinierten From-Headern eine News-Signatur anzuhängen.
Bemerkungen From-Header werden in News-Postings im Allgemeinen dazu verwendet, "Anonymous" durch einen Kurznamen zu ersetzen. Beachten Sie, dass auch dann, wenn ein Remailer From-Header akzeptiert, ein Mail2News-Gateway sie wieder entfernen kann.
Wird einzig ein Kurzname verwendet, erhält die Nachricht anstelle des Standard From-Headers einen Header der Form:
From: Anonymous-Remailer@See.Comments.Header (Ihr Kurzname)
Header CC:, Bcc:
Beispiel: CC: adresse2@nirgends.de
Zusätzlich zu den Adressen im To- Header, wird die Nachricht auch automatisch anonym an die Adressen im CC (Carbon Copy)-Header weitergeleitet.
Beispiel Bcc: adresse3@irgendwo.com, adresse4@sonstwo.de
Zusätzlich zu den Adressen ini den To- und CC-Headern, wird die Nachricht auch automatisch anonym an die Adressen im Bcc (Blind Carbon Copy)-Header gesendet. Der Bcc-Header bleibt den Endempfängern einer Nachricht verborgen.
Maximum Wird vom Betreiber festgelegt (Jeweils gleiches Maximum wie bei Anon-To)
Header Reply-To:
Beispiel Reply-To: ihre@adresse.de
Wird in die endgültige Nachricht eingebaut. Wünscht eine Person, auf Ihre Nachricht zu antworten, wird der Email-Client die Antwort standardmäßig an die Reply-To Adresse anstelle der From-Adresse senden. Natürlich kann die Einstellung eines Reply-To Headers Ihre Anonymität beeinträchtigen.

Max-Size, Max-Count, Max-Date

Remailer, die die max-Option unterstützen, erkennen die Anweisungen Max-Size, Max-Count und Max-Date (dazu gehören alle Reliable-Remailer, die die Software-Version 1.0.f und später verwenden). Die Kommandos dienen dazu, Reply-Blöcke und CPunk-Nachrichten im Allgemeinen gegen Replay-Attacken unempfindlicher zu machen. Max-Anweisungen definieren Beschränkungen des Zeitpunktes und der Art und Weise, wie ein Remail-Request verarbeitet wird.

Max-Size

Max-Size soll in Reply-Blöcken eingesetzt werden und macht an anderer Stelle wenig Sinn. Ein Remailer wird damit aufgefordert, Nachrichten zu löschen, wenn Sie die festgelegte Größe überschreiten. Ein Beispiel einer solchen Anweisung:

::
Anon-To: adresse@irgendwo.net
Max-Size: 15

Wenn die Länge des entschlüsselten Reply-Blocks zusammen mit der Länge der anhängenden Nachricht 15K überschreitet (15 x 1024 bytes = 15360 Zeichen), wird die Nachricht vom Remailer beseitigt.

Max-Size soll die Größe der Nachrichten beschränken, die an Ihren Reply-Block gerichtet sind. Sollte Fixedsize für Ihren Nym nicht aktiviert sein, können Nachrichten von 1 MB oder mehr auflaufen. Solche Nachrichten können die Sicherheit des Reply-Blocks beeinträchtigen, weil sie in der Masse des Datenstromes eher auffallen. Durch Max-Size werden daher Nachrichten gelöscht, die größer sind, als der von Ihnen vorgegebene Wert.

Auch, wenn jemand an Ihren Reply-Block herangekommen ist, und versucht, ihn durch das Versenden großer Nachrichten zurückzuverfolgen, werden diese Nachrichten durch die Max-Size Funktion beseitigt.

Wenn Sie +Fixedsize für Ihren Nym aktiviert haben, werden Nachrichten in Stücke gleicher Größe aufgeteilt. Wenn diese Stücke im Allgemeinen 10K nicht überschreiten, setzen Sie Max-Size auf 15K. Jedesmal, wenn eine Nachricht unterwegs durch Remailer verschlüsselt wird, wächst sie ein wenig. Bei Reply-Blöcken mit langen Ketten, sollten Sie Max-Size daher um ein paar KB erhöhen. Die Verwendung der Inflate -Anweisung bei den ersten Remailern einer Kette verursacht ebenfalls Größenzuwachs der übermittelten Nachricht. Sie können mit dem Test-To Kommando verschiedene Kombinationen ausprobieren.

Beachten Sie , dass die Max-Size Anweisung keine Wirkung zeigt, wenn sie größere Nachrichten zulässt, als der Remailer selbst.

Max-Count

Die Anweisung Max-Count soll in Reply-Blöcken angewendet werden. Sie legt fest, wie viele Nachrichten täglich über einen bestimmten Reply-Block gesendet werden dürfen. Ein Beispiel:

::
Anon-To: adresse@irgendwo.net
Max-Count: 20

(Hier fehlt die PGP-Verschlüsselung, die in der Praxis erforderlich ist)
Dieses Max-Count Kommando würde die Anzahl der Nachrichten, die an einem Tag über den Reply-Block übermittelt werden, auf 20 begrenzen. Jede weitere Nachricht wird vom Remailer beseitigt.

Wichtig: Ihr Reply-Block muss PGP-verschlüsselt sein, damit er mit Max-Count richtig arbeitet. Wird er nicht verschlüsselt, wird jede Nachricht vernichtet.

Max-Count schwächt die Wirkung von Replay-Angriffen gegen Ihren Reply-Block oder Nym-Account ab. Außerdem hilft es gegen übergroße Nachrichten, die an Nym-Accounts mit eingeschalteter +Fixedsize -Funktion adressiert sind. Solche Nachrichten werden in viele Stücke aufgeteilt.

Die Verwendung von Max-Count kann zum Verlust von Mail führen, wenn zu niedrige Werte eingesetzt werden. Ihr Account kann auch effektiv einen Tag lang lahmgelegt werden, wenn jemand sehr viele oder (bei +fixedsize) sehr große Nachrichten dorthin adressiert. Man nennt dies einen " Denial Of Service "-Angriff. Allerdings ziehen viele Menschen diese Möglichkeit der einer Replay-Attacke vor.

Beachten Sie , dass Nym-Accounts ohnehin nach einer gewissen Anzahl von Nachrichten (oder Datenmenge) deaktiviert werden. Der Inhaber wird darüber informiert, und muss ihn durch Vesendung einer Nachricht wieder in Betrieb nehmen. Sollte ein Max-Count Reply-Block vorher bereits den Mailversand stoppen, werden Sie keine Benachrichtigung empfangen (Sie erkennen das Problem, wenn Sie am nächsten Tag versuchen Mail über den Account zu senden und dadurch, dass andere Leute, die Ihnen Mail zuschicken, statt dessen über die Außerbetriebnahme der Adresse informiert werden).

Reliable-Remailer setzen das Max-Count Kommando um, indem ein Reply-Block " gehasht " und inform einer 32-stelligen Hexadezimalzahl gespeichert wird. Ihr Reply-Block wird vom Remailer nicht aufgehoben.

Zur Beachtung : Der in der Anweisung festgelegte Wert, wird annäherungsweise beachtet, das tatsächliche Maximum kann aber etwas höher ausfallen (nicht niedriger). Dahinter steht die Absicht, Datenflussanalysen zu vereiteln. Ein Max-Count Wert von 5 oder weniger, wird dagegen exakt beachtet.

Max-Date

Die Anweisung Max-Date kann sowohl in Reply-Blöcken als auch in Cypherpunk-Nachrichten verwendet werden. Sie setzt das Verfallsdatum einer Nachricht fest. Später würde sie durch den Remailer beseitigt. Das Datum wird im gleichen Format notiert, wie in den Datumsheadern von Email. Zum Beispiel:

::
Anon-To: beispiel1@woauchimmer.net
Max-Date: Thu, 21 Feb 1999 17:00:00 -0800

In diesem Beispiel wird ein exakter Zeitpunkt bestimmt,
zu dem die Nachricht obsolet wird (der Wochentag kann
entfallen).

::
Anon-To: beispiel2@weitweg.net
Max-Date: 21 Feb 1999

In diesem Beispiel wird der letzte Tag genannt, an dem
die Nachricht weitergeleitet werden darf. Nach dem 21.
Februar würde sie statt dessen vernichtet. Sollte
keine Uhrzeit genannt sein, darf auch keine Zeitzone
erscheinen ("-0800"). Wird keine Zeitzone
gefunden, geht der Remailer von UTC aus ("-0000").

Cypherpunk-Nachrichten sind besonders anfällig gegen Replay-Angriffe. Nehmen wir an, sie schicken Nachrichten in eine Newsgroup. Geht jemand mit Zugang zu Ihren abgehenden Emails davon aus, dass Sie der Sender sind, kann er die gleiche Cypherpunk-Nachricht mehrfach versenden. Sie sollte danach mehrfach in der Newsgroup erscheinen.

Einige Remailer unterhalten Replay-Caches, die solche Vorgänge zu vermeiden helfen. Anders als bei Mixmaster-Nachrichten, können Cypherpunk-Nachrichten, die nicht mehr im Cache zu finden sind, erneut versendet werden. Der Angriff wird wohl verzögert, nicht aber völlig vermieden.

Max-Date löst dieses Problem durch Festlegen eines exakten Verfallsdatums für den Remail-Request. Danach kann er nicht mehr benutzt werden. Max-Date kann auch mit Max-Count:1 kombiniert werden, um sicherzustellen, dass ein bestimmter (PGP-verschlüsselter) Remail-Request nur ein einziges Mal gesendet wird. Max-Date kann auch in Reply-Blöcken benutzt werden. Dadurch wird der Reply-Block am festgelegten Tage ungültig. Wenn Sie alle zwei Wochen Ihre Reply-Blöcke ändern, beugen Sie mit Max-Date einem Replay-Angriff vor. Jemand, der nach dem Austausch versucht, den alten Block dafür einzusetzen, scheitert.

Reply-Blöcke profitieren kaum von Replay-Caches, da Zufallselemente, wie Encrypt-Key, die Nachricht bei jeder Benutzung des Reply-Blockes verändern. Max-Size, Max-Count und Max-Date dagegen bieten die Möglichkeit den Zugriff auf Reply-Blöcke zu beschränken.

Die besten Ergebnisse erziehlen Sie mit einer Max-Anweisung zu Beginn Ihrer Remailer-Kette, so dass ungültige Nachrichten vernichtet werden, bevor spätere Eingenheiten Ihres Reply-Blockes kompromittiert werden.

Sie können zwar Max-Kommandos mit Hybrid -Mixmaster-Remailern einsetzen, die meisten Mixmaster sind aber ohnehin dafür ausgelegt, keine Nachricht öfter als einmal zu verschicken (Das stimmt nur, wenn der Remailer die Paket-Ids protokolliert. Die meisten Remailer tun dies).
Bitte besorgen Sie sich weitere Informationen über Max-Kommandos aus dem Kapitel über Remailer-Kommandos.


RePGP

RePGP ist eine Methode, mit der Cypherpunk -Remailer Nachrichten an andere Cypherpunk-Remailer senden können. RePGP bezieht sich nur auf Ketten von Cypherpunk-Remailern. Um die Sicherheit zu erhöhen, verschlüsselt der absendende Remailer die gesamte Nachricht mit dem öffentlichen Schlüssel des empfangenden Remailers. Die Nachricht wird als PGP-verschlüsselter Cypherpunk Remail-Request formattiert der vom empfangenden Remailer entschlüsselt und normal verarbeitet wird.

Weil die Originalnachrichten bereits verschlüsselt sein können,führt RePGP evtl. dazu, dass sie mehrfach verschlüsselt werden. Der Remailer, der eine so behandelte Nachricht empfängt, muss diesen Umstand berücksichtigen. Nicht alle Remailer sind dazu in der Lage, daher ist RePGP auf eine Auswahl von Remailern beschränkt. Um herauszufinden, welche RePGP-fähigen Remailer von einem bestimmten Reliable-Remailer unterstützt werden, fragen Sie mit remailer-conf seine Konfigurationsdaten ab.

Reliable-Remailer erzeugen auch "RePGP-Ketten". Dabei muss nur der letzte Remailer der Kette RePGP-fähig sein. Allerdings müssen alle beteiligten Remailer in der Liste der unterstützten Remailer enthalten sein, um sicherzustellen, dass Reliable auf alle notwendigen Schlüssel zugreifen kann.

RePGP wird auf zwei Weisen durchgeführt. Die erste wird Transparentes RePGP genannt und durch repgp in den Remailer- Optionen angezeigt. Transparentes RePGP ist, wie der Name andeuten soll, für den Nutzer des Remailers transparent. Jedesmal, wenn die Zieladresse in einer Anon-To Anweisung die eines RePGP-fähigen Remailers ist, leitet Reliable die Nachricht automatisch im RePGP-Format weiter. Allerdings unterstützen nicht alle Reliable-Remailer automatisch auch Transparentes RePGP.

Der einzige Weg, um sicherzustellen, dass Transparentes RePGP zwischen Remailern stattfindet ist die Verwendung eines Test-To Kommandos.

Die zweite Form von RePGP wird Explizites RePGP genannt und durch repgp2 in den Remailer- Optionen angezeigt. Explizites RePGP bedeutet, dass der Nutzer anstelle der Anon-To Anweisung Encrypt-To verwendet. Dieses Kommando enthält die Adresse oder den Namen eines unterstützten RePGP-fähigen Remailers. Wenn ein Remailer, der repgp2 unterstützt auch die Adresse des Ziel-Remailers in Encrypt-To Anweisungen akzeptiert, wird die Nachricht über RePGP verschlüsselt. Sollte aus irgendeinem Grund RePGP nicht ausgeführt werden können (zum Beispiel aufgrund fehlender Schlüssel), geht die Nachricht verloren. Somit stellt Encrypt-To sicher, dass Nachrichten auch dann mit RePGP verschlüsselt werden, wenn Transparentes RePGP deaktiviert wurde. Vergewissern Sie sich dennoch, dass ein Remailer repgp2 unterstützt (Reliable-Remailer, die Transparentes RePGP unterstützen, unterstützen auch Explizites RePGP).

Weiterhin kann das Encrypt-To Kommando dazu angewendet werden, Transparentes Remix abzuschalten. Auch wenn Transparentes Remix aktiviert ist, würde die Nachricht nur mit RePGP verschlüsselt weitergeleitet.

Um beides, Transparentes Remix und RePGP abzuschalten und Nachrichten ohne weitere Verschlüsselung versenden zu lassen, verwenden Sie das Remail-To Kommando.

Reliable Remailer können Encrypt-To in erweiterter Form nutzen, um eine Kette von Remailern festzulegen. Ihre Nachricht wird an jeden Remailer in der Kette PGP-verschlüsselt. Der letzte Remailer muss RePGP-fähig sein. Zum Beispiel:

Encrypt-To: squirrel, random, base

Dadurch wird der Remailer die betroffene Nachricht über die PGP-verschlüsselte Remailer-Kette an Base weiterleiten:
Squirrel ==> Random ==> Base
Wobei "Random" ein zufällig ausgewählter Remailer ist (Reliable expandiert vor dem Abschicken die Remailer- Namen zur vollen Adresse; Sie können aber auch die Adresse des Remailers angeben).

Reliable-Remailer akzeptieren Kombinationen der Anweisungen Anon-To, Encrypt-To und Remix-To. Sind zum Beispiel sowohl ein Encrypt-To, als auch ein Anon-To Kommando vorhanden und RePGP kann nicht durchgeführt werden, wird Encrypt-To ignoriert und Anon-To erhält Priorität. Andererseits wird Anon-To nicht beachtet, wenn RePGP ausgeführt wird. Bitte besorgen Sie sich weitere Informationen aus dem Abschnitt Gewichtung von Kommandos.

Warum wird RePGP verwendet?

RePGP erhöht die Sicherheit von Nachrichten, während sie zwischen einzelnen Remailern unterwegs sind. Besonders nützlich ist die Funktion in verschlüsselten Reply-Blöcken. Ohne RePGP oder Remix, sind Reply-Blöcke anfällig, da sie für alle Nachrichten gleich sind.

Bei abgehenden Nachrichten ist RePGP unnötig, da Ihr Remailer-Client komplette Nachrichten mit den Schlüsseln jedes beteiligten Remailers PGP-verschlüsseln kann.

Wie unterscheiden sich Reliable-Remailer?

Reliable-Remailer besitzen die ext -Eigenschaft. Das bedeutet, dass sie die folgenden erweiterten Funktionen besitzen:


Remix

Remix ist, wie RePGP eine Methode, mittels derer Cypherpunk -Remailer Nachrichten an andere Cypherpunk-Remailer übermitteln. Remix ist nur auf Cypherpunk- Ketten anwendbar. Die Nachricht wird zur größeren Sicherheit als Mixmaster -Nachricht formatiert. Der empfangende Cypherpunk-Remailer muss die beiden Optionen cpunk und mix unterstützen, um als Empfänger in Frage zu kommen. Er soll den Mixmaster Remail-Request entschlüsseln und den darin enthaltenen Cypherpunk Remail-Request verarbeiten.

Remix kann auf zwei Weisen durchgeführt werden. Transparentes Remix wird durch die Option remix angezeigt. Transparentes Remix ist, wie der Name andeuten soll, für den Benutzer transparent. Jedesmal, wenn die Zieladresse der Anon-To Anweisung die eines unterstützten Mixmaster-Remailers ist, sendet Reliable die Nachricht im Mixmaster-Format. Allerdings unterstützen nicht alle Reliable-Remailer Transparentes Remix.

Der einzige Weg um festzustellen, ob Remix zwischen Remailern stattfindet, ist die Verwendung eines Test-To Kommandos.

Die zweite Art von Remix wird als Explizites Remix bezeichnet und durch remix2 in den Remailer- Optionen bezeichnet. Explizites Remix beinhaltet, dass der Benutzer ein Kommando Remix-To anstelle von Anon-To einsetzt. Das Komando enthält die Adresse oder den Namen eines unterstützten Mixmaster-Remailers. Wenn ein remix2-Remailer den Ziel-Remailer im Remix-To Komando unterstützt, wird die Nachricht im Mixmaster-Format gesendet. Sollte aus irgendeinem Grunde Remix nicht angewendet werden können (aufgrund fehlender Schlüssel, zum Beispiel), geht die Nachricht verloren. Auf diese Weise stellt Remix-To sicher, dass Nachrichten zwischen Remailern Mixmaster-verschlüsselt übertragen werden, auch,wenn transparentes Remix deaktiviert ist (ist ein Reliable-Remailer auf Transparentes Remix eingestellt, funktioniert auch explizites Remix).

Wenn sie eine Remix-To Anweisung verwenden möchten, achten Sie darauf,dass der genannte Remailer sowohl cpunk als auch mix unterstützt, oder die Mail geht verloren.

Um Transparentes Remix und Transparentes RePGP abzustellen, verwenden Sie eine Remail-To Anweisung. Dadurch werden Nachrichten ohne weitere Verschlüsselung versendet.

Außerdem unterstützen Reliable-Remailer die erweiterte Form von Remix-To zum Festlegen von Remailer- Ketten. Ihre Nachricht wird für jeden Remailer in der Kette Mixmaster-verschlüsselt. Der letzte genannte Remailer muss die beiden Optionen cpunk und mix unterstützen. Zum Beispiel:

Remix-To: marvin, random, replay

Hier würde die Nachricht durch eine Mixmasterkette geleitet:
Marvin ==> Random ==> Replay
wobei "Random" ein zufällig ausgewählter Remailer wäre (Reliable expandiert die Remailer-Namen vor dem Absenden zu den vollen Email-Adressen, Sie können aber auch gleich die Adressen der Remailer nennen).

Reliable-Remailer akzeptieren daneben auch Kombinationen aus Anon-To, Encrypt-To und Remix-To Kommandos. Werden zum Beispiel sowohl Encrypt-To als auch Remix-To Anweisungen verwendet, und kann Remix nicht ausgeführt werden, wird die Remix-to Anweisung ignoriert und Encrypt-To erhält Priorität. Andererseits wird Encrpyt-To ignoriert, wenn Remix-To funktioniert. Bitte sehen Sie sich dazu auch den Abschnitt Gewichtung von Kommandos an.

Warum wird Remix verwendet?

Remix verbessert die Sicherheit von Nachrichten, während sie zwischen Remailern unterwegs sind. Besonders nützlich ist die Funktion in verschlüsselten Reply-Blöcken. Ohne RePGP oder Remix sind Reply-Blöcke anfälliger, weil sie für alle Nachrichten gleich sind.

Bei abgehenden Nachrichten ist Remix nicht erforderlich, weil der Mixmaster-Client komplett verschlüsselte Mixmaster-Ketten erzeugt.

Wie unterscheiden sich Reliable-Remailer?

Reliable-Remailer besitzen die ext -Eigenschaft. Das bedeutet, dass sie die folgenden erweiterten Funktionen besitzen:


Gewichtung von Kommandos

Reliable-Remailer besitzen die ext -Eigenschaft. Das bedeutet, dass sie mehrere Kommandos für die Festlegung von Zieladressen in ein und derselben Nachricht akzeptieren. Sehen Sie sich zum Beispiel die folgende Cypherpunk -Nachricht an:

::
Remix-To: hyper
Encrypt-To: hyper
Anon-To: hyper

::
Anon-to: endempfaenger@adresse.com

Dies ist der Text einer anonymen Nachricht an
endempfaenger@adresse.com.
Er wird durch eine Remailerkette geleitet, deren
letztes Glied Hyper darstellt.

Wenn ein Reliable-Remailer die obige Nachricht empfängt, beachtet er zunächst die Remix-To Anweisung (weil sie Priorität hat). Ist remix2 aktiv, und vorausgesetzt, Hyper ist ein unterstützter Mixmaster-Remailer, wird die Nachricht anonym und mixmaster-verschlüsselt an Hyper gesendet (Remix).

Sollte aus irgendeinem Grund das Remix-To Kommando nicht ausgeführt werden können, so wird es ignoriert und die Encrypt-To Anweisung erhält Priorität. Die Nachricht wird PGP-verschlüsselt (RePGP) an Hyper gesendet.

Sollten weder Remix-To noch Encrypt-To durchgeführt werden können, erhält die Anon-To Anweisung Vorrang. Die Nachricht würde ohne weitere Verschlüsselung an Hyper gesendet.

Kombinationen wie die oben gezeigte erlauben es, explizites Remix anzuwenden, wenn Transparentes Remix für einen Remailer abgestellt worden ist. Zusätzlich geht die Nachricht nicht verloren, wenn explizites Remix nicht zur Verfügung steht. Statt dessen wird sie dann auf weniger sichere Weise weitergeleitet.

Manchmal ist es wünschenswert, dass Nachrichten vernichtet werden. Zum Beispiel dann, wenn Sie aus Sicherheitserwägungen nicht zulassen wollen,dass eine Mail ohne Remix gesendet wird, setzen Sie das Remix-To Kommando ein. Ansonsten kann es besser sein, dem Verlusst einer Mail vorzubeugen, wenn Remix nicht möglich ist.

Kommandos können grundsätzlich in jeder Reihenfolge genannt werden (wenn auch die Test-To Anweisung am besten vor allen anderen genannt wird). Ihre Hierarchie sieht folgendermaßen aus:

Test-To
Null
Anon-Post-To
Remix-To
Encrypt-To
Remail-To
Anon-To

Wenn Anon-To, Remail-To oder Anon-Post-To Anweisungen ungültige oder blockierte Zieladressen enthalten, werden diese aus der Anweisung gelöscht. Bleiben keine Adressen übrig, wird das Kommando entfernt und ein anderes Kommando erhält gegebenenfalls Vorrang. Bleiben keine gültigen Sendeanweisungen übrig, geht die Nachricht verloren.


Beispiele

Die folgenden Beispiele können an Reliable-Remailer versendet werden. Beachten Sie, dass, abhängig von der Konfiguration, einige Anweisungen versagen könnten.

::
Encrypt-To: base
Inflate: 7r

::
Anon-To: endempfaenger@adresse.com
Cutmarks: -----BEGIN GARBAGE-----

Diese Nachricht weist Reliable an, mit RePGP
an remailer@base.xs4all.nl zu verschlüsseln.
Eine zufällige Menge Datenmüll, aber nicht
mehr als 7K würden angehängt (innerhalb
des PGP-verschlüsselten Nachrichtenkörpers).
Base entfernt den Datenmüll und schickt die
Nachricht an endempfaenger@adresse.com
::
Encrypt-To: base
Rand-Hop: 4r

::
Anon-To: end@adresse.de

Diese Nachricht würde per RePGP an
remailer@base.xs4all.nl gesendet. Dazu
würde eine Remailerkette von 1 bis 4
zufälligen Remailern "zwischengeschaltet".
Die Kette würde PGP-verschlüsselt.
Base würde die Nachricht an end@adresse.de
weiterleiten
::
Encrypt-To: replay,bong,base
Rand-Hop: 3

::
Anon-To: end@adrese.de

Diese Nachricht würde über eine PGP-verschlüsselte
Kette von drei zufälligen Remailern gesendet, an
die sich dann Replay, Bong und Base anschlössen.
Nur Base muss RePGP-Mail akzeptieren.
::
Remix-To: squirrel,random
Rand-Hop: 3

::
Anon-To: end@adresse.com

Diese Nachricht würde Mixmaster-verschlüsselt über
die folgende Kette geleitet:

random --> random --> random --> mix@squirrel.owl.de --> random.

Der letzte Remailer müsste die Nachricht an end@adresse.de
senden.
::
Anon-To: empfaenger@adresse.net
Rand-Hop: 1
Encrypt-Key: test

##
Subject: Letztendlicher Betreff-Header

Reliable schickt die Nachricht an einen zufällig
ausgewählten Remailer, der sie dann an
empfaenger@adresse.net weiterleitet. Reliable verschlüsselt
die Nachricht mit der Passphrase "test". Der einzige
zufällige Remailer, der ausgewählt werden muss,
ist ein Mixmaster, wenn transparentes Remix eingeschaltet ist.
Wenn transparentes RePGP eingeschaltet ist, wird
PGP-verschlüsselt, sind beide deaktiviert, wird nicht
verschlüsselt.
::
Test-To: meine@adresse.com
Encrypt-Test: passphrase
Anon-To: end@adresse.com, adresse2@empfaenger.de, end3@adresse.net
Inflate: 3r
Cutmarks: ===
Jjdfle: Bedeutungsloses Kommando
Encrypt-Key: test
Latent-Time: 5:00r

##
Subject: Betreffzeile
From: Mein Kurzname

Reliable würde die Nachricht komplett verarbeiten, dabei alle
To-Header analysieren und die ek-Verschlüsselung vornehmen.
Die Nachricht würde zum Versenden in die Warteschlange
aufgenommen und schließlich gelöscht. Statt dass sie
gesendet würde, wird ein Test-Bericht an meine@adresse.com
gesendet, der die aufgetretenen Probleme erläutert, dabei
Fehlermeldungen und blockierte Adressen aufführt und feststellt,
ob der benutzerdefinierte From-Header akzeptiert worden ist.
Der Test-Bericht wäre mit der Passphrase "passphrase"
verschlüsselt. Er enthielte außerdem den oberen Teil der
Original-Testnachricht und die ersten 20 Zeilen der erzeugten
Ausgabedatei.

Als Beispiel für einen Test-Bericht liegt diesem Handbuch eine mögliche Antwort auf eine ähnlich abgefasste Mail bei. (testbsp.htm).

::
Remix-To: hyper
Encrypt-To: hyper
Anon-To: hyper

::
Anon-To: end@adresse.de

Wäre für den empfangenen Reliable-Remailer remix2 oder remix
aktiviert, würde diese Nachricht Mixmaster-verschlüsselt an
mix@sind.hyperreal.art.pl gesendet, der sie wiederum an
end@adresse.de weiterleiten sollte. Wenn remix ausgeschaltet ist,
wird das Remix-To Kommando gelöscht und die Encrypt-To Anweisung
erhielte Priorität.
Dadurch würde die Mail per RePGP an Hyper gesendet. Wären sowohl
remix, als auch repgp deaktiviert, würden beide Kommandos gelöscht
und Anon-To erhielte Vorrang. Die Nachricht würde unverschlüsselt
an Hyper übermittelt (Wenn in diesem Falle Encrypt-To und Anon-To
weggelassen werden, wird die Nachricht gelöscht).

Remailer-Optionen

Abhängig von der Konfiguration, können Reliable-Remailer jede der folgenden Funktionen unterstützen. Ein Sternchen (*) in der folgenden beispielhaften Liste von Indikatoren (engl.: Remailer Capability String) bedeutet, dass eine Funktion vom Betreiber des Remailers ein- oder ausgeschaltet werden kann.

$remailer{"Beispiel"} = <beispiel@adresse.com> cpunk * mix * hybrid * middle * pgp * PGPonly * latent * ek * cut hash ksub post * repgp * remix * remix2 * ext max reord * test rhop# * inflt# * klen# ";

Remailer Capability Indicators

Indikator Funktion
cpunk* Akzeptiert Remail-Requests im Cypherpunk -Format. Unterstützt die Kommandos Request-Remailing-To: und Anon-To:
mix* Akzeptiert Remail-Requests im Mixmaster -Format
hybrid* Akzeptiert Cypherpunk Remailer-Kommandos in den Headern von Mixmaster-Nachrichten. Alle Reliable- Mix -Remailer sind hybrid.
middle* Ein Middleman -Remailer. Er erzeugt seine eigene Kette weiterer Remailer, über die er selbst Nachrichten weiterleitet [die Middleman-Funktion von Reliable ist "intelligent" in sofern, dass andere Remailer direkt angeschrieben werden. Für die Post an andere Adressen, werden zufällige Remailer ausgewählt, basierend auf deren statistischer Zuverlässigkeit]
pgp* Akzeptiert PGP-verschlüsselte Remail-Requests
PGPonly* Cypherpunk Remail-Requests MÜSSEN PGP-verschlüsselt sein. Unverschlüsselte (Klartext-) Nachrichten werden nicht akzeptiert.
latent* Unterstützt Matt Ghios Latent-Time -Kommando
ek* Verschlüsselt Nachrichten konventionell, wenn eine Encrypt-Key Anweisung gefunden wird.
cut Unterstützt Matt Ghios Cutmarks -Kommando
hash Erkennt " Hash -Marks" ( ##), so dass jeder Mail-Header in anonymen Nachrichten eingebaut werden kann.
ksub Der Remailer löscht stets den Original -Betreff, auch, wenn nicht PGP-verschlüsselt wird.
post* Erlaubt das Posten in Newsgruppen, indem ein Post-To: oder Anon-Post-To: Kommando verwendet wird [Reliable-Remailer behandeln die Post-To Anweisung genau wie die Anon-Post-To Anweisung. Andere Remailer können Post-To als Aufforderung zum nicht-anonymen Posten verstehen].
repgp* Unterstützt Transparentes RePGP. Nachrichten, die an andere Remailer gesendet werden, sind mit seinem öffentlichen Schlüssel PGP-verschlüsselt.
repgp2* Explizites RePGP (die Encrypt-To Anweisung) wird unterstützt [Die erweiterte Funktion von Encrypt-To in Reliable-Remailern lässt lässt es zu, eine Kette von Remailern anzugeben. Das Kommando kann auch gleichzeitig mit anderen zur Anwendung kommen, die jeweils Zieladressen enthalten und im Falle eines Versagens den Vorrang bekommen].
remix* Transparentes Remix wird unterstützt. Nachrichten an andere Remailer werden im Mixmaster -Format versendet. In Zeiten hoher Auslastung kann Transparentes Remix ohne entsprechenden Hinweis abgestellt werden.
remix2* Explizites Remix (die Remix-To Anweisung wird unterstützt [Die erweiterte Funktion von Remix-To in Reliable-Remailern lässt es zu, eine Kette von Remailern anzugeben. Das Kommando kann auch gleichzeitig mit anderen zur Anwendung kommen, die jeweils Zieladressen enthalten und im Falle eines Versagens den Vorrang bekommen].
ext Unterstützt erweiterte Kommandos. Alle Reliable-Remailer besitzen diese Eigenschaft:
  • Der Remailer akzeptiert in Anweisungen Kurznamen an Stelle kompletter Adressen.
  • Remix-To und Encrypt-To Anweisungen dürfen das Schlüsselwort "Random" enthalten.
  • Mit Remix-To und Encrypt-To dürfen Remailerketten definiert werden
  • Mehrere Kommandos mit Zieladressen dürfen verwendet werden.
max Akzeptiert die Kommandos Max-Size, Max-Count und Max-Date zur besseren Kontrolle über CPunk-Nachrichten und Reply-Blöcke [Mehr Infos]
reord* Umsortieren der Nachrichten im Pool soll Angriffe durch Datenflussanalyse vereiteln.
test Das Test-To Kommando wird unterstützt. Die Nachrichten werden komplett verarbeitet, dann aber nicht gesendet. Statt dessen wird ein Test-Bericht erzeugt und an die Test-To-Adresse versendet.
rhop#* Die Anweisung Rand-Hop wird unterstützt. Sie bewirkt, dass eine Nachricht durch eine Kette zufällig ausgewählter Remailer geleitet wird. Die Ziffer (#) bestimmt die maximal unterstützte Anzahl von Remailern im Kommando;
z. B. rhop5
inflt#* Die Inflate Anweisung kann dazu dienen, einer Nachricht zufälligen Datenmüll anzuhängen. Die Ziffer (#) bestimmt die maximale Anzahl von Kilobytes, die angehängt werden können;
z. B. inflt20
klen#* Zeigt die maximale Größe von Nachrichten an (in KB), die durch den Remailer weitergeleitet werden. klen1000 bedeutet, dass Nachrichten bis zur Größe von 1MB (1000KB) akzeptiert werden.

Weitere Optionen:

, die in Listen auftauchen, aber nicht mit Reliable-Remailern in Verbindung gebracht werden sollten, sind:

Indikator Funktion
newnym Ein Pseudonymserver
esub Akzeptiert das Encrypt-Subject Kommando, mit dem Betreffzeilen von News-Artikeln verschlüsselt werden.
nsub Der Remailer behält den Betreff-Header bei, auch, wenn PGP-verschlüsselt wird.
mon Der Remailer nimmt bekanntermaßen Einsicht in private Email.
filter Der Remailer ist dafür bekannt, dass er Nachrichten aufgrund ihres Inhaltes ausfiltert. Wird nicht gleichzeitig auch mon genannt, sind nur Nachrichten an öffentliche Foren betroffen.

Eigenheiten der Reliable-Remailer

Von einigen Ausnahmen abgesehen, gelten die Informationen in dieser Anleitung für alle Remailer. Zum Zeitpunkt, da dieser Text entstand, unterscheiden sich Reliable-Remailer von allen anderen in den folgenden Punkten:

Wenn Sie wissen möchten, welche Software ein Remailer verwendet, senden Sie ihm eine Nachricht mit Subject: remailer-conf oder Subject: freedom-conf.


Glossar

anonym
engl.: anonymous
Eine anonyme Nachricht wurde von einem Remailer weitergeleitet. Alle Originalheader sind entfernt worden, so dass der ursprüngliche Sender für den Empfänger unbekannt bleibt.
Betreiber
engl.: operator
Der Betreiber eines Remailers (oder Administrator) ist die Person, die einen Remailer einrichtet und pflegt, dadurch also den anonymen Weiterleitungsdienst für dessen Nutzer bereitstellt.
bit bucket Der Papierkorb eines Remailers. Der Begriff taucht auf, wenn Nachrichten vom Remailer gelöscht und nicht weitergeschickt worden sind (Siehe auch: Dummy-Nachrichten)
Blockiert Siehe: Geblockt
cover traffic Nachrichten mehrerer Nutzer, die den Remailer erreichen und verlassen. Dieser Datenverkehr erschwert die Analyse Ihrer Mails. Manchmal wird cover traffic vorsätzlich von Nutzern erzeugt, indem Dummy-Nachrichten durch Ketten verschiedener Remailer geleitet werden, um die Rückverfolgung einer bestimmten Nachricht zu erschweren.
Cypherpunk
CPunk
Type1
Ein Cypherpunk-Remailer, auch als Type I- oder "CPunk" Remailer bezeichnet, akzeptiert Remail-Requests im Cypherpunk -Format. Die Liste der Optionen enthält bei solchen Remailern die Abkürzung cpunk.
Datenflussanalyse
engl.: traffic analysis
Das Schnüffeln in und die Analyse von privater Email, die von und zu Remailern unterwegs ist. Es soll dabei der ursprüngliche Sender oder der Endempfänger einer Nachricht ermittelt werden. Der Angriff umfasst die Erkennung von Mustern und die Inspektion von Headern, um festzustellen, mit wem ein Nutzer Email austauscht. Datenflussanalysen wird durch Cover-Traffic, Umsortieren, Pooling, Verschlüsselung und andere Techniken wirksam begegnet.
Datenmüll (Fülldaten),
engl.: Garbage
Zufälliger (gewöhnlich radix-64) Text, der dem Nachrichtenkörper angehängt wird, um ihn größer erscheinen zu lassen, als er tatsächlich ist. Datenmüll hilft dabei, Datenflussanalysen zu vereiteln. Der Zufallstext wird im Allgemeinen zwischen den Zeilen "-----Begin Garbage-----"und "-----End Garbage-----" eingefügt (Siehe auch: Inflate).
Denial Of Service
(etwa: Den Dienst verweigern)
Ein Angriff auf einen Remailer oder Benutzer (gelegentlich DoS abgekürzt), der den Remailer für seine Benutzer unbrauchbar macht. Dazu gehören auch solche Aktionen, die die Außerbetriebnahme oder Beeinträchtigung eines Remailers zum Ziel haben (Mailbomben oder Überfluten des Remailers) und Angriffe gegen Nym-Accounts, durch Versendung übergroßer Mengen Mail [Siehe auch: Replay-Angriff]
Dummy-Nachricht,
engl.: dummy message
Ein Remail-Request, der zu einem Remailer oder über eine Kette von Remailern geleitet wird, im letzten Remailer aber eine Null-Nachricht erzeugt und daher ignoriert wird. Dummy-Nachrichten dienen dazu, Cover-Traffic zu erzeugen (siehe auch: Bit Bucket)
Endempfänger Der Empfänger einer anonymen Nachricht, die durch einen Remailer oder eine Remailer-Kette geleitet worden ist. Manchmal ist der Endempfänger ein Mail2News-Gateway.
Explizit
engl.: explicit
Eine Funktion erhält das Attribut explizit, wenn sie durch die Anweisung eines Nutzers ausgelöst wird. Beispiele sind Remix-To, Encrypt-To, Latent-Time (Siehe auch: Transparent)
geblockt,
blockiert,
engl.: blocked
Eine Email-Adresse oder Newsgruppe ist blockiert, wenn der Betreiber eines Remailers den Nutzern verweigert, dorthin Nachrichten zu adressieren. Reliable-Remailer filtern Kommandos und Mail-Header, wobei einzig die geblockten Zieladressen entfernt werden. Andere Remailer können die gesamte Nachricht löschen, wenn blockierte Ziele darin auftauchen.
Nach Fällen des Missbrauchs, kann auch eine Absenderblockade dazu dienen, Remail-Requests, die durch bestimmte Domains oder Benutzer versendet werden, zu vernichten.
Hash Hash kann sich auf einen Hash-Header beziehen. Ein Hash ist auch eine mathematische Operation, die dazu dient, den Inhalt einer Nachricht durch eine Zahl zu repräsentieren. Jede einzelne Nachricht erzeugt dabei eine faktisch einzigartige "Hash-Summe". Verbreitete Hash-Algorithmen sind MD5 und SHA1. Hashes kommen in Replay-Caches zur Anwendung.
Hash-Header Ein Header, wie Subject, der im "Hash-Abschnitt" ("##") eines Remail-Requests eingefügt wird. Hash-Header werden in einer anonymen Nachricht als Mail-Header eingebaut.
Header Ein Mail-Header ist eine Zeile im Kopfabschnitt einer Mail, der Informationen liefert. Beispiele dafür sind Subject, From, Date, Newsgroups, Received [Siehe auch: Original-Header, Mail-Header, Nachrichtenkörper].
Kette
engl.: Chain
Eine Remailer-Kette steht für mehrere Remailer, die hintereinandergeschaltet werden, um eine anonyme Nachricht zuzustellen. Der erste Remailer verarbeitet den empfangenen Remail-Request und sendet den darin enthaltenen Text als anonyme Nachricht an den nächsten Remailer. In diesem Falle stellt der Text erneut einen Remail-Request dar. Er wird vom zweiten Remailer verarbeitet und so fort. Der letzte Remailer der Kette sendet den Nachrichtentext an den Endempfänger. Wenn die Remail-Requests in einer Kette PGP- oder Mixmaster-verschlüsselt sind, erkennt der letzte Remailer nicht die Adresse des ursprünglichen Absenders und der erste Remailer weiß nicht wer der Endempfänger der Nachricht ist.
Kommando
Anweisung
engl.: directive
Ein Kommando teilt dem Remailer mit, wie er Remail-Requests verarbeiten soll. Kommandos werden auch manchmal als "Remailer-Header", "Remailer Kontroll-Header" oder ":: Header" bezeichnet, obwohl es sich eigentlich nicht um Header handelt (Weitere Informationen).
konventionelle
Verschlüsselung
Eine Art der symmetrischen Verschlüsselung (gewönlich in PGP). Das bedeutet, dass die gleiche Passphrase zum Ver- und Entschlüsseln benutzt wird. Konventionelle Verschlüsselung wird häufig dazu verwendet, die Anonymität von Reply-Blöcken mit Hilfe des Encrypt-Key Kommandos zu verbessern. Die Passphrase, die zur Anwendung kommt, wird als "konventionelle Passphrase" bezeichnet. Konventionelle Verschlüsselung unterscheidet sich von der Verschlüsselung mit öffentlichen Schlüsseln, die auch als "asymmetrisch" bezeichnet wird (weitere Informationen).
Mail-Header
engl. auch: final header
Email- Header, die einer anonymen Nachricht hinzugefügt werden. Mail-Header können vom Endempfänger eingesehen werden.
Mail2News-
Gateway
Ein Dienst, der empfangene Emails ins Usenet postet. Nachrichten an Mail2News-Gateways (kurz: m2n) benötigen einen Newsgroups -Header, oder akzeptieren manchmal auch die Namen der Newsgruppen als Teil der Email-Adresse [weitere Informationen].
Middleman Ein Middleman-Remailer (angezeigt durch den Indikator middle in der Liste der Optionen) sendet Nachrichten nicht direkt an Endempfänger, sondern nur an einen anderen Remailer. Reliable-Remailer, die als Middleman konfiguriert sind, verhalten sich insofern "intelligent", dass sie Remailer als Empfänger einer Nachricht ohne Umweg, direkt anschreiben.
MIME MIME, oder Multipurpose Internet Mail Extension ist ein Email-Protokoll, das von einigen Email-Programmen angewendet wird. Nachrichten werden in Stücke zerteilt (wie Attachments) und können verschiedenartig kodiert werden. Soll ein Remail-Request an einen Remailer durch einen standard Email-Client versendet werden, ist es wichtig, MIME vorher abzustellen. Remailer akzeptieren keine Remail-Requests im MIME-Format oder mit Anhängen. Um MIME-Nachrichten und -Anhänge anonym zu senden, verwenden Sie einen Remailer-Client, der MIME unterstützt.
Mixmaster-Client Das Programm, das der Erzeugung von Mixmaster Remail-Requests dient. Mixmaster 2.0.3 oder 2.0.4 werden zur Verwendung mit Reliable-Remailern empfohlen.
Mixmaster,
Type II
Ein Mixmaster-Remailer, auch als Type II Remailer bezeichnet, akzeptiert Remail-Requests im Mixmaster -Format. Mixmaster-Remailer werden durch den Indikator mix gekennzeichnet.
Nachrichtenkörper Der Teil einer Email, der die eigentliche Nachricht enthält, aber keine Header. Währenddessen kann Nachrichten-Text auch den Teil eines Remail-Requests bedeuten, der an den Empfänger weitergeleitet wird.
News-Signatur Einige Zeilen Text, die an den Nachrichtenkörper von News-Artikeln angehängt werden können, um anzuzeigen, dass die Nachricht von einen anonymen Remailer gesendet worden ist (siehe auch: Anon-Post-To, Newsgroups).
Null-Nachricht Eine ungültige Nachricht, die aus einer Dummy-Nachricht entsteht und vom Remailer vernichtet wird [Siehe auch: Bit Bucket].
Nym Account Ein Nym-Account, oder "Nym" ist ein Email-Account, der auf einem Nym-Server eingerichtet wird (auch bezeichnet als Pseudonym-Server oder engl.: pseudonymous remailer). Nym-Accounts erlauben es ihren Inhabern, Mail unter Pseudonym zu empfangen und zu senden, ohne dass außer dem Benutzer selbst irgendjemand seine reale Email-Adresse kennt. Nym-Benutzer senden Mail über Ketten von Remailern und empfangen Mail, indem ein Reply-Block genutzt wird. Der Umgang mit Nym-Accounts kann in der Regel durch die Verwendung eines Remailer-Client vereinfacht werden [Weitere Informationen]
Optionen,
engl.: Capabilities
Eine Funktion oder Option, die von einem Remailer unterstützt wird, wie cpunk, mix und latent. Optionen werden für jeden Remailer in einer Zeile aufgelistet (weitere Informationen).
Optionen-Liste,
engl.: Capability string
Die Liste der Optionen beinhaltet die Remailer-Adresse und Indikatoren für die angebotenen Funktionen. Sie kann abgefragt werden, indem eine Mail mit Subject: remailer-conf an den Remailer gesendet wird oder die Remailer- Statistiken konsultiert werden (weitere Informationen).
Original-Header Email- Header die mit dem Remail-Request übermittelt werden. Sie bezeichnen die Email-Adresse des ursprünglichen Absenders und seinen Aufenthaltsort im Netz. Diese Header werden entfernt, wenn eine Nachricht anonym weitergeleitet wird.
PGP PGP steht für Pretty Good Privacy, ein Verschlüsselungsprogramm, das ursprünglich von Philip Zimmerman zur freien Verwendung durch jedermann geschrieben worden ist. Seither ist es zu einer sehr beliebten Software geworden und sichert vielerorts die private Kommunikation über Internet. PGP wird ausgiebig dazu verwendet, die Sicherheit und Anonymität von Cypherpunk -Remailern zu steigern. Remailer sind im Allgemeinen mit den PGP-Versionen 2.6.2 und 2.6.3(i) kompatibel. Gewöhnlich unterstützen Sie nicht PGP 5.x [Siehe auch: öffentliche Remailer-Schlüssel].
ping Versenden eines Remail-Requests an einen Remailer, der selbst eine Antwort zurückschickt. Zum Testen der Funktionstüchtigkeit eines Remailers [Siehe auch: Statistiken, Zuverlässigkeit von Remailern].
Pool Der Nachrichten-Pool eines Remailers besteht aus den gesammelten Nachrichten, die zum Weiterleiten anstehen. Remailer sammeln Nachrichten, damit der Nachweis ihrer Herkunft umso schwieriger ist. Pools ermöglichen die Umsortierung von Nachrichten und die Erzeugung von Cover-Traffic. Dadurch wird Angriffen durch Datenflussanalyse entgegengewirkt.
Priorität
Vorrang
Die Gewichtung von Anweisungen bewirkt, dass manche Kommandos vorrangig beachtet werden, wenn gleichzeitig mehrere davon existieren. Die Priorität von Nachrichten bestimmt, wie eine Nachricht versendet wird - als Remix, RePGP oder Klartext-Nachricht, noch bevor die Middleman und Rand-Hop Funktionen berücksichtigt werden.
pubring.mix Das ist die Mixmaster -Datei, die die öffentlichen Schlüssel für alle Remailer aus type2.lis enthält. Ihre Datei pubring.mix sollte regelmäßig aktualisiert werden, indem die aktuelle Schlüssel-Datei abgerufen wird.
Remailer Ein Mail-Dienst, der Remail-Requests annimmt, um anonyme Email zu versenden. Remailer sind Cypherpunk, Mixmaster oder Pseudonymserver. Mit "Remailer" kann auch die Software gemeint sein, die ein solcher Dienst verwendet.
Remailer-Adresse Die Email-Adresse, an die Benutzer Remail-Requests senden können. Die Adresse eines Remailers kann der Liste seiner Optionen entnommen werden [siehe auch: Remailer-Name]
Remailer-Benutzer Der ursprüngliche Sender, der einen Remail-Request an einen Remailer sendet und damit die anonyme Weiterleitung einer Nachricht veranlasst [Siehe auch: Betreiber].
Remailer-Client Ein Email-Programm, das speziell zur Verwendung mit Anonymen Remailern und Nym-Accounts gedacht ist. Remailer-Clients erstellen automatisch Remail-Requests und Reply-Blöcke, rufen Statistiken ab und vereinfachen andere wiederkehrende Remailer-Funktionen [Siehe auch: Jack B. Nymble, Potato, AnonPost, EasyNym, Private Idaho, und andere].
Remailer-Name Der Remailer-Name ist eine kurze, gebräuchliche Bezeichnung für einen Remailer, z.B.: Replay. Reliable-Remailer akzeptieren Remailer-Namen anstelle von Adressen in Kommandos. Der Name eines Remailers kann seiner Liste der Optionen entnommen werden.
Remailing Das anonyme Versenden eines Nachrichtentextes innerhalb eines Remail-Requests.
Remail-Request Eine speziell formatierte Nachricht, die an einen Remailer gerichtet ist und die anonyme Übermittlung des Nachrichtentextes an eine andere Adresse bewirkt. Remail-Requests können im Cypherpunk - oder Mixmaster-Format abgefasst sein, je nach den Fähigkeiten eines Remailers. Remail-Requests werden manchmal auch "Remailer-Nachrichten" genannt (was auch auf anonyme Nachrichten bezogen wird, hier aber eine andere Bedeutung hat).
Remix Eine Methode, die Cypherpunk -Remailer verwenden, um Mail an andere Cypherpunk-Remailer zu senden, die auch mix unterstützen. Die Nachricht wird als Mixmaster -Nachricht formatiert. Remix kann transparent oder explizit erfolgen [Siehe auch: RePGP] [weitere Informationen] [Knowledge Base]
RePGP Eine Methode, die Cypherpunk -Remailer verwenden, um Mail an andere Cypherpunk-Remailer zu senden. Die Nachricht wird PGP -verschlüsselt, um größere Sicherheit und Anonymität zu erreichen. RePGP kann transparent oder explizit erfolgen [Siehe auch: Remix] [weitere Informationen] [Knowledge Base].
Replay-Angriff
engl.: Replay-Attack
Eine Methode zur " Datenflussanalyse ", wobei eine große Anzahl Nachrichten über einen Reply-Block geschickt wird, oder ein vorhandener Remail-Request mehrfach abgesendet wird. Die Zunahme an Emailverkehr erleichtert die Suche nach dem Endempfänger der Remail-Requests. Replay-Angriffen wird durch Replay-Caches und die Verwendung von Max-Anweisungen entgegengewirkt [Siehe auch: " Denial Of Service " Angriff].
Replay-Cache Eine Einrichtung, die Nachrichten oder ihre Hash -Werte speichert, um der mehrfachen Versendung von Nachrichten entgegenzuwirken. Replay-Caches dienen dazu, Replay-Angriffe zu vereiteln und Spam zu reduzieren.
Reply-Block Ein Reply-Block (auch: verschlüsselter Reply-Block oder ERB) als Teil eines Remail-Requests erlaubt es Benutzern, auf Nachrichten zu antworten, indem der Reply-Block dem Nachrichtentext vorangestellt und das Resultat an einen genannten Remailer gesendet wird. Reply-Blöcke ermöglichen die anonyme Beantwortung von Mail-, sogar wenn der Sender die Adresse des Empfängers nicht kennt.
Reply-Blöcke werden nach dem Muster PGP-verschlüsselter Cypherpunk Remail-Requests konstruiert. Sie finden häufig in Nym-Accounts Verwendung, um einem Nym-Inhaber den Empfang von Email zu gestatten, ohne, dass der Betreiber des Nym-Servers die Adresse des Nutzers kennt. Weil sie möglicherweise sehr komplex sind, werden Reply-Blöcke häufig mit Hilfe eines Remailer-Clients erzeugt. [weitere Informationen]
Schlüssel
Remailer-Schlüssel
öffentlicher Schlüssel
Mix-Schlüssel
engl.: key
Der öffentlichen Schlüssel eines Remailers. Cypherpunk -Remailer besitzen einen öffentlichen PGP -Schlüssel. Mixmaster -Remailer besitzen einen öffentlichen Mix-Schlüsel (Einige Remailer haben beides). Öffentliche Schlüssel werden dazu verwendet, Remail-Requests an den Remailer zu verschlüsseln, entweder als PGP-verschlüsselten Remail-Request oder als Mixmaster -Nachricht. Sie können die Schlüsel eines Remailers beziehen, indem Sie ihm eine Mail mit Subject: remailer-key senden, oder durch Abruf aus dem Internet. PGP-Schlüssel werden in Ihren PGP-Schlüsselring integriert. Mix-Schlüssel werden in Ihre Dateien type2.list und pubring.mix aufgenommen.
Statistiken Remailer-Statistiken zeigen an, welche Remailer aktiv sind (und richtig arbeiten) und welche voraussichtlich Funktionsstörungen haben (nicht aktiv sind und daher Mail, die sie empfangen, nicht weiterleiten). Statistiken sind ein Indikator für die Zuverlässigkeit von Remailern. Sie werden automatisch von Servern erzeugt, die die Remailer regelmäßig "anpingen". Statistiken können an verschiedenen Stellen abgerufen werden.
transparent Eine Funktion erhält das Attribut transparent, wenn sie nicht durch die Aktion oder das Kommando eines Benutzers ausgelöst wird. Transparente Funktionen werden automatisch in Gang gesetzt und im Falle von Remix und RePGP kann nur durch das Test-To Kommando festgestellt werden, ob eine der beiden Funktionen eingeschaltet ist [Siehe auch: explizit].
type2.list Das ist eine Datei des Mixmaster-Client, die die Liste derzeit verfügbarer Remailer enthält. Sie sollte regelmäßig aktualisiert werden, indem die aktuellen Listen aus dem Internet abgerufen werden [siehe auch: pubring.mix]
Umsortieren
engl.: reorder
Ein Remailer, der Nachrichten umsortiert, sendet sie nicht entsprechend der Reihenfolge ihres Eintreffens ab. Dadurch ist es schwierig, festzustellen, welcher empfangene Remail-Request zu welcher anonymen, abgehenden Mail gehört.
Ursprünglicher Sender Der Benutzer eines Remailers, der einen Remail-Request einsendet, damit die darin enthaltene Nachricht anonym an den genannten Empfänger ausgeliefert wird (entweder an einen weiteren Remailer in einer Kette oder an den Endempfänger).
Zuverlässigkeit Aufgrund verschiedener Umstände erleben Remailer häufiger Aussetzer (engl.: down-times), als standard Email-Server. Wenn Remailer nicht arbeiten, kann Mail zwischengespeichert werden (zum späteren Versenden) oder verloren gehen. Daher rufen Benutzer Statistiken ab, um bezüglich der Funktionstüchtigkeit von Remailern immer auf dem Laufenden zu sein.

Nürnberg, 20. März 1999 (Fehler Fehler Fehler)
Michael Uplawski <der_ups@gmx.net>

Erzeugt mit Arachnophilia