Kommunikationsprotokoll - Versionsgeschichte

FreeW: + Kategorie:Manipulation | K

2023-04-04T01:20:17Z

+ Kategorie:Manipulation | K

Admin am 26. Dezember 2019 um 17:19 Uhr

2019-12-26T17:19:02Z

Änderungen zeigen

Admin am 26. Dezember 2019 um 17:18 Uhr

2019-12-26T17:18:41Z

Manorainjan: /* Message Disposition Notification */ no copy

2019-12-19T02:34:49Z

‎Message Disposition Notification: no copy

Manorainjan: /* Der Nutzen von Protokollen */ fertig

2019-12-19T02:21:44Z

‎Der Nutzen von Protokollen: fertig

Manorainjan: erstellt, in Bearbeitung

2019-12-19T01:05:03Z

erstellt, in Bearbeitung

Neue Seite

Ein '''Kommunikationsprotokoll''' ist ein Regelsatz, der den Ablauf einer Kommunikation regelt. Einem technikbasierten Informationsaustausch liegt in jedem Fall ein definiertes Protokoll zugrunde, wohingegen direkter zwischenmenschlicher Kommunikation oft kein bewusstes Protokoll zugrunde liegt, weshalb sie auch so fehleranfällig ist.

==Zwischenmenschlich==
Der Begriff des Protokolls im zwischenmenschlichen Bereich tritt zumeist als sogenanntes [[Diplomatisches Protokoll]] auf, also als eine Regelung, nach der z.B. die Treffen von Staatsoberhäuptern ablaufen. Daneben gibt es eine Vielzahl [[explizit]]er und [[implizit]]er Protokolle, die teils kulturell bedingt sind und demzufolge von Ort zu Ort und von Zeit zu Zeit variieren und andere, die sich aus der Funktionsweise des Gehirns ergeben haben. Kulturell bedingt ist z.B., dass es üblich ist, dass Mitarbeiter, die sich am Tagesbeginn in Deutschland treffen, sich gegenseitig mit "Guten Morgen" begrüßen, dass man die Übergabe einer Gabe mit einem "Bitte" begleitet und die Annahme mit einem "Danke". Kognitiv bedingt ist es, dass man jemanden anschaut, wenn man ihm zuhört.

==Technisch==
Die Vielfalt der technischen Protokolle ist so zahlreich wie die Anzahl der unterschiedlichen technischen Geräte. Die [[Node]]s des Internets verständigen sich z.B. mittels [[TCP/IP]], während [[Peripheriegerät]]e sich mit ihrem [[Host]], also mit dem [[Rechner]] an den sie angestöpselt sind, heutzutage meist per [[USB]]-Protokoll verständigen und per Funk angeschlossene Geräte z.B. [[Bluetooth]] oder [[W-LAN]] als Protokoll für die [[Luftschnittstelle]] verwenden.

Der Benutzer wird nach Möglichkeit von der Handhabung dieser rein technischen Protokolle fern gehalten, um die Bedienung zu vereinfachen und Fehlbedienungen zu minimieren. So muß ein Bluetooth-Kopfhörer meist nur einmal eingeschaltet werden und als neues Gerät im Bluetooth-Menü eines Smartphones durch einfaches Antippen bestätigt werden, um sich in Folge jedes mal selbsttätig zu Verbinden, sobald Smartphone und Kopfhörer betriebsbereit und in Reichweite zueinander (10 m) sind.

==E-Mail==
Eine Besonderheit stellen die E-Mail-Protokolle dar, weil hier der Mensch noch sehr direkt in den Kommunikationsprozess eingebunden ist.

===Adressierung===
Notwendigerweise muss eine Mail einen Empfänger haben. Man kann zwar gegen eine Wand reden, aber keine E-Mail irgendwohin oder nirgendwohin schicken. Das erlaubt das [[Simple Mail Transfer Protocol]] (SMTP) nicht, dass seit 1982 im Einsatz ist und somit bedeutend älter als das [[HTTP]] ist, dass dem zugrunde liegt, was wir heutzutage WWW oder Internet nennen. In so fern man auf eine empfangene Mail antwortet, ergibt sich der Empfänger automatisch aus der Absenderadresse der Ursprungsmail. Der [[E-Mail-Client]] übernimmt die Einsetzung der Adresse in dem Fall automatisch. Schreibt man eine Initiativ-Mail, muß man die korrekte Adresse des Empfängers wissen und selber eintragen. Hier muss der Mensch sich also direkt mit dem Protokoll auseinandersetzen und wird zur potenziellen Fehlerquelle. Man muss wissen, dass eine korrekte [[E-Mail-Adresse]] so aufgebaut ist: <Mailbox-Name>@<Server-Name>. Das Abtippen solcher Adressen ist die häufigste Fehlerquelle. Dabei sollten [[Syntaxfehler]], wie das Einfügen von [[Leerzeichen]] vom E-Mail-Client abgefangen werden, was aber [[Thunderbird]] nicht tut, weshalb derartige Fehler meistens vom [[E-Mail-Server]] abgefangen werden, wodurch der Benutzer am Versenden an derartig falsche Adressen gehindert wird. Dahingegen kann keine Technik den Benutzer daran hindern oder darauf aufmerksam machen, wenn er Mails an falsche aber existierende Adressen verschickt. Und es ist unvorhersagbar, was der falsche Empfänger dann mit der Mail machen wird. Er könnte sie z.B. kommentarlos löschen, woraufhin der Absender keine Möglichkeit hat, den Fehler zu bemerken. Mails an nicht existierende Adressen werden normalerweise zeitnah zurückgeschickt.

===Offener Versandt===
Mails werden wie Postkarten versendet. Den Inhalt kann jede Stelle mitlesen, über die der Datenstrom verläuft. Man kann die Inhalte zwar verschlüsseln, nicht aber die Adressen von Absender und Empfänger. Daher ist es ganz leicht, durch das Mitlesen des Internetverkehrs nicht nur E-Mail-Adressen zu sammeln, sondern auch festzustellen, wer mit wem kommuniziert. Man kann zwar mittels [[SMTPS]] (SMTP-secure) verhindern, dass beim Anmelden an den Server das Passwort mitgelesen werden kann, aber die Adressen lassen sich so nicht schützen, weil der Transport zwischen den Mail-Servern offen ist.

===Transportprobleme===
Der für den Empfang zuständige Mail-Server kann ausfallen. Dass führt zu einer Anzahl von erfolglosen Auslieferungsversuchen und schlussendlich zu einer um Stunden oder Tage verzögerten Fehlermeldung an den Absender. Ebenso kann die Mailbox des Empfängers "voll" sein. auch das führt zu einer - allerdings zeitnahen - Fehlermeldung. Sollte der Empfänger seine Mails nicht abrufen, z.B. weil er tot ist, ergibt das keine Fehlermeldung. Auch Fehlfunktionen in den Eingangsfiltern des Empfängers oder falsch-positive [[SPAM]]-Erkennung führt zu keiner Fehlermeldung, aber i.d.R. zum Verlust der Mail. Falsch-positive SPAM-Erkennungen auf dem Transportweg, also die Eintragung des sendenden Mail-Servers auf eine [[Blocklist]] führt zu einer Meldung über diesen schwer behebbaren Fehler.

===Message Disposition Notification===
Message Disposition Notification kurz MDN ist ein [[High-Level]]-Protokoll, das mit dem Benutzern direkt interagiert. Es fängt damit an, dass der Absender eine Empfangsbestätigung vom Empfänger anfordert. Dazu fügt der Mail-Client folgende Zeile in den [[E-Mail-Header]] ein:
* Disposition-Notification-To: <E-Mail-Adresse>
Daraufhin würde ein korrekt konfigurierter Mail-Client beim Empfang solcher Mail den Benutzer fragen, ob er bereit ist, den Empfang der Mail zu quittieren. Wenn ja, wird automatisch eine Empfangsbestätigung erstellt, die ihrerseits wie eine Mail auf dem selben Weg zurück geschickt wird, auf dem die bestätigte Mail hereingekommen ist und dann dem Absender der Mail angezeigt wird. Dadurch kann der Absender sehen, dass seine Mail von jemandem empfangen wurde. Sie ist also nicht im SPAM gelandet, gelöscht worden, noch auf dem Weg oder sonst wie untergegangen. Da man Mail-Clients auch so konfigurieren kann, dass sie jede MDN automatisch beantworten (oder nie), ist es nicht zulässig, aus einer Empfangsbestätigung zu schließen, dass die Mail auch gelesen wurde. Leider unterstützen nicht alle Mail-Clients das Anfordern oder Bestätigen von MDNs. Thunderbird unterstützt fallweise oder generelle Anforderung von MDNs und fallweise oder automatische Bestätigung sowie generelle Ignoranz von MDNs.

Positive [[Delivery Status Notification]]s (DSN) werden noch weniger unterstützt und dienen dazu, lediglich die Auslieferung an den letzten Mail-Server zu bestätigen, nicht das Abholen durch den Mail-Client. Vor- und Nachteil liegen darin, dass der individuelle Empfänger keinen Einfluss auf die Handhabung der DSN hat.

==Der Nutzen von Protokollen==
In einem rein technischen Kontext machen Protokolle die Datenübertragung überhaupt erst möglich. Teile der Protokolle, die als verzichtbar angesehen werden könnten, dienen dazu, die Sicherheit der Übertragung zu verbessern, also Übertragungsstörungen zu erkennen und möglichst zu kompensieren, so dass die übertragenen Daten vollständig und fehlerfrei übertragen werden, auch wenn die Übertragungsbedingungen mal nicht ideal sind.

Das gleiche gilt für zwischenmenschliche Protokolle. Redundanzen in der menschlichen Sprache ermöglichen das Aufdecken von Fehlern und gelegentlich auch die unmittelbare Kompensation. Z.B. ist in "Herbert ist heute gekommen. Er hat seine Schulden bezahlt." das Wort "er" eine Redundanz. "Herbert ist heute gekommen und hat seine Schulden bezahlt." wäre genau so verständlich. "Herbert ist heute gekommen, hat seine Schulden bezahlt." wäre auch verständlich, aber grammatikalisch falsch. "Herbert ist heute gekommen. <unverständlich> hat seine Schulden bezahlt." wäre ein Übertragungsfehler, der beim Empfänger kompensiert werden kann. "<unverständlich> ist heute gekommen. <unverständlich> hat seine Schulden bezahlt." ist ein mehrfacher Übertragungsfehler, der nicht mehr beim Empfänger kompensiert werden kann. Hier wird eine Rückfrage (die ein Protokollelement ist) notwendig.

Wenn der Gesprächspartner wegschaut und mit seinen Blicken umherschweift, ist das ein impliziter Hinweis auf eine gestörte Übertragung und macht eine Rückfrage erforderlich. Unprofessionelle Rückfragen wie: "Hörst Du mir überhaupt zu?" können mit einem halbautomatischen "Ja, sicher." beantwortet werden und sind daher völlig wertlos. [[Offene Frage]]n wie: "An was denkst du gerade?", sind eher geeignet, die Situation zu klären und nicht nur festzustellen, ob das Letztgesagte überhaupt angekommen ist.

@@ Zeile 4: / Zeile 4: @@
 == Zwischenmenschlich ==
-Der Begriff des Protokolls im zwischenmenschlichen Bereich tritt zumeist als sogenanntes [[Diplomatisches_Protokoll|Diplomatisches Protokoll]] auf, also als eine Regelung, nach der z.B. die Treffen von Staatsoberhäuptern ablaufen. Daneben gibt es eine Vielzahl [[Explizit|expliziter]] und [[Implizit|impliziter]] Protokolle, die teils kulturell bedingt sind und demzufolge von Ort zu Ort und von Zeit zu Zeit variieren und andere, die sich aus der Funktionsweise des Gehirns ergeben haben. Kulturell bedingt ist z.B., dass es üblich ist, dass Mitarbeiter, die sich am Tagesbeginn in Deutschland treffen, sich gegenseitig mit "Guten Morgen" begrüßen, dass man die Übergabe einer Gabe mit einem "Bitte" begleitet und die Annahme mit einem "Danke". Kognitiv bedingt ist es, dass man jemanden anschaut, wenn man ihm zuhört.
+Der Begriff des Protokolls im zwischenmenschlichen Bereich tritt zumeist als sogenanntes [[Diplomatisches_Protokoll|Diplomatisches Protokoll]] auf, also als eine Regelung, nach der z.&nbsp;B. die Treffen von Staatsoberhäuptern ablaufen. Daneben gibt es eine Vielzahl [[Explizit|expliziter]] und [[Implizit|impliziter]] Protokolle, die teils kulturell bedingt sind und demzufolge von Ort zu Ort und von Zeit zu Zeit variieren und andere, die sich aus der Funktionsweise des Gehirns ergeben haben. Kulturell bedingt ist z.&nbsp;B., dass es üblich ist, dass Mitarbeiter, die sich am Tagesbeginn in Deutschland treffen, sich gegenseitig mit "Guten Morgen" begrüßen, dass man die Übergabe einer Gabe mit einem "Bitte" begleitet und die Annahme mit einem "Danke". Kognitiv bedingt ist es, dass man jemanden anschaut, wenn man ihm zuhört.
 == Technisch ==
-Die Vielfalt der technischen Protokolle ist so zahlreich wie die Anzahl der unterschiedlichen technischen Geräte. Die [[Node|Nodes]] des Internets verständigen sich z.B. mittels [[TCP/IP|TCP/IP]], während [[Peripheriegerät|Peripheriegeräte]] sich mit ihrem [[Host|Host]], also mit dem [[Rechner|Rechner]] an den sie angestöpselt sind, heutzutage meist per [[USB|USB]]-Protokoll verständigen und per Funk angeschlossene Geräte z.B. [[Bluetooth|Bluetooth]] oder [[W-LAN|W-LAN]] als Protokoll für die [[Luftschnittstelle|Luftschnittstelle]] verwenden.
+Die Vielfalt der technischen Protokolle ist so zahlreich wie die Anzahl der unterschiedlichen technischen Geräte. Die [[Node|Nodes]] des Internets verständigen sich z.&nbsp;B. mittels [[TCP/IP|TCP/IP]], während [[Peripheriegerät|Peripheriegeräte]] sich mit ihrem [[Host|Host]], also mit dem [[Rechner|Rechner]] an den sie angestöpselt sind, heutzutage meist per [[USB|USB]]-Protokoll verständigen und per Funk angeschlossene Geräte z.&nbsp;B. [[Bluetooth|Bluetooth]] oder [[W-LAN|W-LAN]] als Protokoll für die [[Luftschnittstelle|Luftschnittstelle]] verwenden.
 Der Benutzer wird nach Möglichkeit von der Handhabung dieser rein technischen Protokolle fern gehalten, um die Bedienung zu vereinfachen und Fehlbedienungen zu minimieren. So muß ein Bluetooth-Kopfhörer meist nur einmal eingeschaltet werden und als neues Gerät im Bluetooth-Menü eines Smartphones durch einfaches Antippen bestätigt werden, um sich in Folge jedes mal selbsttätig zu Verbinden, sobald Smartphone und Kopfhörer betriebsbereit und in Reichweite zueinander (10 m) sind.
@@ Zeile 18: / Zeile 18: @@
 === Adressierung ===
-Notwendigerweise muss eine Mail einen Empfänger haben. Man kann zwar gegen eine Wand reden, aber keine E-Mail irgendwohin oder nirgendwohin schicken. Das erlaubt das [[Simple_Mail_Transfer_Protocol|Simple Mail Transfer Protocol]] (SMTP) nicht, dass seit 1982 im Einsatz ist und somit bedeutend älter als das [[HTTP|HTTP]] ist, dass dem zugrunde liegt, was wir heutzutage WWW oder Internet nennen. In so fern man auf eine empfangene Mail antwortet, ergibt sich der Empfänger automatisch aus der Absenderadresse der Ursprungsmail. Der [[E-Mail-Client|E-Mail-Client]] übernimmt die Einsetzung der Adresse in dem Fall automatisch. Schreibt man eine Initiativ-Mail, muß man die korrekte Adresse des Empfängers wissen und selber eintragen. Hier muss der Mensch sich also direkt mit dem Protokoll auseinandersetzen und wird zur potenziellen Fehlerquelle. Man muss wissen, dass eine korrekte [[E-Mail-Adresse|E-Mail-Adresse]] so aufgebaut ist: <Mailbox-Name>@<Server-Name>. Das Abtippen solcher Adressen ist die häufigste Fehlerquelle. Dabei sollten [[Syntaxfehler|Syntaxfehler]], wie das Einfügen von [[Leerzeichen|Leerzeichen]] vom E-Mail-Client abgefangen werden, was aber [[Thunderbird|Thunderbird]] nicht tut, weshalb derartige Fehler meistens vom [[E-Mail-Server|E-Mail-Server]] abgefangen werden, wodurch der Benutzer am Versenden an derartig falsche Adressen gehindert wird. Dahingegen kann keine Technik den Benutzer daran hindern oder darauf aufmerksam machen, wenn er Mails an falsche aber existierende Adressen verschickt. Und es ist unvorhersagbar, was der falsche Empfänger dann mit der Mail machen wird. Er könnte sie z.B. kommentarlos löschen, woraufhin der Absender keine Möglichkeit hat, den Fehler zu bemerken. Mails an nicht existierende Adressen werden normalerweise zeitnah zurückgeschickt.
+Notwendigerweise muss eine Mail einen Empfänger haben. Man kann zwar gegen eine Wand reden, aber keine E-Mail irgendwohin oder nirgendwohin schicken. Das erlaubt das [[Simple_Mail_Transfer_Protocol|Simple Mail Transfer Protocol]] (SMTP) nicht, dass seit 1982 im Einsatz ist und somit bedeutend älter als das [[HTTP|HTTP]] ist, dass dem zugrunde liegt, was wir heutzutage WWW oder Internet nennen. In so fern man auf eine empfangene Mail antwortet, ergibt sich der Empfänger automatisch aus der Absenderadresse der Ursprungsmail. Der [[E-Mail-Client|E-Mail-Client]] übernimmt die Einsetzung der Adresse in dem Fall automatisch. Schreibt man eine Initiativ-Mail, muss man die korrekte Adresse des Empfängers wissen und selber eintragen. Hier muss der Mensch sich also direkt mit dem Protokoll auseinandersetzen und wird zur potenziellen Fehlerquelle. Man muss wissen, dass eine korrekte [[E-Mail-Adresse|E-Mail-Adresse]] so aufgebaut ist: <Mailbox-Name>@<Server-Name>. Das Abtippen solcher Adressen ist die häufigste Fehlerquelle. Dabei sollten [[Syntaxfehler|Syntaxfehler]], wie das Einfügen von [[Leerzeichen|Leerzeichen]] vom E-Mail-Client abgefangen werden, was aber [[Thunderbird|Thunderbird]] nicht tut, weshalb derartige Fehler meistens vom [[E-Mail-Server|E-Mail-Server]] abgefangen werden, wodurch der Benutzer am Versenden an derartig falsche Adressen gehindert wird. Dahingegen kann keine Technik den Benutzer daran hindern oder darauf aufmerksam machen, wenn er Mails an falsche aber existierende Adressen verschickt. Und es ist unvorhersagbar, was der falsche Empfänger dann mit der Mail machen wird. Er könnte sie z.&nbsp;B. kommentarlos löschen, woraufhin der Absender keine Möglichkeit hat, den Fehler zu bemerken. Mails an nicht existierende Adressen werden normalerweise zeitnah zurückgeschickt.
 === Offener Versand ===
@@ Zeile 26: / Zeile 26: @@
 === Transportprobleme ===
-Der für den Empfang zuständige Mail-Server kann ausfallen. Dass führt zu einer Anzahl von erfolglosen Auslieferungsversuchen und schlussendlich zu einer um Stunden oder Tage verzögerten Fehlermeldung an den Absender. Ebenso kann die Mailbox des Empfängers "voll" sein. auch das führt zu einer - allerdings zeitnahen - Fehlermeldung. Sollte der Empfänger seine Mails nicht abrufen, z.B. weil er tot ist, ergibt das keine Fehlermeldung. Auch Fehlfunktionen in den Eingangsfiltern des Empfängers oder falsch-positive [[SPAM|SPAM]]-Erkennung führt zu keiner Fehlermeldung, aber i.d.R. zum Verlust der Mail. Falsch-positive SPAM-Erkennungen auf dem Transportweg, also die Eintragung des sendenden Mail-Servers auf eine [[Blocklist|Blocklist]] führt zu einer Meldung über diesen schwer behebbaren Fehler.
+Der für den Empfang zuständige Mail-Server kann ausfallen. Dass führt zu einer Anzahl von erfolglosen Auslieferungsversuchen und schlussendlich zu einer um Stunden oder Tage verzögerten Fehlermeldung an den Absender. Ebenso kann die Mailbox des Empfängers "voll" sein. auch das führt zu einer - allerdings zeitnahen - Fehlermeldung. Sollte der Empfänger seine Mails nicht abrufen, z.&nbsp;B. weil er tot ist, ergibt das keine Fehlermeldung. Auch Fehlfunktionen in den Eingangsfiltern des Empfängers oder falsch-positive [[SPAM|SPAM]]-Erkennung führt zu keiner Fehlermeldung, aber i.d.R. zum Verlust der Mail. Falsch-positive SPAM-Erkennungen auf dem Transportweg, also die Eintragung des sendenden Mail-Servers auf eine [[Blocklist|Blocklist]] führt zu einer Meldung über diesen schwer behebbaren Fehler.
 === Message Disposition Notification ===
@@ Zeile 44: / Zeile 44: @@
 In einem rein technischen Kontext machen Protokolle die Datenübertragung überhaupt erst möglich. Teile der Protokolle, die als verzichtbar angesehen werden könnten, dienen dazu, die Sicherheit der Übertragung zu verbessern, also Übertragungsstörungen zu erkennen und möglichst zu kompensieren, so dass die übertragenen Daten vollständig und fehlerfrei übertragen werden, auch wenn die Übertragungsbedingungen mal nicht ideal sind.
-Das gleiche gilt für zwischenmenschliche Protokolle. Redundanzen in der menschlichen Sprache ermöglichen das Aufdecken von Fehlern und gelegentlich auch die unmittelbare Kompensation. Z.B. ist in "Herbert ist heute gekommen. Er hat seine Schulden bezahlt." das Wort "er" eine Redundanz. "Herbert ist heute gekommen und hat seine Schulden bezahlt." wäre genau so verständlich. "Herbert ist heute gekommen, hat seine Schulden bezahlt." wäre auch verständlich, aber grammatikalisch falsch. "Herbert ist heute gekommen. <unverständlich> hat seine Schulden bezahlt." wäre ein Übertragungsfehler, der beim Empfänger kompensiert werden kann. "<unverständlich> ist heute gekommen. <unverständlich> hat seine Schulden bezahlt." ist ein mehrfacher Übertragungsfehler, der nicht mehr beim Empfänger kompensiert werden kann. Hier wird eine Rückfrage (die ein Protokollelement ist) notwendig.
+Das gleiche gilt für zwischenmenschliche Protokolle. Redundanzen in der menschlichen Sprache ermöglichen das Aufdecken von Fehlern und gelegentlich auch die unmittelbare Kompensation. z.&nbsp;B. ist in "Herbert ist heute gekommen. Er hat seine Schulden bezahlt." das Wort "er" eine Redundanz. "Herbert ist heute gekommen und hat seine Schulden bezahlt." wäre genau so verständlich. "Herbert ist heute gekommen, hat seine Schulden bezahlt." wäre auch verständlich, aber grammatikalisch falsch. "Herbert ist heute gekommen. <unverständlich> hat seine Schulden bezahlt." wäre ein Übertragungsfehler, der beim Empfänger kompensiert werden kann. "<unverständlich> ist heute gekommen. <unverständlich> hat seine Schulden bezahlt." ist ein mehrfacher Übertragungsfehler, der nicht mehr beim Empfänger kompensiert werden kann. Hier wird eine Rückfrage (die ein Protokollelement ist) notwendig.
 Wenn der Gesprächspartner wegschaut und mit seinen Blicken umherschweift, ist das ein impliziter Hinweis auf eine gestörte Übertragung und macht eine Rückfrage erforderlich. Unprofessionelle Rückfragen wie: "Hörst Du mir überhaupt zu?" können mit einem halbautomatischen "Ja, sicher." beantwortet werden und sind daher völlig wertlos. [[Offene_Frage|Offene Fragen]] wie: "An was denkst du gerade?", sind eher geeignet, die Situation zu klären und nicht nur festzustellen, ob das Letztgesagte überhaupt angekommen ist.
@@ Zeile 50: / Zeile 50: @@
 === Shadow Banning Detection ===
-Angesichts der rapide zunehmenden Nutzung von [[Shadow_Banning|Shadow Banning]] zur Unterdrückung und [[Marginalisierung|Marginalisierung]] von [[Dissident|Dissidenten]], muß man bestehende Protokolle aktivieren und weitere Protokolle etablieren, um versteckte Zensur mindestens zu detektieren und möglichst auch zu kompensieren oder zu umgehen. Der blinde Glaube, dass eine Mail einfach deshalb ihren Empfänger erreicht hat, weil man keine Fehlermeldung bekommen hat, ist gefährlich. In Zeiten der [[Hybride_Kriegsführung|Hybriden Kriegsführung]] ist die Denkungsart "Es hat funktioniert, weil ich es gemacht habe." unzulässig. Alles muß ständig überprüft werden. Und bei Handlungen im virtuellen Raum ist sogar der Erfolgsmeldung, die eigentlich das Ergebnis einer Überprüfung sein sollte, zu misstrauen. [[Cyberwar|Cyberwar]] bedeutet nicht nur, dass Übertragungen gestört werden. Es bedeutet auch, dass Protokollelemente gefälscht werden, um gestörte Übertragungen wie erfolgreiche Übertragungen erscheinen zu lassen. Ein Intelligentes Protokoll hat also immer eine Ebene mehr, als notwendig erscheint. Eine MDN anzufordern erscheint zwar nutzlos, wenn man sich klar macht, dass nicht nur der Transport der Mail unterdrückt werden kann, sondern auch eine falsche MDN verschickt werden könnte. Allerdings wäre eine "verschwundene" Mail lediglich ein unklares technisches Problem. Eine gefälschte MDN hingegen wäre der Beweis für gezielte Manipulation. Wenn ich z.B. weiß, dass mein Kommunikationspartner sonntags keine Mails ließt, weil er Sonntags immer [[Medien-Fasten|Medien-Fasten]]-Tag hat, ich aber sonntags eine MDN von ihm bekomme, ist die Manipulation schon aufgeflogen. Eine effektive Manipulation des Protokolls erfordert also derart intime Kenntnisse der beteiligten Personen, dass eine automatisierte Durchführung nicht möglich, sondern personeller Einsatz erforderlich ist. Das widerspricht aber den Grundsätzen des Shadow Banning, das darauf aufbaut, das der Algorithmus kostengünstig gegen den Menschen arbeitet. Anders herum bedeutet die Nicht-Nutzung der technischen Protokolle, sich den Angriffen durch feindliche Algorithmen wehrlos auszusetzen. In jeder vitalen Beziehung sollte also mindestens das Protokollelement [[Lebenszeichen|Lebenszeichen]] regelmäßig genutzt werden, um Beziehungsstörungen möglichst frühzeitig zu detektieren.
+Angesichts der rapide zunehmenden Nutzung von [[Shadow_Banning|Shadow Banning]] zur Unterdrückung und [[Marginalisierung|Marginalisierung]] von [[Dissident|Dissidenten]], muss man bestehende Protokolle aktivieren und weitere Protokolle etablieren, um versteckte Zensur mindestens zu detektieren und möglichst auch zu kompensieren oder zu umgehen. Der blinde Glaube, dass eine Mail einfach deshalb ihren Empfänger erreicht hat, weil man keine Fehlermeldung bekommen hat, ist gefährlich. In Zeiten der [[Hybridkrieg|Hybriden Kriegsführung]] ist die Denkungsart "Es hat funktioniert, weil ich es gemacht habe." unzulässig. Alles muß ständig überprüft werden. Und bei Handlungen im virtuellen Raum ist sogar der Erfolgsmeldung, die eigentlich das Ergebnis einer Überprüfung sein sollte, zu misstrauen. [[Cyberwar|Cyberwar]] bedeutet nicht nur, dass Übertragungen gestört werden. Es bedeutet auch, dass Protokollelemente gefälscht werden, um gestörte Übertragungen wie erfolgreiche Übertragungen erscheinen zu lassen. Ein Intelligentes Protokoll hat also immer eine Ebene mehr, als notwendig erscheint. Eine MDN anzufordern erscheint zwar nutzlos, wenn man sich klar macht, dass nicht nur der Transport der Mail unterdrückt werden kann, sondern auch eine falsche MDN verschickt werden könnte. Allerdings wäre eine "verschwundene" Mail lediglich ein unklares technisches Problem. Eine gefälschte MDN hingegen wäre der Beweis für gezielte Manipulation. Wenn ich z.&nbsp;B. weiß, dass mein Kommunikationspartner sonntags keine Mails ließt, weil er Sonntags immer [[Medien-Fasten|Medien-Fasten]]-Tag hat, ich aber sonntags eine MDN von ihm bekomme, ist die Manipulation schon aufgeflogen. Eine effektive Manipulation des Protokolls erfordert also derart intime Kenntnisse der beteiligten Personen, dass eine automatisierte Durchführung nicht möglich, sondern personeller Einsatz erforderlich ist. Das widerspricht aber den Grundsätzen des Shadow Banning, das darauf aufbaut, das der Algorithmus kostengünstig gegen den Menschen arbeitet. Anders herum bedeutet die Nicht-Nutzung der technischen Protokolle, sich den Angriffen durch feindliche Algorithmen wehrlos auszusetzen. In jeder vitalen Beziehung sollte also mindestens das Protokollelement [[Lebenszeichen|Lebenszeichen]] regelmäßig genutzt werden, um Beziehungsstörungen möglichst frühzeitig zu detektieren.
-[[Category:Zensur]] [[Category:Kommunikation]]
+[[Category:Kommunikation]] [[Category:Manipulation]] [[Category:Zensur]]

← Nächstältere Version		Version vom 19. Dezember 2019, 02:21 Uhr
Zeile 34:		Zeile 34:

	Wenn der Gesprächspartner wegschaut und mit seinen Blicken umherschweift, ist das ein impliziter Hinweis auf eine gestörte Übertragung und macht eine Rückfrage erforderlich. Unprofessionelle Rückfragen wie: "Hörst Du mir überhaupt zu?" können mit einem halbautomatischen "Ja, sicher." beantwortet werden und sind daher völlig wertlos. [[Offene Frage]]n wie: "An was denkst du gerade?", sind eher geeignet, die Situation zu klären und nicht nur festzustellen, ob das Letztgesagte überhaupt angekommen ist.		Wenn der Gesprächspartner wegschaut und mit seinen Blicken umherschweift, ist das ein impliziter Hinweis auf eine gestörte Übertragung und macht eine Rückfrage erforderlich. Unprofessionelle Rückfragen wie: "Hörst Du mir überhaupt zu?" können mit einem halbautomatischen "Ja, sicher." beantwortet werden und sind daher völlig wertlos. [[Offene Frage]]n wie: "An was denkst du gerade?", sind eher geeignet, die Situation zu klären und nicht nur festzustellen, ob das Letztgesagte überhaupt angekommen ist.
		+
		+	===Shadow Banning Detection===
		+	Angesichts der rapide zunehmenden Nutzung von [[Shadow Banning]] zur Unterdrückung und [[Marginalisierung]] von [[Dissident]]en, muß man bestehende Protokolle aktivieren und weitere Protokolle etablieren, um versteckte Zensur mindestens zu detektieren und möglichst auch zu kompensieren oder zu umgehen. Der blinde Glaube, dass eine Mail einfach deshalb ihren Empfänger erreicht hat, weil man keine Fehlermeldung bekommen hat, ist gefährlich. In Zeiten der [[Hybride Kriegsführung\|Hybriden Kriegsführung]] ist die Denkungsart "Es hat funktioniert, weil ich es gemacht habe." unzulässig. Alles muß ständig überprüft werden. Und bei Handlungen im virtuellen Raum ist sogar der Erfolgsmeldung, die eigentlich das Ergebnis einer Überprüfung sein sollte, zu misstrauen. [[Cyberwar]] bedeutet nicht nur, dass Übertragungen gestört werden. Es bedeutet auch, dass Protokollelemente gefälscht werden, um gestörte Übertragungen wie erfolgreiche Übertragungen erscheinen zu lassen. Ein Intelligentes Protokoll hat also immer eine Ebene mehr, als notwendig erscheint. Eine MDN anzufordern erscheint zwar nutzlos, wenn man sich klar macht, dass nicht nur der Transport der Mail unterdrückt werden kann, sondern auch eine falsche MDN verschickt werden könnte. Allerdings wäre eine "verschwundene" Mail lediglich ein unklares technisches Problem. Eine gefälschte MDN hingegen wäre der Beweis für gezielte Manipulation. Wenn ich z.B. weiß, dass mein Kommunikationspartner sonntags keine Mails ließt, weil er Sonntags immer [[Medien-Fasten]]-Tag hat, ich aber sonntags eine MDN von ihm bekomme, ist die Manipulation schon aufgeflogen. Eine effektive Manipulation des Protokolls erfordert also derart intime Kenntnisse der beteiligten Personen, dass eine automatisierte Durchführung nicht möglich, sondern personeller Einsatz erforderlich ist. Das widerspricht aber den Grundsätzen des Shadow Banning, das darauf aufbaut, das der Algorithmus kostengünstig gegen den Menschen arbeitet. Anders herum bedeutet die Nicht-Nutzung der technischen Protokolle, sich den Angriffen durch feindliche Algorithmen wehrlos auszusetzen. In jeder vitalen Beziehung sollte also mindestens das Protokollelement [[Lebenszeichen]] regelmäßig genutzt werden, um Beziehungsstörungen möglichst frühzeitig zu detektieren.
		+
		+	[[Kategorie:Zensur]]
		+	[[Kategorie:Kommunikation]]

@@ Zeile 15: / Zeile 15: @@
 Notwendigerweise muss eine Mail einen Empfänger haben. Man kann zwar gegen eine Wand reden, aber keine E-Mail irgendwohin oder nirgendwohin schicken. Das erlaubt das [[Simple Mail Transfer Protocol]] (SMTP) nicht, dass seit 1982 im Einsatz ist und somit bedeutend älter als das [[HTTP]] ist, dass dem zugrunde liegt, was wir heutzutage WWW oder Internet nennen. In so fern man auf eine empfangene Mail antwortet, ergibt sich der Empfänger automatisch aus der Absenderadresse der Ursprungsmail. Der [[E-Mail-Client]] übernimmt die Einsetzung der Adresse in dem Fall automatisch. Schreibt man eine Initiativ-Mail, muß man die korrekte Adresse des Empfängers wissen und selber eintragen. Hier muss der Mensch sich also direkt mit dem Protokoll auseinandersetzen und wird zur potenziellen Fehlerquelle. Man muss wissen, dass eine korrekte [[E-Mail-Adresse]] so aufgebaut ist: <Mailbox-Name>@<Server-Name>. Das Abtippen solcher Adressen ist die häufigste Fehlerquelle. Dabei sollten [[Syntaxfehler]], wie das Einfügen von [[Leerzeichen]] vom E-Mail-Client abgefangen werden, was aber [[Thunderbird]] nicht tut, weshalb derartige Fehler meistens vom [[E-Mail-Server]] abgefangen werden, wodurch der Benutzer am Versenden an derartig falsche Adressen gehindert wird. Dahingegen kann keine Technik den Benutzer daran hindern oder darauf aufmerksam machen, wenn er Mails an falsche aber existierende Adressen verschickt. Und es ist unvorhersagbar, was der falsche Empfänger dann mit der Mail machen wird. Er könnte sie z.B. kommentarlos löschen, woraufhin der Absender keine Möglichkeit hat, den Fehler zu bemerken. Mails an nicht existierende Adressen werden normalerweise zeitnah zurückgeschickt.
-===Offener Versandt===
-Mails werden wie Postkarten versendet. Den Inhalt kann jede Stelle mitlesen, über die der Datenstrom verläuft. Man kann die Inhalte zwar verschlüsseln, nicht aber die Adressen von Absender und Empfänger. Daher ist es ganz leicht, durch das Mitlesen des Internetverkehrs nicht nur E-Mail-Adressen zu sammeln, sondern auch festzustellen, wer mit wem kommuniziert. Man kann zwar mittels [[SMTPS]] (SMTP-secure) verhindern, dass beim Anmelden an den Server das Passwort mitgelesen werden kann, aber die Adressen lassen sich so nicht schützen, weil der Transport zwischen den Mail-Servern offen ist.
+=== Offener Versand ===
 ===Transportprobleme===

@@ Zeile 24: / Zeile 24: @@
 Message Disposition Notification kurz MDN ist ein [[High-Level]]-Protokoll, das mit dem Benutzern direkt interagiert. Es fängt damit an, dass der Absender eine Empfangsbestätigung vom Empfänger anfordert. Dazu fügt der Mail-Client folgende Zeile in den [[E-Mail-Header]] ein:
 * Disposition-Notification-To: <E-Mail-Adresse>
-Daraufhin würde ein korrekt konfigurierter Mail-Client beim Empfang solcher Mail den Benutzer fragen, ob er bereit ist, den Empfang der Mail zu quittieren. Wenn ja, wird automatisch eine Empfangsbestätigung erstellt, die ihrerseits wie eine Mail auf dem selben Weg zurück geschickt wird, auf dem die bestätigte Mail hereingekommen ist und dann dem Absender der Mail angezeigt wird. Dadurch kann der Absender sehen, dass seine Mail von jemandem empfangen wurde. Sie ist also nicht im SPAM gelandet, gelöscht worden, noch auf dem Weg oder sonst wie untergegangen. Da man Mail-Clients auch so konfigurieren kann, dass sie jede MDN automatisch beantworten (oder nie), ist es nicht zulässig, aus einer Empfangsbestätigung zu schließen, dass die Mail auch gelesen wurde. Leider unterstützen nicht alle Mail-Clients das Anfordern oder Bestätigen von MDNs. Thunderbird unterstützt fallweise oder generelle Anforderung von  MDNs und fallweise oder automatische Bestätigung sowie generelle Ignoranz von MDNs.
+Daraufhin würde ein korrekt konfigurierter Mail-Client beim Empfang solcher Mail den Benutzer fragen, ob er bereit ist, den Empfang der Mail zu quittieren. Wenn ja, wird automatisch eine Empfangsbestätigung erstellt, die ihrerseits wie eine Mail auf dem selben Weg zurück geschickt wird, auf dem die bestätigte Mail hereingekommen ist und dann dem Absender der Mail angezeigt wird. Diese Bestätigungsmail wird aber nicht, wie normale Mails, auch in den GESENDET-Ordner des bestätigenden Empfängers kopiert. Sie "kostet" den Empfänger also maximal einen Klick.
 Positive [[Delivery Status Notification]]s (DSN) werden noch weniger unterstützt und dienen dazu, lediglich die Auslieferung an den letzten Mail-Server zu bestätigen, nicht das Abholen durch den Mail-Client. Vor- und Nachteil liegen darin, dass der individuelle Empfänger keinen Einfluss auf die Handhabung der DSN hat.