11
E-Mail BCC anzeigen
Hallo
Bis heute Abend habe ich mich betreffend des E-Mail bcc Feldes auf die RFC 2822 Definition verlassen. D.H. kein Empfänger (nicht der Sender!) kann eine E-Mailadresse, die im "bcc" Feld war, sehen.
In einer Diskussion sind wir über eine Aussage des WP Artikels zu "E-Mail Header" stutzig geworden.
Dort steht folgender Abschnitt:
A: Wie der erste Satz korrekt festhält, wird das BBC Feld nicht übermittelt
B: Der verschachtelte Satz "Durch die entfernte BBC-Zeile..." verstehe ich als Aussage, dass es Funktionen in E-Mail Programmen geben soll, welche BCC anzeigen. Das halte ich für falsch. Was nicht im Header steht, kann nicht übermittelt werden.
C: Der englische Text dieses Absatzes ist ebenso schwammig:
"not usually listed in the message header" ? D.h. am Freitag den 13. sind sie doch dabei?
Wenn sich die E-Mail Infrastruktur hält, dann sind BCC nicht im Header - IMHO.
Wir haben mit Outlook 2021 herum gespielt und konnten keine BCC Empfänger sehen.
Einer der Testcases war:
Ich sende eine E-Mail an einen "to" und zwei "bcc".
Ich öffne als bcc empfänger die email und klicke auf "Antworten an alle"
Der zweite bbc empfänger wurde nicht angezeigt
Danach habe ich den Zustellbericht des Mails anzeigen lassen.
Der zweite bcc war nicht aufgeführt
Ich öffne die Mailbox der zweiten bbc Adresse und habe die E-Mail nicht erhalten.
Auf "security.stackexchange.com" Post von 2016 finde ich folgende Erklärung:
Diese Aussage fusst auf diesem Standord Universitäts Whitepaper Correcting Privacy Violations in Blind-Carbon-Copy (BCC) Encrypted Email. Sie zitieren daraus wie folgt:
Den abschliessenden Ratschlag in diesem Exchange Post ist für mich praxis relevant:
Fazit unter dem Strich
Ja - Software kann sich nicht konform verhalten. D.h. in zusätzlichen Informationsfeldern Informationen mitliefern, die in den offiziellen Feldern verboten ist
Nein - ich glaube nicht, dass die grossen E-Mail Infrastrukturen sich so verhalten. Die Tage von OutlookExpress sind vorbei. Der Image Schaden für den Anbieter, wenn das bekannt wird, wäre einfach zu gross.
Im Sinne von "Die Vorsicht ist die Mutter der Porzellankiste" sollte man E-Mails an mehrere bcc Empfänger "einzeln" versenden.
Ja - der Abschnitt von Wikipedia ist falsch und irreführend. In Konsequenz müsste man bei jedem technischen Konzept (z.B. Autobremsen) dazu schreiben, dass bei abweichender bzw. mangelhafter Umsetzung Seiteneffekte auftreten könnten.
Hat jemand eine technisch fundiertes Argument bzw. Gedanken dazu beizutragen?
Beste Grüsse
Bis heute Abend habe ich mich betreffend des E-Mail bcc Feldes auf die RFC 2822 Definition verlassen. D.H. kein Empfänger (nicht der Sender!) kann eine E-Mailadresse, die im "bcc" Feld war, sehen.
In einer Diskussion sind wir über eine Aussage des WP Artikels zu "E-Mail Header" stutzig geworden.
Dort steht folgender Abschnitt:
Die BCC-Zeile wird vor der Übertragung vollständig aus dem Header der E-Mail entfernt. Die Nachricht wird jedoch trotzdem an alle Empfänger übermittelt. Die BCC-Empfänger sehen beim Eingang der E-Mail nicht, dass sie im BCC-Feld geführt wurden (können dies jedoch leicht erkennen, da sie weder im TO-Feld noch im CC-Feld der empfangenen E-Mail stehen). Durch die entfernte BCC-Zeile ist eine (versehentliche) Identifikation mittels der Programmfunktion „Antworten an alle“ nur gegenüber den TO- und CC-Empfängern, nicht jedoch den anderen BCC-Empfängern möglich. In solch einem Fall ist es sinnvoll, explizit auf BCC-Empfänger hinzuweisenA: Wie der erste Satz korrekt festhält, wird das BBC Feld nicht übermittelt
B: Der verschachtelte Satz "Durch die entfernte BBC-Zeile..." verstehe ich als Aussage, dass es Funktionen in E-Mail Programmen geben soll, welche BCC anzeigen. Das halte ich für falsch. Was nicht im Header steht, kann nicht übermittelt werden.
C: Der englische Text dieses Absatzes ist ebenso schwammig:
Bcc: Blind carbon copy; addresses are usually only specified during SMTP delivery, and not usually listed in the message header.Wenn sich die E-Mail Infrastruktur hält, dann sind BCC nicht im Header - IMHO.
Wir haben mit Outlook 2021 herum gespielt und konnten keine BCC Empfänger sehen.
Einer der Testcases war:
Ich sende eine E-Mail an einen "to" und zwei "bcc".
Ich öffne als bcc empfänger die email und klicke auf "Antworten an alle"
Der zweite bbc empfänger wurde nicht angezeigt
Danach habe ich den Zustellbericht des Mails anzeigen lassen.
Der zweite bcc war nicht aufgeführt
Ich öffne die Mailbox der zweiten bbc Adresse und habe die E-Mail nicht erhalten.
Auf "security.stackexchange.com" Post von 2016 finde ich folgende Erklärung:
Servers often add additional headers to emails during processing. These headers might, as a side effect, inadvertently reveal BCC recipients to everyone elseWe show that many widely deployed email encryption systems reveal the identities of Blind- Carbon-Copy (BCC) recipients. For example, encrypted email sent using Microsoft Outlook completely exposes the identity of every BCC recipient. Additionally, several implementations of PGP expose the full name and email address of BCC recipients.Den abschliessenden Ratschlag in diesem Exchange Post ist für mich praxis relevant:
As an alternative I'd suggest you to send the mail to each BCC recipient individually. If there are many of them, you can use a bulk email plugin for your mail client that will send the mails one by one. Fazit unter dem Strich
Ja - Software kann sich nicht konform verhalten. D.h. in zusätzlichen Informationsfeldern Informationen mitliefern, die in den offiziellen Feldern verboten ist
Nein - ich glaube nicht, dass die grossen E-Mail Infrastrukturen sich so verhalten. Die Tage von OutlookExpress sind vorbei. Der Image Schaden für den Anbieter, wenn das bekannt wird, wäre einfach zu gross.
Im Sinne von "Die Vorsicht ist die Mutter der Porzellankiste" sollte man E-Mails an mehrere bcc Empfänger "einzeln" versenden.
Ja - der Abschnitt von Wikipedia ist falsch und irreführend. In Konsequenz müsste man bei jedem technischen Konzept (z.B. Autobremsen) dazu schreiben, dass bei abweichender bzw. mangelhafter Umsetzung Seiteneffekte auftreten könnten.
Hat jemand eine technisch fundiertes Argument bzw. Gedanken dazu beizutragen?
Beste Grüsse
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3245344995
Url: https://administrator.de/forum/e-mail-bcc-anzeigen-3245344995.html
Ausgedruckt am: 11.04.2025 um 04:04 Uhr
11 Kommentare
Neuester Kommentar
Das Mailrouting ist unabhängig von den Headern in der Mail, bei SMTP (und nur das ist heute noch relevant, oder macht hier jemand UUCP, Bitnet etc.?) ist der Envelope-Recipient relevant, der vom MUA (Outlook, TB) aus To, CC und Bcc generiert wird.
Da gibt es dan viele rcpt to: info@kacke.de in der SMTP-Transaktion.
Auch ohne To, Cc und Bcc kann eine Mail am Ziel ankommen, wenn man per SMTP den rcpt to passend setzt.
Einfach mal per Telnet auf nen SMTP-Sever gehen und eine Mail per Hand verschicken. Nach Data kommt dann die eigentliche Mail samt (oder auch ohne) To, CC usw.).
Da gibt es dan viele rcpt to: info@kacke.de in der SMTP-Transaktion.
Auch ohne To, Cc und Bcc kann eine Mail am Ziel ankommen, wenn man per SMTP den rcpt to passend setzt.
Einfach mal per Telnet auf nen SMTP-Sever gehen und eine Mail per Hand verschicken. Nach Data kommt dann die eigentliche Mail samt (oder auch ohne) To, CC usw.).
1
Hallo,
der Wikipedia-Artikel meint lediglich, dass sich ein BCC-Empfänger selbst "enttarnen" kann, also eine Selbstverständlichkeit:
Er bekommt eine E-Mail, ohne ausdrücklich zu sehen, dass er ein BCC-Empfänger ist, weil die eben nicht angezeigt werden (vielmehr müsste er es daraus folgern, weder TO- noch CC-Empfänger zu sein). Wenn er nun an alle antwortet, gibt er sich gegenüber den TO- und CC-Empfängern als BCC-Empfänger zu erkennen; nicht aber gegenüber anderen BCC-Empfängern, weil die auch nicht angezeigt werden und die Antwort also auch nicht erhalten.
Grüße
Richard
der Wikipedia-Artikel meint lediglich, dass sich ein BCC-Empfänger selbst "enttarnen" kann, also eine Selbstverständlichkeit:
Er bekommt eine E-Mail, ohne ausdrücklich zu sehen, dass er ein BCC-Empfänger ist, weil die eben nicht angezeigt werden (vielmehr müsste er es daraus folgern, weder TO- noch CC-Empfänger zu sein). Wenn er nun an alle antwortet, gibt er sich gegenüber den TO- und CC-Empfängern als BCC-Empfänger zu erkennen; nicht aber gegenüber anderen BCC-Empfängern, weil die auch nicht angezeigt werden und die Antwort also auch nicht erhalten.
Grüße
Richard
1
Viel gezetere um nichts. Bisher hab ich (du anscheinend auch) keine SW gesehen, die BCC übermittelt. Wenn aber, wie CRS sagt, der BCC allen antwortet offenbart er sich natürlich.
Hi,
was ist denn jetzt deine Frage?
Gruß
Drohnald
was ist denn jetzt deine Frage?
Ja - der Abschnitt von Wikipedia ist falsch und irreführend.
Naja 2 Sätze vor deinem Zitat steht dortDie Handhabung der BCC-Zeile ist aber nicht eindeutig vorgegeben.
und am Ende des Abschnittes:Auch wenn E-Mail-Programme und Server üblicherweise nach der ersten Variante vorgehen, sollte man sich im Zweifelsfall nicht darauf verlassen.
Würde ich weder als falsch noch irreführend bezeichnen.In Konsequenz müsste man bei jedem technischen Konzept (z.B. Autobremsen) dazu schreiben, dass bei abweichender bzw. mangelhafter Umsetzung Seiteneffekte auftreten könnten.
Das würde ich als gesunden Menschenverstand bezeichnen.Gruß
Drohnald
- Mir ist noch kein SMTP-Client und/oder -Server aufgefallen, der die Mailadressen im BCC überträgt.
- Bei verschlüsselten Mails liegt's an der Technik. Sowohl S/MIME als auch PGP arbeiten mit öffentlichen Schlüsseln, die einer Mailadresse zugeordnet sind. Die Mailadresse kann dann in den Metadaten der verschlüsselten Daten auftauchen. Es kommt in freier Wildbahn allerdings selten vor, dass verschlüsselte Mails an große BCC-Listen versendet werden, weil für alle Empfänger einer BCC-Liste ein gültiger, öffentlicher Schlüssel vorliegen muss. Irgendein Schlüssel ist da immer abgelaufen und der Versand wird dann vom Mailclient verweigert.
- Die Erklärung von Wikipedia ist etwas verkorkst formuliert, aber korrekt. Die Übersetzung in "einfach" lautet: Bei "TO" und "CC" sehen alle anderen die Mailadresse, bei "BCC" nicht. Wenn man will, dass andere Mailempfänger wissen, an wen die Mail noch ging, müsste man das in der eigentlichen Mail extra erwähnen.
- Bei verschlüsselten Mails liegt's an der Technik. Sowohl S/MIME als auch PGP arbeiten mit öffentlichen Schlüsseln, die einer Mailadresse zugeordnet sind. Die Mailadresse kann dann in den Metadaten der verschlüsselten Daten auftauchen. Es kommt in freier Wildbahn allerdings selten vor, dass verschlüsselte Mails an große BCC-Listen versendet werden, weil für alle Empfänger einer BCC-Liste ein gültiger, öffentlicher Schlüssel vorliegen muss. Irgendein Schlüssel ist da immer abgelaufen und der Versand wird dann vom Mailclient verweigert.
- Die Erklärung von Wikipedia ist etwas verkorkst formuliert, aber korrekt. Die Übersetzung in "einfach" lautet: Bei "TO" und "CC" sehen alle anderen die Mailadresse, bei "BCC" nicht. Wenn man will, dass andere Mailempfänger wissen, an wen die Mail noch ging, müsste man das in der eigentlichen Mail extra erwähnen.
1
Zitat von @137960:
- Mir ist noch kein SMTP-Client und/oder -Server aufgefallen, der die Mailadressen im BCC überträgt.
- Mir ist noch kein SMTP-Client und/oder -Server aufgefallen, der die Mailadressen im BCC überträgt.
/me 2
- Bei verschlüsselten Mails liegt's an der Technik. Sowohl S/MIME als auch PGP arbeiten mit öffentlichen Schlüsseln, die einer Mailadresse zugeordnet sind. Die Mailadresse kann dann in den Metadaten der verschlüsselten Daten auftauchen. Es kommt in freier Wildbahn allerdings selten vor, dass verschlüsselte Mails an große BCC-Listen versendet werden, weil für alle Empfänger einer BCC-Liste ein gültiger, öffentlicher Schlüssel vorliegen muss. Irgendein Schlüssel ist da immer abgelaufen und der Versand wird dann vom Mailclient verweigert.
Kann ich bestätigen.
i.d.R. ist es also so, daß wenn alle MUAs und MTAs korrekt arbeiten, keiner sieht, wer in den BCCs ist.
lks
1
Hallo Drohnald
Das die BCC nicht sicher sei, bzw. nicht funktioniert wird wiederholt behauptet.
Eine "Urban Legend".
BCC funktioniert. Das man es falsch bedienen (antworten als BCC Empfänger) bzw. das eine fatale Implementation ev. den Mechanismus unterläuft, ist doch völlig klar. GMV wie ein anderer Teilnehmer geschrieben hat.
BCC ist sicher. So sicher wie jedes vergleichbare technische Konstrukt mit einer vergleichbaren Zahl an Variablen.
Beste Grüsse
Das die BCC nicht sicher sei, bzw. nicht funktioniert wird wiederholt behauptet.
Eine "Urban Legend".
BCC funktioniert. Das man es falsch bedienen (antworten als BCC Empfänger) bzw. das eine fatale Implementation ev. den Mechanismus unterläuft, ist doch völlig klar. GMV wie ein anderer Teilnehmer geschrieben hat.
BCC ist sicher. So sicher wie jedes vergleichbare technische Konstrukt mit einer vergleichbaren Zahl an Variablen.
Beste Grüsse
Moin,
also wie gesagt sind die Felder TO, CC (SMTP Header) eigentlich nur Kosmetik für das E-Mail-Programm. Da kann alles drin stehen. Wichtig für das Mailrouting sind die SMTP-Envelope Daten, wie vom Kollege @Windows10Gegner schon gesagt.
"Wenn Sie aber genau aufgepasst haben, dann ist eine gewisse Information doppelt: Sowohl im Header als auch im Envelope sind Daten über den Absender und Empfänger enthalten. Wenn Sie nun glauben, dass dies "doppelt" ist, dann irren Sie, denn es gibt hierfür einen Gründe: Die Informationen im Envelope dienen den Mailservern (SMTP-Server) dazu, die Nachrichten zu routen. Die Informationen im Header dienen der Anzeige beim Anwender."
Quelle und gute ausführende Infos: https://www.msxfaq.de/internet/envelope.htm
@PeterGyger: Ich lese hier sehr gerne von Dir ! Du machst Dir oft einen Kopf über eigentlich banale Dinge, die dann aber doch oft komplizierter sind, als man denkt. Da kann man sich echt tief vergraben, um zu verstehen, wie es funktioniert. Das kenne ich auch von mir.
Trommel
also wie gesagt sind die Felder TO, CC (SMTP Header) eigentlich nur Kosmetik für das E-Mail-Programm. Da kann alles drin stehen. Wichtig für das Mailrouting sind die SMTP-Envelope Daten, wie vom Kollege @Windows10Gegner schon gesagt.
"Wenn Sie aber genau aufgepasst haben, dann ist eine gewisse Information doppelt: Sowohl im Header als auch im Envelope sind Daten über den Absender und Empfänger enthalten. Wenn Sie nun glauben, dass dies "doppelt" ist, dann irren Sie, denn es gibt hierfür einen Gründe: Die Informationen im Envelope dienen den Mailservern (SMTP-Server) dazu, die Nachrichten zu routen. Die Informationen im Header dienen der Anzeige beim Anwender."
Quelle und gute ausführende Infos: https://www.msxfaq.de/internet/envelope.htm
@PeterGyger: Ich lese hier sehr gerne von Dir ! Du machst Dir oft einen Kopf über eigentlich banale Dinge, die dann aber doch oft komplizierter sind, als man denkt. Da kann man sich echt tief vergraben, um zu verstehen, wie es funktioniert. Das kenne ich auch von mir.
Trommel
Vor allem können die Daten im Envelope anders als die im Header sein. Ist zwar für Filter auffällig, interessiert aber ein MUA oder einen MTA nicht die Bohne.
Zitat von @Windows10Gegner:
Vor allem können die Daten im Envelope anders als die im Header sein. Ist zwar für Filter auffällig, interessiert aber ein MUA oder einen MTA nicht die Bohne.
Vor allem können die Daten im Envelope anders als die im Header sein. Ist zwar für Filter auffällig, interessiert aber ein MUA oder einen MTA nicht die Bohne.
Guten Abend
Wie Trommel so treffend festhält, wenn ich mal an einem Thema dran bin, dann versuche ich dort auch ein bisschen Erkenntnis zu gewinnen.
https://www.msxfaq.de/internet/envelope.htm kenne ich gut. Dort habe ich bereits viele informative Artikel gelesen. Lese ich asap. Vorgreifend und vorwitzig dennoch folgende "Frage":
Aussage1: "st der Envelope-Recipient relevant, der vom MUA (Outlook, TB) aus To, CC und Bcc generiert wird"
Aussage2: "Auch ohne To, Cc und Bcc kann eine Mail am Ziel ankommen... Telnet"
Frage1: "Weshalb sehe ich oben einen Widerspruch?"
Frage2: D.h. ich kann mit Telnet eine E-Mail ohne Absender an jemanden schicken? Vorausgesetzt kein nervöser Mailserver fängt es ab, da der Header fehlt.
Frage3: D.h. es ist lediglich eine Frage, mit welchem Protokoll der Sender mit dem SMTP Server spricht, ob ein Mail Header generiert wird?
Frage4: In welchen RFC kann ich Deine Aussagen referenzieren?
Frage5: Einen Schritt zurück. Meine Kernaussage war, dass das Geraune um BCC welche auf irgendwelche Umstände aus einem gesendeten E-Mail (nicht der Use Case das der BCC Empfänger antwortet) die unter BCC gesendeten Empfänger ausgelesen werden können, ist falsch. Nicht wahr.
Danke für Eure beharrliche Geduld.
Beste Grüsse
Zitat von @PeterGyger:
Guten Abend
Wie Trommel so treffend festhält, wenn ich mal an einem Thema dran bin, dann versuche ich dort auch ein bisschen Erkenntnis zu gewinnen.
https://www.msxfaq.de/internet/envelope.htm kenne ich gut. Dort habe ich bereits viele informative Artikel gelesen. Lese ich asap. Vorgreifend und vorwitzig dennoch folgende "Frage":
Aussage1: "st der Envelope-Recipient relevant, der vom MUA (Outlook, TB) aus To, CC und Bcc generiert wird"
Ist der Standardfall, man kann aber einen Env-Recpt ohne passende Mail-Header setzen und die Mail kommt an (ist u.a. beim Bcc der Fall).Zitat von @Windows10Gegner:
Vor allem können die Daten im Envelope anders als die im Header sein. Ist zwar für Filter auffällig, interessiert aber ein MUA oder einen MTA nicht die Bohne.
Vor allem können die Daten im Envelope anders als die im Header sein. Ist zwar für Filter auffällig, interessiert aber ein MUA oder einen MTA nicht die Bohne.
Guten Abend
Wie Trommel so treffend festhält, wenn ich mal an einem Thema dran bin, dann versuche ich dort auch ein bisschen Erkenntnis zu gewinnen.
https://www.msxfaq.de/internet/envelope.htm kenne ich gut. Dort habe ich bereits viele informative Artikel gelesen. Lese ich asap. Vorgreifend und vorwitzig dennoch folgende "Frage":
Aussage1: "st der Envelope-Recipient relevant, der vom MUA (Outlook, TB) aus To, CC und Bcc generiert wird"
Aussage2: "Auch ohne To, Cc und Bcc kann eine Mail am Ziel ankommen... Telnet"
Richtig, das manuell über Telnet zu machen ist eine Option.
Frage1: "Weshalb sehe ich oben einen Widerspruch?"
Musst du uns sagen, es gibt keinen.
Frage2: D.h. ich kann mit Telnet eine E-Mail ohne Absender an jemanden schicken? Vorausgesetzt kein nervöser Mailserver fängt es ab, da der Header fehlt.
Ohne mail from: wird zumindest sendmail in der Standardkonfiguration meckern, aber man kann den leer lassen. Header sind für die SMTP-Sitzung nicht relevant, die werden wie Nutzdaten behandelt.
Frage3: D.h. es ist lediglich eine Frage, mit welchem Protokoll der Sender mit dem SMTP Server spricht, ob ein Mail Header generiert wird?
Mit einem SMTP-Server kann man nur SMTP sprechen. Die Header der Mail werden da als Nutzdaten übertragen und interessieren einen MTA nicht (natürlich kann man da filtern).
Frage4: In welchen RFC kann ich Deine Aussagen referenzieren?
https://datatracker.ietf.org/doc/html/rfc5321Frage5: Einen Schritt zurück. Meine Kernaussage war, dass das Geraune um BCC welche auf irgendwelche Umstände aus einem gesendeten E-Mail (nicht der Use Case das der BCC Empfänger antwortet) die unter BCC gesendeten Empfänger ausgelesen werden können, ist falsch. Nicht wahr.
Wir gehen vom Standardfall aus.
Der Bcc-Header in den Nutzdaten wird entfernt, die Empfänger werden aber im Envelope-Rcpt übertragen (sonst kommen keine Mails da an). Anhand der Header der Mail kann man nicht rausfinden, wer im Bcc steht. Im To-Header stehen die normalen Empfänger. Die sieht jeder.
Antwortet aber einer der Bcc-Empfänger an alle (oder nur einen Teil der To-Empfänger), so sehen diese, dass der nicht im To steht, aber geantwortet hat (das merkt man an den Referenzen mit der Message-ID, die man nur schwer zufällig erraten kann). Daraus kann man dann schließen, dass die im Bcc standen.
