Email header Received: from

[user08157]

Hallo,

Received: from [IPextern] (helo=[192.168.178.122])

warum wird in einer Email im Header die interne IP, hier 192.168.178.122, mitgesendet.
Gibt es dafür technische Gründe oder widerspricht das nicht sogar der DSGVO?


Ebenfalls falls der Empfänger das speichert hat das technische Gründe oder widerspricht das nicht auch der DSGVO ?


Was sind die technischen Gründe sowas un einer Email mitzusenden?
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.11.0

Gruss

[GregorS]

Received: from [IPextern] (helo=[192.168.178.122])
warum wird in einer Email im Header die interne IP, hier 192.168.178.122, mitgesendet.

Weil das so in den RFCs festgelegt ist. Es soll sich halt wirklich jede „Station“, an der eine E-Mail durchkommt, in die Headerdaten eintragen, damit man im Fehlerfall restlos alle identifizieren kann, die Ihre Finger resp. Programme im Spiel hatten.

... widerspricht das nicht sogar der DSGVO?

Wieso sollte das der DSGVO widersprechen? Welcher Bestimmung genau?

Was sind die technischen Gründe sowas un einer Email mitzusenden?
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.11.0

Auch hier: Es sollen halt alle für eine zielführende Fehlersuche relevanten Informationen vorhanden sein.

Ich sehe da keinen Verstoß gegen die DSGVO.

Gruß

Gregor

[user08157]

Das mag in den RFC so festegelegt sein, daraus lässt sich aber nicht ableiten das diese zu anderen Gesetzen rechtskonform sind..Der finale Empfänger einer Email erhält Informationen wie
[IPextern] (helo=[192.168.178.122])
aus denen er ableiten kann wo der Sender sitzt, in der Schweiz, in den USA oder an einen Vodafone Anschluss in Deutschland.
Auch ob es der gleiche Rechner wie bein der letzten Email war oder eine andere interne IP was schließen kann ob es sich um einen anderen Rechner handeln könnte.
Warum erhält er diese, Datenminimierung ist ein wesentliches Element der DSGVO.
Man könnte diese Daten doch "problemlos" in der Email löschen bevor diese den endgültigen Empfänger in das Postfach zugestellt werden.
Und die [IPextern] ist auch im Log File des beteiligten Emailserver enthalten, eine weiterer Speicherung und Weitergabe in der Email ist nicht erforderlich.

[electri]

warum wird in einer Email im Header die interne IP mitgesendet.
Gibt es dafür technische Gründe oder widerspricht das nicht sogar der DSGVO?
Ebenfalls falls der Empfänger das speichert hat das technische Gründe oder widerspricht das nicht auch der DSGVO ?

Bitte entschuldigt meine Emotionalität, aber: Nach der Logik würde das Lesen und Speichern von Emails, die ich empfange, ebenso der DSGVO widersprechen. Verwende ich ein gmail-Konto, dann werden die Daten (Inhaltsdaten der Mail, nicht nur der Header) sogar in der USA gespeichert und ausgewertet. Ich verstehe immer wieder nicht, warum niemand gegen die Gesetze auf die Straße geht, die immer mehr unsere Privatsphäre in krasser Weise einschränken (Lauschangriff, Videoüberwachung, PAG, Vorratsdatenspeicherung Versuch Einhundert, geplante Chatkontrolle, etc.), aber bei "Kleinigkeiten" ist das auf einmal alles ein DSGVO-Verstoß. Trotzdem verwenden wir alle (ich will mich da nicht ausnehmen) Windows, Handy, Auto, autonomen Rasenmäher oder Staubsauger, und so weiter. (Emotionaler Ausbruch Ende).

Zum Thema: Ich wüsste nicht, was die DSGVO verletzt. Du schickst ja freiwillig Emails weg mit dem Provider und Mailclient deines Vertrauens. Je nach Provider und Client kann man übrigens die Absender-IP und den User-Agent unterdrücken. Unter Claws kann ich es z.B. einstellen, dass der User-Agent nicht hinzugefügt wird, und einige datenschutzfreundliche Mail-Provider wie meines Wissens posteo oder mailbox.org (ohne Garantie) nehmen die Absender-IP aus dem Header.

[GregorS]

... Ich verstehe immer wieder nicht, warum niemand gegen die Gesetze auf die Straße geht, die immer mehr unsere Privatsphäre in krasser Weise einschränken (Lauschangriff, Videoüberwachung, PAG, Vorratsdatenspeicherung Versuch Einhundert, geplante Chatkontrolle, etc.), aber bei "Kleinigkeiten" ist das auf einmal alles ein DSGVO-Verstoß. ...

Auch mir ist ein Rätsel, warum so gerne auf Kleinigkeiten herumgehackt wird, während die „richtig dicken Klopse“ eigentlich immer klaglos geschluckt werden.

Gruß

Gregor

[Meillo]

Zur technischen Seite: Verhindern kann man das, indem man einen Relay-Host betreibt, ueber den man die Mail routet. Der kann dann den Received-Header mit der lokalen IP-Adresse rausfiltern. Oder man schreibt die Mail gleich im Webmailer.

[user08157]

Aus dem geschriebenen kann ich immer noch nicht erkennen das es notwendig ist dem Endempfänger der Email interne IP und externe IP des Absenders mitzuteilen, zumal das herausfiltern bevor die Email an den Postkasten des Endempfängers übergeben wird ja wohl problemlos möglich ist.

Und wie geschrieben Datenminimierung ist ein wesentlicher Bestandteil der DSGVO.

Zu sagen ist doch überall so, da kommt es da doch auch nicht mehr drauf an ist eine qualifizierte Betrachtung.

[Meillo]

Das Verhalten, das du gerne aendern wuerdest, ist seit 1982, also seit 40 Jahren (!), standardisiert. Siehe: https://www.rfc-editor.org/rfc/rfc821. Alle Email-Software, die als Kommunikationssoftware natuerlich einheitlich funktionieren muss, arbeitet seit 40 Jahren in der Weise.

Der Hintergrund damals war die wertvolle Nachvollziehbarkeit des Transportweges. Heute ist die nicht mehr in der gleichen Weise noetig, wie damals. Heute will man aus Datensparsamkeitssicht eher das Gegenteil, also Nicht-Nachvollziehbarkeit. Dabei sind Received-Header (wenn man sie richtig zu interpretieren weiss) immer noch eine wertvolle Information, um Phishing zu erkennen.

Abgesehen davon, dass es kaum moeglich ist, ein so altes System wie Email (das schon zehn Jahre bevor das Web ueberhaupt aufgekommen ist schon standardisiert war und selbst zumindest weitere zehn Jahre aelter ist), zu aendern, und auch abgesehen davon, dass (wie die anderen schon geschrieben haben, dieses Thema eine Kleinigkeit ist gegenueber den Datenschutzproblemen, die wir alle problemlos akzeptieren, und auch abgesehen davon, dass du andere Kommunikationsmedien nutzen kannst oder ein Email-Setup bauen oder Webmail nutzen kannst, so dass dieses Problem nicht auftaucht, ... mal von all dem abgesehen, zeigt dein Vorschlag, die Received-Header fuer den Endempfaenger rauszufiltern, dass du weder die Technik von Email noch das relevantere Datenschutzproblem verstanden zu haben scheinst.

Mir kommt es mehr so vor, wie wenn dir ungewollt und unangenehmerweise deine IP-Adresse fuer einen Empfaenger bekannt geworden ist, du dich darueber aergerst und nun hier deinen Frust darueber ablaedst. Email muss dabei als Suendenbock herhalten.

Wenn es dir wirklich um eine Verbesserung der Datensparsamkeit bei Email gehen wuerde, dann wuerden deine Posts anders aussehen.

[electri]

Aus dem geschriebenen kann ich immer noch nicht erkennen das es notwendig ist dem Endempfänger der Email interne IP und externe IP des Absenders mitzuteilen,
[...]
Und wie geschrieben Datenminimierung ist ein wesentlicher Bestandteil der DSGVO.

Wie gesagt ist es meines Wissens möglich je nach Mailclient die interne IP sowie den User-Agent zu unterdrücken. Dass die externe IP den Kommunikationspartnern bekannt wird, ist teil des Internet. Surfst du im WWW, dann ist deine externe IP auch den Webseiten bekannt, die du aufrufst. Da hilft auch keine DSGVO, da die IPs ja einen Zweck haben, nämlich Aufrechterhaltung der Verbindung, Schutz der Webseite vor DDOS, und so weiter. Wobei auch das unterdrückt werden kann, wenn du den Webmailer verwendest, oder einen entsprechenden Mail-provider, oder ein VPN verwendest.

Geschätzt gut 90 % meiner privaten Mailkontakte verwenden kostenlose Freemailer wie gmail/yahoo/gmx & Co.. Mein Hausarzt hatte bis vor kurzem einen Freemailer! Datenschutzrechtlich werden Inhaltsdaten strenger behandelt als Metadaten. Daher halte ich aus rechtlichen Gründen die Verwendung von Freemailern für durchaus problematisch. Ich wüsste aber nicht, warum der Header gegen die DSGVO verstoßen solle. Sofern es sich nur um allgemeine Grundsätze wie Datensparsamkeit handelt, können schon gute Gründe dazu führen, dass die Grundsätze nicht angewendet werden.

[mludwig]

Was im HELO Header drinsteht, bestimmt der Absender bzw. dessen verwendete Software. Wenn der Absender die Information also - bewusst oder unbewusst - mitsendet, wieso sollte das gegen die DSGVO verstoßen? Wenn er es geheim halten wollte, soll er halt was anderes ins HELO-Feld reinschreiben (z. B. den DNS Namen des Mailservers zB). Das kann halt dazu führen, dass der nächste Mailserver die Mail nicht haben will, wenn er gegen die RFC verstößt. Immerhin kann er dann nicht mehr gegen die DSGVO verstoßen.

Wenn mir jemand freiwillig (und ungefragt) seine privaten Daten mitteilt, ist das kein Verstoß gegen die DSGVO. Ich (als Empfänger) kann diese Daten dann sogar speichern, erst beim (ungefragten) veröffentlichen habe ich wohl ein Problem.

Sonst hätten ja sämtliche Systeme zum Nachrichtenaustausch ein Problem. Auf einer Postkarte könnte man erkennen, wo diese abgestempelt wurde ... der Horror, warum das noch keiner verboten hat. /sarkasmus

[MSfree]

Received: from [IPextern] (helo=[192.168.178.122])

Ja und? Was soll das mit der DSGVO zu tun haben?
Die DSGVO reguliert (sie verbietet es aber nicht) das Verarbeiten und Speichern von personenbezogenen Daten. 192.168.178.122 ist aber alles andere, nur nicht personenbezogen. Subnetze, die mit 192.168 anfangen, werden in fast allen Heimnetzten verwendet, wovon es in Deutschalnd rund 40 Millionen gibt. 192.168.178 im Speziellen sind typischerweise Subnetze, die von Fritzboxen angeboten werden, die in mindestens einem Drittel der Haushalte vorhanden sind. Wie man von zig Millionen in Deutschland installierter Fritzboxen auf "personenbezogen" rückfolgert, ist mir absolut schleieraft.

[mat6937]

Wie man von zig Millionen in Deutschland installierter Fritzboxen auf "personenbezogen" rückfolgert, ist mir absolut schleieraft.

Ob personen- oder Gerätebezogen, hängt davon ab, wie "gut" man das Subnetz der FritzBox (als border device) mit der externen/öffentlichen IPv4-Adresse (die der TE anonymisiert hat), kennt:

Code: Alles auswählen

Received: from [IPextern] (helo=[192.168.178.122])

Bei mir (diverse email-Software) _kann_ das z. B. so aussehen:

Code: Alles auswählen

Received: from [192.168.178.22] ([10#.###.###.###]) by mail.###net

D. h. jetzt nicht, dass ich ein Problem mit emails habe.

[Huo]

Manche E-Mail-Anbieter entfernen den ersten Received-Header ganz aus der E-Mail, z.B. mailbox.org. Dann wird weder die lokale noch die externe IP-Adresse mitgesandt.

Wobei es bei der internen IP auch vom Mailclient abhängt, ob sie überhaupt weitergegeben wird. Bei aus Claws-Mail versendeten E-Mails fehlt sie, in Thunderbird lässt sie sich in der erweiterte Konfiguration durch einen Fake-String, z.B. den Localhost, ersetzen:

Code: Alles auswählen

mail.smtpserver.default.hello_argument = [127.0.0.1]

[user08157]

Bei einem Teil der Beiträge handelt es sich um Rentnerlogik nach dem Motte war schon immer so und dazu die Betrachtung warum nicht statt warum.
Dazu noch die Unterstellung mit schlechter Erfahrung.

DSGVO hat viele Seiten und ist auch Datenminimierung bevor man überhaupt mit Datenverknüfung anfängt.

Aus der internen IP kann man z.B. sehen ob ich für den Versand einen Email ein anderen Rechner benutzt habe und aus der externen IP des Email Clients ob ich mich an einer anderen "Stelle" befinde, ggbf. sogar wo ich mich befinde.
Warum soll der finale Empfänger das aus der Email erfahren? Per brainstorming fällt einen sofort ein z.B. um über ein Monate ein Bewegungsprofil aufzubauen, welchen Rechner er benutzt, oder wo er sich aufgehalten hat oder eine Alarmmeldung bei einer eingehenden Email zu erfahren das der Absender sich woanders aufhält, usw.

Der Vergleich mit einem Brief hinkt. Natürlich kann man aus dem Umschlag Briefmarke und Frankatur erfahren wo der Brief herkommt. Aber es geht nicht um einen einzelnen Brief der i.d.R in der Poststelle ohnehin vernichtet wird und nicht mit dem Brief weitergegeben wird sondern um die Speicherung der Umschläge. Diese wäre bestimmt nicht DSGVO konform.

Es geht auch zusätzlich nicht um einen einzelne Information sondern um die Sammlung und Verknüpfung dieser, beginnend schon bei der Möglichkeit dieses zu tun.

Und technisch scheint es ja wohl kein Problem zu sein sowas wie Received: from [IPextern] (helo=[192.168.178.122]) zu entfernen oder bei finaler Akzeptanz und einfügen in den Verarbeitungsprozess des finalen Empfänger zu entfernen.

[user08157]

Was im HELO Header drinsteht, bestimmt der Absender bzw. dessen verwendete Software. Wenn der Absender die Information also - bewusst oder unbewusst - mitsendet, wieso sollte das gegen die DSGVO verstoßen? Wenn er es geheim halten wollte, soll er halt was anderes ins HELO-Feld reinschreiben (z. B. den DNS Namen des Mailservers zB). Das kann halt dazu führen, dass der nächste Mailserver die Mail nicht haben will, wenn er gegen die RFC verstößt. Immerhin kann er dann nicht mehr gegen die DSGVO verstoßen.

Und was gespeichert wird und werden kann entscheidet der finale Mailserver mit den Inhalten die er dem POP/IMAP Server übergibt die diese Emails dann auf ihre Rechner runterladen oder sogar dauerhaft speichern.
Wenn mir einen Behörde oder Firma Email als Kommunikationsmöglichkeit anbietet kann es nicht meine Aufgabe sein zu überlegen oder zu erforschen was ich wie an Daten übergeben damit der finale Empfänger rechtskonform ist. Das soll er machen.

Das liegt mir nun vor:
'Nach Art. 17 DSGVO können Sie die unverzügliche Löschung Ihrer personenbezogenen Daten verlangen. Nach Art. 18 DSGVO können sie alternativ verlangen, dass die Verarbeitung Ihrer personenbezogenen Daten einschränkt wird.

Ich bin mal gespannt wenn ich im Hinblick auf das angebotene "..dass die Verarbeitung Ihrer personenbezogenen Daten einschränkt wird.." fordere das man interne IP und IP meines EmailClients nicht speichert.

[Meillo]

Danke fuer die hilfreiche Antwort, Huo.

Und technisch scheint es ja wohl kein Problem zu sein sowas wie Received: from [IPextern] (helo=[192.168.178.122]) zu entfernen oder bei finaler Akzeptanz und einfügen in den Verarbeitungsprozess des finalen Empfänger zu entfernen.

Dann kann mein Kumpel Bob kein Profil mehr von mir erstellen, aber Google kann es weiterhin. Google hat zudem deutlich mehr Interesse daran, diese Daten auszuwerten.

Fuer alle Szenarien, die von MUA --> MeinProvider --> EmpfaengerProvider --> EmpfaengerMUA abweichen, funktioniert das Denkmodell nicht mehr. Dieses heute fuer Privatpersonen vorherrschende Schema ist nur ein Spezialfall einer breiten Vielfalt an Setups. In einem Store-and-Forward-System ist die Idee ``finaler Empfaenger'' zudem recht willkuerlich.

Wenn man die Information zuverlaessig entfernen will, dann muss das am *Anfang* des Transfers passieren, nicht am Ende. Nur eine Information, die ich nicht losschicke, kommt auch sicher nicht an. Bei einem dezentralen, heterogenen System waere jede Erwartung daran, was bei spaeteren MTAs mal passiert, reine Spekulation.

Provider koennten Headerinformationen rausloeschen, bevor sie die Mails an ihre User ausliefern, aber wer wuerde so einen Provider waehlen? Und wenn es in Deutschland gesetztlich erzwungen waere, wuerde man einfach einen Provider im Ausland nehmen, oder seinen eigenen MTA betreiben.

Die letzte von mir kontrollierte Stelle wird zwangslaeufig vom ersten nicht mehr von mir kontrollierten System aus sichtbar sein. Ab dieser Stelle habe ich keine Kontrolle mehr darueber was beim Empfaenger ankommt. Und diese Kontaktstelle kann ich auch nicht aus eigener Kraft verbergen.

Datenschutz ist (wie Sicherheit) Teil des grundlegenden Designs einer Technologie. Man kann sie nicht einfach nachtraeglich reinbauen. Email ist nunmal wie es ist. Ich sehe nicht, wie man das aendern sollte, ausser indem man Email zu etwas macht, was kein Email mehr ist. Dieser immer wieder unternommende Versuch zerstoert letztlich nur eine an sich funktionierende aber nicht alle Beduerfnissen entsprechende Technologie, um eine halblebige, inkonsistente Abwandlung davon zu schaffen, die wiederum nicht alle Beduerfnisse erfuellt. Wenn man etwas anderes haben will, das anders funktioniert als Email, dann wird man auch etwas anderes nehmen muessen.

[mludwig]

Das liegt mir nun vor:
'Nach Art. 17 DSGVO können Sie die unverzügliche Löschung Ihrer personenbezogenen Daten verlangen. Nach Art. 18 DSGVO können sie alternativ verlangen, dass die Verarbeitung Ihrer personenbezogenen Daten einschränkt wird.

Ich bin mal gespannt wenn ich im Hinblick auf das angebotene "..dass die Verarbeitung Ihrer personenbezogenen Daten einschränkt wird.." fordere das man interne IP und IP meines EmailClients nicht speichert.

Ich kann die Mails von dir Speichern, egal was drin steht (interne IP oder nicht). Du kannst die Löschung verlangen - dann wird die Mail halt gelöscht. Eine "Verarbeitung" dieser angeblich personenbezogenen internen IP ist eh Verschwörungstheorie - irgendeinen Nachweis dafür hab ich nirgendwo gesehen. D. h. du kannst die gerne Verlangen dass die Verarbeitung eingeschränkt wird ... ändert vermutlich genau gar nichts.

[Meillo]

Manche E-Mail-Anbieter entfernen den ersten Received-Header ganz aus der E-Mail, z.B. mailbox.org. Dann wird weder die lokale noch die externe IP-Adresse mitgesandt.

Weisst du dazu naeheres? Der ``erste'' Received-Header ist ja in der Datei der letzte, weil neue immer am Anfang eingefuegt werden. Ausser wenn Microsoft Exchange irgendwo in der Transferkette steckt, weil das gerne mal willkuerlich die Received-Header umordnet. Mich wuerde interessieren wie mailbox.org das genau macht: Schauen die auf's Datum oder loeschen sie einfach die letzte Received-Zeile?

Dass so ein Ansatz nicht unbedingt ausreichend ist, zeigt sich, wenn man z.B. einen lokalen MTA auf dem Homeserver hat, weil dann die ersten zwei Received-Header geloescht werden muessten. Und falls man noch eine weitere Queue oder eine Fetchmail-Uebertragung dazwischengeschaltet hat, bevor die Mail raus ins Internet geht, dann sind es noch weitere Zeilen, die Aufschluss ueber die lokale Situation geben. Wobei man die immerhin selber entfernen kann. So gesehen kann man immerhin sicherstellen, dass maximal der Received-Header, den die erste nicht selbst kontrollierten Stelle einfuegt, Aufschluesse ueber eigene Informationen gibt. Wenn dieser entfernt wird und man die Mails am besten jeweils gesammelt um zwoelf Uhr mittags verschickt, dann lassen sich auch keine Rueckschluesse mehr ueber den Schlafrhythmus und die Zeitgestaltung am Tag treffen.

Darueber nachzudenken, welche Informationen ausgewertet werden koennen, finde ich ich durchaus wertvoll. Die Frage, was technisch zu aendern waere, ist dagegen deutlich komplexer, vor allem weil es gilt, die Wirksamkeit und die Folgen einer Aenderung abzuschaetzen. Generell sehe ich die Gefahr deutlich weniger bei den Endanwendern sondern viel mehr bei den Internetriesen, die die Mailinfrastruktur grossteils kontrollieren.

[mludwig]

Darueber nachzudenken, welche Informationen ausgewertet werden koennen, finde ich ich durchaus wertvoll. Die Frage, was technisch zu aendern waere, ist dagegen deutlich komplexer, vor allem weil es gilt, die Wirksamkeit und die Folgen einer Aenderung abzuschaetzen. Generell sehe ich die Gefahr deutlich weniger bei den Endanwendern sondern viel mehr bei den Internetriesen, die die Mailinfrastruktur grossteils kontrollieren.

Insofern ist sicherlich Datensparsamkeit sinnvoller (dh. den Client sinnvoll den helo-header befüllen lassen), als hinterher den Empfänger aufzufordern, Daten zu löschen die einem nicht gefallen. Denn das muss selbst mit DSGVO nicht funktionieren: es gibt durchaus Gesetze die dem entgegenstehen: bei Bestellungen, Verträgen etc. wird z. B. gefordert, die zugehörige Kommunikation lange aufzubewahren - Steuerprüfung etc lässt grüßen.

Ob jemand überhaupt aus HELO für irgendwas verwertbare Informationen entlockt halte ich eh für fragwürdig. Gerade im dem Beispiel des Threaderstellers ging es um eine IP, die jede Fritzbox standardmäßig intern verteilt. Fritzboxen sind gerade in Deutschland nun nicht gerade selten.

[user08157]

Es ist Aufgabe des Endempfängers der Email dafür zu sorgen das die Verarbeitung DSGV konform stattfindet.
Eine in Deutschland ansässige Behörde oder Firma sollte das leisten können. Um Endanwender sollen sich andere Institutionen kümmern.

Ich kann nicht erkennen das es DSGVO konform ist wenn ein Sachbearbeiter mit seinem Laptop zu Hause sitzt, Unmengen an Emails auf seinen Rechner lokal gespeichert hat und da auch beispielhaft so was wie Received: from [IPextern] (helo=[192.168.178.122]) in der Email steht.
Warum braucht der Sachbebarbeiter überhaupt den ganzen Email Header? Weil man sich vorher keine Gedanken gemacht hat was er technisch wirklich braucht?
Es scheint mir alles sehr viel Rentnerlogik zu sein. Die Welt entwickelt sich eben weiter.

Ich werde das Angebot mal annehmen"..dass die Verarbeitung Ihrer personenbezogenen Daten einschränkt wird.." fordere das man interne IP und IP meines EmailClients nicht speichert.
Wenn man mir schreibt das können wir nicht, kann man eben behaupten das wenn man mit denen per Email kommuniziert mit einen einfachen Click der Sachbearbeiter diverse Informationen erhalten kann und diese sogar noch lokal auf seinen Rechner speichert. Dann kann man sich noch anschauen ob ggbf. Einwilligungen erfolgt sind und diese das auch abdecken und vor allem dem Unterzeichner hinreichend deutlich gemacht worden ist was er da unterschreibt.

[electri]

Weisst du dazu naeheres? Der ``erste'' Received-Header ist ja in der Datei der letzte, weil neue immer am Anfang eingefuegt werden. Ausser wenn Microsoft Exchange irgendwo in der Transferkette steckt, weil das gerne mal willkuerlich die Received-Header umordnet. Mich wuerde interessieren wie mailbox.org das genau macht: Schauen die auf's Datum oder loeschen sie einfach die letzte Received-Zeile

Wenn ich das richtig sehe, dann gibt es hinter der Infrastruktur des Mail-providers einfach nix. Das ist bei mehreren privacy-engagierten Mailanbietern so. Es erscheint so, wie wenn der MUA fehlen würde, und die Mailweitergabe direkt beim Provider beginnt. Wie der Mailprovider das technisch macht, da habe ich keine Ahnung.


Ich verstehe nach wie vor die Welle nicht. Dass die Absender-IP bekannt ist, das ist doch nix neues. Jegliche Verbindung über Netzwerk funktioniert so. Jetzt gibt es halt den Sonderfall, dass im Gegensatz zu einer direkten Verbindung bei Mail die Absender-IP durch den Privider unterdrückt werden kann. Viel relevanter als diese Information sind aber doch die Inhalte der Mail. Und die liegen oftmals schlecht gesichert auf dem selbst gebastelten Mail-server, oder auf irgendwelchen Freemailern rum. Des weiteren bin ich mir sicher, dass z.B. eine Firma wie Microsoft selbst bei bezahlten Business-Postfächern die Metadaten auswerten wird, allein schon zur Bekämpfung von Spam. .... Wobei es ja eigentlich keine Welle ist, da sich hier viele einige sind, und nur in Details unterscheiden.

[Huo]

Manche E-Mail-Anbieter entfernen den ersten Received-Header ganz aus der E-Mail, z.B. mailbox.org. Dann wird weder die lokale noch die externe IP-Adresse mitgesandt.

Weisst du dazu naeheres? Der ``erste'' Received-Header ist ja in der Datei der letzte, weil neue immer am Anfang eingefuegt werden. Ausser wenn Microsoft Exchange irgendwo in der Transferkette steckt, weil das gerne mal willkuerlich die Received-Header umordnet. Mich wuerde interessieren wie mailbox.org das genau macht: Schauen die auf's Datum oder loeschen sie einfach die letzte Received-Zeile?

O je, selbst wenn ich Näheres zum Verfahren wüsste, würde mir vermutlich das notwendige technische Hintergrundwissen fehlen, um es zu verstehen. Vielleicht helfen Insidern zwei Beiträge im Kuketz-Blog zum Thema IP-Stripping weiter?
https://www.kuketz-blog.de/e-mail-anbie ... zgruenden/
https://www.kuketz-blog.de/postfix-ip-s ... im-detail/

[electri]

Ich kann nicht erkennen das es DSGVO konform ist wenn ein Sachbearbeiter mit seinem Laptop zu Hause sitzt, Unmengen an Emails auf seinen Rechner lokal gespeichert hat und da auch beispielhaft so was wie Received: from [IPextern] (helo=[192.168.178.122]) in der Email steht.
Warum braucht der Sachbebarbeiter überhaupt den ganzen Email Header? Weil man sich vorher keine Gedanken gemacht hat was er technisch wirklich braucht?
Es scheint mir alles sehr viel Rentnerlogik zu sein. Die Welt entwickelt sich eben weiter.

Es ist nicht DSGVO-konform wenn ein Sachbearbeiter zu Hause auf seinem privaten (!) Laptop dienstliche Mails speichert. Es ist sehr wohl in Ordnung, wenn er oder sie einen Firmen-Laptop verwendet.

Der Emailheader wird vom Sachbearbeiter nicht benötigt. Aber er wird technisch für die Versendung von Emails benötigt. Bei der Argumentation müsstest du auch die Rufnummer beim Telefonieren unterdrücken, oder entsprechendes beim Fax ... bei Post dürftest du auch keinen Absender drauf schreiben, und müsstest der Post verbieten einen Poststempel drauf zu setzen, dieser enthält ja, wie oben bereits gesagt, den Ort wo der Brief eingeschmissen wurde. Das sind alles Infos, die der Empfänger (im Falle einer Firma oder Behörde) nicht braucht, was aber für den Versandt deiner Mitteilung notwendig ist.

Und warum geht es dir eigentlich nur um Metadaten, und nicht um Inhalte? Mich nervt viel mehr, dass fast jeder Internetshop meine Telefonnummer und mein Geburtsdatum haben will, was er eigentlich nicht braucht. Adresse und Name sollte für die Bestellung reichen. Den Rest will er entweder für die Schufaauskunft, oder um Daten (mehr oder weniger anonymisiert) verwenden bzw. verkaufen zu können.

[Meillo]

Es ist Aufgabe des Endempfängers der Email dafür zu sorgen das die Verarbeitung DSGV konform stattfindet.
Eine in Deutschland ansässige Behörde oder Firma sollte das leisten können. Um Endanwender sollen sich andere Institutionen kümmern.

Ich kann nicht erkennen das es DSGVO konform ist wenn ein Sachbearbeiter mit seinem Laptop zu Hause sitzt, Unmengen an Emails auf seinen Rechner lokal gespeichert hat und da auch beispielhaft so was wie Received: from [IPextern] (helo=[192.168.178.122]) in der Email steht.
Warum braucht der Sachbebarbeiter überhaupt den ganzen Email Header? Weil man sich vorher keine Gedanken gemacht hat was er technisch wirklich braucht?

Dann ist die Loesung doch einfach, dass diese Behoerden und Firmen kein Email mehr einsetzen, sondern andere Kommunikationstechnologien nutzen. Das ist die bessere Loesung als Email veraendern zu wollen in einer Form, die nicht zum Design von Email passt und damit auch nur juristisch belangt aber nicht technisch erzwungen werden kann.

Das Problem ist nicht, dass diese Information im Email-Header steht, sondern, dass Email die falsche Technologie fuer diesen Anwendungsfall ist.

Weisst du dazu naeheres? Der ``erste'' Received-Header ist ja in der Datei der letzte, weil neue immer am Anfang eingefuegt werden. Ausser wenn Microsoft Exchange irgendwo in der Transferkette steckt, weil das gerne mal willkuerlich die Received-Header umordnet. Mich wuerde interessieren wie mailbox.org das genau macht: Schauen die auf's Datum oder loeschen sie einfach die letzte Received-Zeile

Wenn ich das richtig sehe, dann gibt es hinter der Infrastruktur des Mail-providers einfach nix. Das ist bei mehreren privacy-engagierten Mailanbietern so. Es erscheint so, wie wenn der MUA fehlen würde, und die Mailweitergabe direkt beim Provider beginnt. Wie der Mailprovider das technisch macht, da habe ich keine Ahnung.

So macht das technich Sinn, dann loeschen die einfach bei eingehenden Mails alle Received-Header und fuegen dann nur noch die eigenen hinzu. Das ist einfach und stupide umsetzbar.

[electri]

Ganz aktuell auf Golem: https://www.golem.de/news/chatkontrolle ... 74374.html
Da es dem Threadersteller ja um das Thema Datenschutz geht, vielleicht mal ein Link der für Bodenhaftung sorgt. Wird flächendeckend Ende-zu-Ende-Verschlüsselung für jegliche Kommuikation verboten, und werden Inhaltsdaten standardmäßig aus gewichtigen strafrechtlichen Gesichtspunkten überprüft, dann liegt es auf der Hand dass diese Daten zeitnah auch für andere, nebensächliche, rein wirtschaftliche Interessen verwendet werden. Und sobald die Inhalte überall im Klartext verfügbar sind, kann ich mir den Datenschutz sowieso sonst wohin schieben. Das vom TE genannte Problem ist angesichts dieser drohenden Gefahr meines Erachtens zu vernachlässigen. Ich persönlich (IMHO) finde es wichtig, diese Entwicklung zu stoppen, z.B. durch die Unterstützung von Organisation die die Privatsphäre hoch halten, oder durch das richtige Kreuzchen an der Wahlurne.