Ist die Zuverlässigkeit von BCCing-E-Mails garantiert?


29

Mit anderen Worten, ist es eine sichere Annahme, dass niemand von Empfängern jemals E-Mails in BCC sehen wird? Was ist, wenn der Empfänger ein Administrator seines Mailservers (aber nicht des Absenders) ist und Änderungen an seinem Server vornehmen kann?


15
Im Allgemeinen ist E-Mail nicht sicher und nicht zuverlässig. Wenn der Empfänger ein Administrator seines Servers ist, kann er so ziemlich alles daran ändern.
Lord Peter

Für das, was es wert ist, habe ich ein Problem mit gerade diesem ATM. stackoverflow.com/questions/31527974/…
Johnsnails

Antworten:


21

Nein. SMTP ist ein Klartextprotokoll , das Store-and-Forward- Methoden verwendet.

Was das bedeutet:

  • Klartext: Jeder Server, der diese Nachricht weiterleitet, sieht sie vollständig, einschließlich aller Header-Informationen. Obwohl jeder Empfänger im BCC-Feld normalerweise seine eigene E-Mail erhält (der Server sendet also eine angepasste E-Mail, in der alle anderen BCC-Empfänger entfernt werden sollten (Schwerpunkt sollte !), Im Gegensatz zu CC, in dem die Daten gespeichert werden bleibt erhalten), dass noch eine einzige E-Mail in den Headern gespeichert ist, im Klartext (keine Verschlüsselung, keine Verschleierung, nichts).
  • Speichern und Weiterleiten: Die E-Mail muss nicht direkt an den Mailserver des Empfängers gesendet werden, sondern kann (und wird normalerweise) über eine Reihe von E-Mail-Zwischenservern weitergeleitet werden. es wird auf jedem gespeichert (auf unbestimmte Zeit) und dann an den nächsten Hop weitergeleitet (wiederum nicht unbedingt das endgültige Ziel).
  • Bedenken Sie, dass die E-Mail an eine nicht vorhandene, vollständige, blockierte oder anderweitig nicht funktionsfähige Adresse gesendet wird. Die Kopie der E-Mail kann zusammen mit den Diagnosedaten an mehreren Stellen landen, nicht unbedingt an allen Postfächern ( zB Fehlerprotokolle oder die Postmaster- Mailbox)
  • (Dies, bevor Ihre E-Mail bei den Mailservern des Ziels ankommt, die sie für immer speichern und an jeden weitergeben könnten, der mit einer Vorladung kommt, aber das ist eine etwas andere Geschichte.)

Mit anderen Worten, Ihre Annahme ist unsicher. Wenn Sie Privatsphäre und Sicherheit wünschen, verwenden Sie digitale Signaturen und Verschlüsselung, z. B. GPG. Vanille-E-Mail ist ein falsches Werkzeug für einen solchen Job.


1
Wie löst die Verschlüsselung das Problem des Versteckens von Empfängern?
Detly

Dies ist nicht der Fall, aber Piskvor sprach nicht unbedingt über die Empfängerpostfächer der Nachricht, wenn es um den Datenschutz ging, sondern nur um den Inhalt. AFAIK, es ist im Allgemeinen nicht möglich, die Empfänger einer E-Mail zu verbergen, es sei denn, sie kann über nicht protokollierende Proxys weitergeleitet werden. Wenn Ihre Nachricht so geheim ist, dass Sie sowohl die Empfänger als auch den Inhalt maskieren müssen, müssen Sie einen anderen Kommunikationsmechanismus finden.
afrazier

2
Ich war bis zum letzten Satz bei Piskvor. Wenn Sie nur Empfänger voneinander verbergen möchten, benötigen Sie lediglich einen Mail-Client, der alle BCCs einzeln senden kann.
Steve Bennett

@afrazier: Hätte ich noch keine konkurrierende Antwort hinzugefügt, hätte ich diese abgelehnt, weil ich die Frage des OP nicht beantwortet habe.
Blrfl

1
BCC-Empfänger werden nicht im E-Mail-Header erfasst (außer bei sehr alten und defekten MTAs). Ein Standard-Mailserver überprüft nicht einmal die Kopfzeile, sondern verwendet nur den Umschlag, um zu entscheiden, wohin E-Mails gesendet werden sollen.
Adrian Pronk

13

Jeder Mail Transfer Agent (MTA), der RFC 2822 vollständig erfüllt (insbesondere Abschnitt 3.6.3, Zieladressfelder ), entfernt das Bcc:Feld aus der Kopfzeile, bevor die Zustellung versucht wird, sodass die nicht blinden Empfänger die blinden Empfänger nicht ermitteln können 'Identitäten.

Es gibt ein paar Fänge:

  • Wenn Sie nicht die Kontrolle über den allerersten MTA haben, den Ihre ausgehenden E-Mails erreichen, können Sie nicht garantieren, dass die Software auf diesem MTA den Anweisungen von RFC 2822 entspricht.

  • Die Tatsache, dass eine E-Mail von Ihnen an einen Empfänger, der möglicherweise blind kopiert wurde, einen oder mehrere MTAs durchlaufen hat, kann in den Protokollen dieser MTAs überleben.


1
Hervorragende Antwort speziell für die Frage "Niemand von Empfängern wird jemals E-Mails [Adressen] in BCC sehen". Sie können testen, wie Ihr erster MTA mit BCC-Headern umgeht, indem Sie eine E-Mail an einen E-Mail-Antwort-Bot senden, der die Header Ihrer E-Mail zurückgibt.
Sabre23t

Der MTA soll nicht einmal den Bcc:Header sehen. Stattdessen sollte der MUA (Mail-Client-Programm) alle Adressen im SMTP-Umschlag ( MAIL FROM) angeben .
Grawity

Dieser Trick funktioniert nicht in allen Fällen, da die Standards nicht vorschreiben, dass die Zustellung etwas durchläuft, das eine Empfängeradresse außerhalb der Header erhalten kann. MTP existierte erst sechs Jahre nach der ersten Definition des BCC-Verhaltens (RFC 680, 1975). SMTP kam ein Jahr später.
Blrfl

5

Sie sollten niemals davon ausgehen, dass die Empfänger nicht auf den BCC-Empfänger aufmerksam werden. BCC-Empfänger haben in ihrem E-Mail-Programm auf "Allen antworten" geklickt und zuvor jedem den Empfang einer E-Mail angekündigt, ohne zu verstehen, was BCC tatsächlich bedeutet. Wenn es wirklich privat sein soll, leiten Sie die Nachricht aus Ihrem Ordner "Gesendet" weiter, nachdem Sie sie an die ursprünglichen Empfänger gesendet haben. Die einzige andere Adresse in den Nachrichtenköpfen ist Ihre.

Das heißt, selbst wenn Sie BCC verwenden, hätte der Server des Empfängers keinen Zugriff auf die BCC-Informationen, solange der Server des Empfängers vom ursprünglichen Empfänger getrennt ist, da er entfernt worden wäre (oder wahrscheinlicher nie in der Liste enthalten gewesen wäre) Nachrichtentext) vom Mailserver Ihres Providers.

Nebenbei bemerkt: SMTP ist weder zuverlässig noch besonders privat. Einige Poster behaupten, dass SMTP-Serverketten existieren, aber im Allgemeinen sendet SMTP von Ihrem Computer an Ihren ISP und an den Empfänger-ISP. (und wie viele Server sie auch intern haben) Im Allgemeinen werden Ihre E-Mails NICHT an den E-Mail-Server eines Drittanbieters weitergeleitet, und solche Versuche werden im Allgemeinen aus Gründen der Spam-Abwehr abgelehnt. (Es gibt Ausnahmen, da kleine Anbieter und Heimnetzwerke an ihren Anbieter weiterleiten, aber dies ist die Ausnahme, nicht die Regel.)

Die Verschlüsselung von E-Mails während des Transports kann jedoch nicht garantiert werden, und potenziell sensible Daten sollten nicht unverschlüsselt über JEDE Methode an das Internet übertragen werden, einschließlich E-Mails, da dies für große Anbieter oder Telekommunikationsunternehmen kein Problem ist ihre Einrichtungen oder Protokollpakete, die über ihre Router übertragen werden.

Das FBI tut dies regelmäßig über die Carnivore-Programme und andere Programme, und es wurden auch in der Vergangenheit Rogue-Elemente dokumentiert.


1
I've had BCCed recipients hit "Reply All" in their mail program Das ist mir noch nie passiert, aber ich habe es schon oft gesehen. Dein Rat (nicht Bcc, sondern nach dem Absenden weiterleiten) ist genau das, was ich auch tue. Ich mag es nicht, wie ein arroganter Idiot zu klingen, aber manchmal muss man die Menschen vor sich selbst schützen.
Dan7119

@ Dan7119 Lass mich raten .. bist du / warst du auch ein Sysadmin?
SplinterReality

Gute Antwort. Selbst wenn das Entfernen von BCC-Informationen zu 100% zuverlässig ist, kann der menschliche Faktor BCCed recipients hit "Reply All"nicht als zuverlässig garantiert werden. Ich stimme forward the message from your Sent folderinsbesondere für technisch nicht versierte BCC-Empfänger wie CEOs zu.
Sabre23t

1

Ihr E-Mail-Client oder -Server (weiß nicht, welcher) sollte die BCC-Informationen entfernen, bevor Sie eine Nachricht senden. Wenn Sie eine Nachricht selbst als BCC speichern und dann die Quelle anzeigen, sollten Sie Ihre E-Mail-Adresse nur in der Von-Zeile finden (dies wurde mit meiner eigenen E-Mail-Adresse überprüft).


Vielen Dank. Aber meine Frage ist eigentlich tiefer und dreht sich um Zuverlässigkeit und Sicherheit. Nicht so, wie es theoretisch sein soll.
QWERTY

Soweit ich weiß, können Sie anhand einer E-Mail feststellen, ob die Theorie mit der Praxis übereinstimmt, indem Sie sich die BCC-Adresse anzeigen lassen.
zpletan

Ihr E-Mail-Client entfernt keine BCC-Informationen. Das ergibt keinen Sinn.
Steve Bennett

1

Es hängt alles vom Server ab. Die meisten Server verwenden die BCC-Leitung und senden die Nachricht grundsätzlich einmal pro Adresse. im grunde die bcc adresse in die cc zeile sende, die nächste adresse in die cc zeile und sende den typ thing. Aber es hängt alles vom MAIL-Server-Setup ab. BCC sollte niemals weiter gehen als auf Ihrem Postausgangsserver.


7
Falsch in drei Punkten. Erstens sind es MUAs, nicht SMTP-Server, die sich mit Bcc:Headern befassen . Wenn die Nachrichten einen SMTP-Server erreichen, befinden sich die Empfängeradressen im Nachrichtenumschlag und nicht in den Kopfzeilen. Zweitens nur SMTP - Submission - Server jemals solche Header an erster Stelle neu zu schreiben. Drittens werden Nachrichten immer einmal pro Umschlagempfänger gesendet. Das ist nicht besonders oder anders.
JdeBP

1

Alles, was ohne digitale Signatur oder Verschlüsselung im Internet unterwegs ist, kann problemlos geändert werden. Wenn Sie eine End-to-End-Integrität für E-Mails benötigen, verwenden Sie die PGP / GPG-Signatur.

Außerdem müssen Sie Ihren öffentlichen PGP / GPG-Schlüssel irgendwie an die Empfänger übertragen (damit diese überprüfen können, ob Ihre E-Mail-Nachrichten wirklich Ihnen gehören). Die Art von Henne-Ei-Problem: Es geht darum, einen sicheren Kommunikationskanal einzurichten, aber es ist bereits ein sicherer Kommunikationskanal erforderlich. Das Senden per E-Mail ist in Ordnung, Sie müssen jedoch den Fingerabdruck des PGP / GPG-Schlüssels telefonisch oder auf andere Weise überprüfen. Die Veröffentlichung auf einer https-fähigen Website ist ebenfalls eine gute Idee, da SSL die erforderlichen Garantien für die Integrität des Transports bietet.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.