petergyger
Goto Top

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:

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 hinzuweisen

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:
Bcc: Blind carbon copy; addresses are usually only specified during SMTP delivery, and not usually listed in the message header.
"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:
Servers often add additional headers to emails during processing. These headers might, as a side effect, inadvertently reveal BCC recipients to everyone else
Diese Aussage fusst auf diesem Standord Universitäts Whitepaper Correcting Privacy Violations in Blind-Carbon-Copy (BCC) Encrypted Email. Sie zitieren daraus wie folgt:
We 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

Content-Key: 3245344995

Url: https://administrator.de/contentid/3245344995

Ausgedruckt am: 19.03.2024 um 04:03 Uhr

Mitglied: Windows10Gegner
Windows10Gegner 03.07.2022 um 19:54:27 Uhr
Goto Top
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.).
Mitglied: C.R.S.
C.R.S. 03.07.2022 um 20:38:46 Uhr
Goto Top
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
Mitglied: Mystery-at-min
Mystery-at-min 03.07.2022 um 21:04:55 Uhr
Goto Top
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.
Mitglied: Drohnald
Drohnald 03.07.2022 um 21:42:00 Uhr
Goto Top
Hi,

was ist denn jetzt deine Frage?

Ja - der Abschnitt von Wikipedia ist falsch und irreführend.
Naja 2 Sätze vor deinem Zitat steht dort
Die 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
Mitglied: 137960
137960 04.07.2022 um 12:53:26 Uhr
Goto Top
- 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.
Mitglied: Lochkartenstanzer
Lochkartenstanzer 04.07.2022 um 15:32:55 Uhr
Goto Top
Zitat von @137960:

- 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
Mitglied: PeterGyger
PeterGyger 06.07.2022 um 10:12:01 Uhr
Goto Top
Zitat von @Drohnald:

Hi,

was ist denn jetzt deine Frage?

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
Mitglied: Trommel
Lösung Trommel 07.07.2022 um 17:22:42 Uhr
Goto Top
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
Mitglied: Windows10Gegner
Windows10Gegner 07.07.2022 um 17:31:04 Uhr
Goto Top
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.
Mitglied: PeterGyger
PeterGyger 07.07.2022 um 20:13:39 Uhr
Goto Top
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.

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
Mitglied: Windows10Gegner
Windows10Gegner 07.07.2022 um 21:00:32 Uhr
Goto Top
Zitat von @PeterGyger:

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.

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).
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/rfc5321
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.

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.