Diskussion:Header (E-Mail)

Singular oder Plural?

RFC 2822 sagt: A message consists of header fields (collectively called "the header of the message") […]. Gibt es einen Grund, weshalb im Artikel von mehreren Headern (statt Header-Zeilen) pro Mail gesprochen wird?--Gunther 14:13, 5. Dez 2005 (CET)

Schreib-/Mundfaul. Einfach aendern. -- Wikifh 16:36, 5. Dez 2005 (CET)

Wenn ich mich richtig erinnere wird, wenn eine Mail aus mehreren Teilen (z.B. Text + Anhang) besteht, für jeden Teil ein eigener Header angelegt. --84.176.150.201 15:46, 13. Jan 2006 (CET)

Jein. Es gibt nur einen message header, aber für jeden Teil einen eigenen part header, der von dem hier beschriebenen Header wesentlich abweicht (nur Content-Felder). (Es kann auch eine komplette Mail als Teil einer anderen Mail versandt werden, dann gibt es natürlich auch mehr als einen message header, aber darum geht es nicht.) Details siehe RFC 2045.--Gunther 16:00, 13. Jan 2006 (CET)

To: Der Adressat

Im Artikel steht:

Hier sollte laut Standard nur eine E-Mail-Adresse angegeben werden, an die die E-Mail primär gesendet wird. Moderne E-Mail-Programme und Mailserver unterstützen heutzutage in diesem Feld jedoch beliebig viele durch Kommas getrennte E-Mail-Adressen.

Nach welchem Standard soll nur ein Empfänger im To:-Feld angegeben werden? Laut RFC 2822 enthält das To:-Feld eine Empfängerliste:

to = "To:" address-list CRLF
address-list = (address *("," address)) / obs-addr-list

Mögliche Einträge im Header

"Einträge im E-Mail-Header werden durch einen Zeilenumbruch (CRLF) voneinander getrennt. Der E-Mail-Header wird durch eine Leerzeile (CRLF CRLF) vom E-Mail-Body getrennt."

Stimmt das so? CR/LF Zeilenumbrüche stammen doch aus dem Hause Microsoft, Unix und dessen Abkömmlinge verwenden i.d.R. nur ein einfaches LF. Oder gibt es da eine Ausnahme? Dann wäre eine kurze Erklärung angebracht, um Unklarheiten zu vermeiden.

Habe leider gerade keinen lokalen funktionsfähigen Mailclienten unter Linux (Deb) zur Verfügung, sonst könnte ichs schnell testen... --138.190.15.46

Lies den RFC.--Gunther 12:21, 31. Mai 2006 (CEST)

CRLF CRLF ist keine von MS gepachtete Zeichenfolge. Der Seperator "CRLF" ist halt laut RFC vorgeschrieben. Testen kann man das nicht unbedingt, da einige E-Mail-Clients und -Server den RFC ignorieren.Lehmi 02:58, 1. Jun 2006 (CEST)

RFC habe ich inzwischen gelesen, steht tatsächlich so drin. Gehört jetzt nicht mehr unbedingt zum Thema, aber wie schaut der Header denn aus, wenn man ihn mit vi öffnet? Vor jedem Zeilenumbruch ein "^M"? So, ich halte mich wieder an die goldene Regel "WmkAhemdFh!", keine überstürzte Diskssionen mehr -- 138.190.15.46 11:21, 1. Jun 2006 (CEST)

Also ich kann mit meinem vi keine SMTP-Verbindung direkt anschauen, und nur darauf bezieht sich ja der RFC. Was in /var/spool/mail steht, ist im "default"-mbox-Format, für das in RFC 4155 einfache LF und nicht CRLF vorgeschrieben sind.--Gunther 11:28, 1. Jun 2006 (CEST)

Danke für die schnelle Antwort. Ich bringe Äpfel und Birnen durcheinander... sorry für die ganze Aufregung. -- 138.190.15.46 13:31, 1. Jun 2006 (CEST)

BCC

„Einige Mailserver löschen bei der Übertragung die BCC-Zeile, einige allerdings auch nicht. In letzterem Fall ist bei der Wahl eines E-Mail-Programms darauf zu achten, dass das E-Mail-Programm selbst die BCC-Zeile nicht in den Header schreibt.“ hieß es unter BCC.

Das verstehe ich nicht. Wenn ein Mailserver den BCC-Header nicht löscht, ist das natürlich doof, weil der Sinn von BCC unterwandert wird. Aber wenn das E-Mail-Programm den BCC-Zeile nicht in den Header schreibt, woher weiß dann der Server, an wen die BCCs verschickt werden sollen? -- 195.37.61.3 12:52, 16. Nov. 2006 (CET)

Man muss unterscheiden zwischen E-Mail (RFC 2822) und SMTP (RFC 2821). In RFC 2822 wird u. a. der optionale E-Mail-Header Bcc: definiert. Bei der Übergabe von einem MUA an einen Mail Transfer Agent oder bei der Übertragung per SMTP wird neben der E-Mail (incl. E-Mail-Header) die Empfänger der Nachricht übergeben. In diese Empfänger-Liste werden alle E-Mail-Adressen aus den To:-, Cc:- und Bcc:-Feldern eingetragen. Der Bcc:-Header sollte vor der Weiterleitung entfernt werden. Entweder vom MUA oder MTA. --Fomafix 13:35, 16. Nov. 2006 (CET)

Achso. -- 195.37.61.3 18:10, 20. Nov. 2006 (CET)

Heißt das, dass jeder Mailserver immer alle Empfänger kennt? --147.142.13.27 23:44, 10. Jun. 2009 (CEST)

Nein. Natürlich benötigt jeder Mailserver, der eine E-Mail transportiert, die jeweilige Empfängeradresse. --Fomafix 21:31, 30. Sep. 2009 (CEST)

BCC (un)erlaubt?

Eine Frage, die ich anhand von Recherchen im Netz nicht klären konnte. Nachdem ich in meinem Kurs Internet & Sicherheit auch immer über BCC rede und es empfehle, tauchte nun eine für mich neue Aussage auf, dass allein die Verwendung von BCC rechtlich/gesetzlich verboten sei? Das ist mir neu und bis dato nie untergekommen, ich kanns mir auch nicht plausibel erklären, noch finde ich dazu Hinweise im Netz. Aber eine Schülerin behauptet sicher zu sein, dies von einem Internetfachmann gehört zu haben. Hat hier aus diesen Fachkreisen jemals jemand davon gehört, dass es in der EU, in Deutschland etc. entsprechende Datenschutzrichtlinien, Gesetze oder Ähnliches dazu geben könnte oder in Entwurf ist? Das man BCC letztlich auch für Massenmails verwenden kann und die verboten sind ist bekannt, aber das hat ja nichts mit BCC an sich zu tun, sondern mit dem Werbeinhalt einer Mail bzw. mit dem was der Anwender damit macht. Manche Unternehmer wollen anscheinend auch BCC in ihrem Unternehmen (vielleicht wegen Mobbinggefahr) verbieten aber auch das ist was anderes - oder? Danke für Hinweise - denn sollte es sowas geben, wäre es auch für hier wichtig - oder? --Marcus Tuerner (Diskussion) 16:10, 16. Mai 2012 (CEST)

Das kann ich mir nicht vorstellen. Und in einer Urteilsbegründung des OLG Düsseldorf (http://www.ra-kotz.de/emailspam.htm) steht, dass bspw. Newsletter besser als BCC verschickt werden "sollten". Wer bei Newslettern und Massenmails BCC vergisst, sollte sich schämen (und entschuldigen). --Zahnradzacken (Diskussion) 18:15, 16. Mai 2012 (CEST)

Grundlegend wird die Nutzung von BCC nicht zu verbieten sein - insbesondere, wenn der Absender dies bewußt einsetzt. Daß BCC jedoch für Mobbing mißbraucht werden kann (indem die anderen per BCC direkt informiert werden, wie einer fertiggemacht wird), ist dann ein anderes Thema. Daß sowas firmenintern verboten wird, ist sehr wohl vorstellbar. Daß die Nutzung von BCC ein Gschmäckle haben kann (i.S.v.: ich erzähle es aber auch dem Chef, nur weißt Du aber nicht, daß ich dies tue, da es der Chef per BCC erhält), liegt auf der hand. --ProloSozz (Diskussion) 10:48, 24. Nov. 2020 (CET)

Nochmal BCC

Der Absatz klärt nicht wirklich, wer welche Informationen sieht. Sind BCC-Empfänger für die anderen unsichtbar oder umgekehrt ? Oder hängt dies vom Mailserver ab ? Außerdem sollte man erwähnen, daß die Nutzung von BCC im geschäftlichen e-mail-Verkehr zumindest als unhöflich gilt.

Ich schließe mich an. In der derzeitigen Form wirkt der Absatz inkonsistent und verwirrt mehr als daß er Fragen klären würde. Eine gründliche Überarbeitung wäre schön. --79.211.114.155 17:09, 8. Jan. 2008 (CET)

Speziell der letzte Satz dieses Abschnitts ist schlecht formuliert: "Der Inhalt der BCC-Zeile wird bei der Übertragung entfernt. Personen, welche die E-Mail via BCC bekommen, können sich nicht gegenseitig identifizieren. Allen Empfängern wird aber offengelegt, dass die E-Mail zusätzlich als Blindkopie versendet wurde." Wer sind denn "Allen Empfängern"? Wirklich alle oder alle Bcc-Empfänger? Wie soll denn diese Offenlegung funktionieren? Nach meinem Verständnis und meiner Erfahrung kann man Bcc-Empfänger nur daran erkennen, dass man eine Mail bekommen hat, obwohl man nicht als Adressat genannt ist. Das sagt einem aber noch nicht, ob es auch weitere Bcc-Empfänger gibt. Und "Offenlegung" würde ich das auch nicht nennen, weil das eine "passive Information" ist. Alternativ gäbe es ja nur die Möglichkeit der Verschleierung (Mail auf SMTP-Ebene einzeln an die BCC-Empfänger verschicken und dann die Adresse hinzufügen). --Hauke Laging 18:07, 22. Jul. 2010 (CEST)

BCC unhöflich? Hier wird ganz vergessen, dass BCC bei Mails mit mehreren Adressaten in Zeiten der SPAM-Häufung und Viren eher wichtig oder sogar die einzige Alternative sein sollte. Jedes Mailprogramm, das Mails empfängt, bei dem alle Adressaten in TO oder in CC drinstehen öffnet Tür und Tor der Virenverbreitung. Die Trojaner und Virenprogramme freuen sich über jede Mailadresse, die sie irgendwo finden können und kucken dabei nicht nur im Adressbuch nach sondern nutzen allerliebst die vielen angesammelten CC und TO Adressen aller Mails. Bitte vergesst das nicht! Gerade im Privatbereich werden gerne Rundmails an viele Adressen via TO oder CC geschickt und so sammeln sich überall Mailadressen von einem an, wenn man da mit drin steht, mit denen man nichts zu tun hat und bei denen man nicht weiß, wie deren Schleusen für Virenprogramme offen sind. (Marcus Türner)

BCC steht NIE beim Verfassen einer Email im Header selbiger. Diese Information teilt das Emailprogramm lediglich beim Senden nur dem MTA mit.

Die Mailserver fügen jedoch einen Received-Header hinzu. Manche Mailserver tragen dort auch ein for ... ein. Einige schlecht konfigurierte Mailserver machen dies für alle Sendeziele. Merlissimo 21:42, 30. Sep. 2009 (CEST)

Noch fehlene Header

Falls sich jemand auskennt, kann er ja noch folgende fehlende Zeilen erklären:

Return-path:

Delivery-date:

DomainKey-Signature:

Content-Transfer-Encoding:

Delivered-To:

Envelope-to:

Zur besseren Lesbarkeit sollten die im Abschnitt "weitere Header" genannten Zeilen genau so dargestellt werden wie z. B TO: (nicht signierter Beitrag von 77.128.97.118 (Diskussion | Beiträge) 10:50, 30. Sep. 2009 (CEST))

Datums-Format

Ich fände es nützlich, wenn der Artikel erklären würde, wie das date-Feld aufgebaut ist. -- Digamma 19:51, 4. Jan. 2011 (CET)

Hab ich jetzt mal gemacht. Ed --217.251.206.183 15:36, 30. Nov. 2015 (CET)

Danke. Gruß, --Digamma (Diskussion) 18:36, 30. Nov. 2015 (CET)

Inhalt nicht verständlich und auch kein deutscher Satz?!

Ich verstehe nur Bahnhof, was ist damit gemeint?

Zitat: "Wird diese Adresse vom Mailserver in den Header eingetragen und vom E-Mail-Anbieter Wildcard-Mailadressen unterstützt (z.B. benutzername+beliebig@gmail.com bei Gmail), können Nutzer bei jeder Anmeldung im Internet eine eigene Mailadresse verwenden und den Absender über die von ihm verwendete Ziel-Adresse eindeutig identifizieren (sofern dieser nicht weiß, dass wie im vorangegangenem Gmail-Beispiel alle E-Mail-Adressen eines bestimmten Musters zu einem Konto gehören, und eine andere Adresse verwendet)."--217.29.156.156 09:59, 16. Jun. 2015 (CEST)

Kann ich nur unterstreichen!! Es klingt nach einer interessanten und wichtigen Information, aber die Aussage verschließt sich geradezu dem Verständnis. Mehrere Begriffe werden auch unklar verwendet, insb. die Unterscheidung zw. "Nutzer" und "Absender" im dargestellten Fall. --79.224.214.67 00:09, 25. Nov. 2015 (CET)

PS: Falls sich sonst niemand darum kümmern mag, versuche ich mal in den nä. Tagen, das aufzudröseln. Ed --79.224.214.67 00:15, 25. Nov. 2015 (CET)

Soweit ich sehe, geht es einfach um die Möglichkeit variabler Mailadressen bei (z.B.) Gmail, prinzipiell vergleichbar mit Aliassen. Wird dann eine solche spezifische Adresse von anderen als Zieladresse verwendet, so ist eine eindeutige Zuordnung zum eigenen Mailversand bzw. der Adressbekanntgabe möglich (und damit ggfs. auch die Weitergabe der Mailadresse durch den ursprünglichen Empfänger feststellbar). Das ist nun aber nichts so Spektakuläres. Zum einen lässt sich das auch mit ad hoc erzeugten Aliassen erreichen, zum anderen sind die variablen Adresserweiterungen m.W. eben nur optional, können also zur Verwendung auch entfernt werden (bspw. "benutzername@gmail.com" statt "benutzername+test@gmail.com"), wodurch die spezifische Zuordbarkeit natürlich wieder verloren geht. Dieser letzte Aspekt wird in dem Absatz ja auch erwähnt.

Ich halte den ganzen Abschnitt NACH DEM ERSTEN SATZ (= "Einzig und allein Envelope To ist nicht von außen manipulierbar und gibt stets an, welche E-Mail-Adresse der Absender tatsächlich benutzt hat, um die E-Mail an das jeweilige Postfach zu senden.") daher für verzichtbar, um nicht zu sagen überflüssig.

Die Formulierung dieses Satzes wäre noch zu verbessern (s. nä. Diskussionsbeitrag).

Falls keine Einwände oder anderen Vorschläge kommen, ändere ich das in Kürze.

Ed --217.251.206.183 14:33, 30. Nov. 2015 (CET)

Erledigt. Außerdem den Abschnitt "Sender: Technischer Absender" teilweise neu formuliert, da verbesserungswürdig. Ed --79.224.207.232 20:54, 8. Dez. 2015 (CET)

Inhaltlich falschen Absatz über 'envelope to = nicht manipulierbar' ersetzen durch 'envelope from = manipulierbar'?

Zusätzlich zur obigen Anmerkung über den unverständlichen Satz, die ich unterstütze, ist auch der vorhergehende Absatz m.E. komplett falsch: "Einzig und allein Envelope To ist nicht von außen manipulierbar und gibt stets an, welche E-Mail-Adresse der Absender tatsächlich benutzt hat, um die E-Mail an das jeweilige Postfach zu senden."

Benutzt hat der Absender dazu doch "Envelope From". Und das ist, wie ständig praktiziert, leicht manipulierbar!

Und bei "envelope to" ergibt der Terminus 'Manipulation' wiederum keinen Sinn. (nicht signierter Beitrag von Jhennecke (Diskussion | Beiträge) 18:57, 18. Aug. 2015 (CEST))

Header Pflichtangabe

"Der Header enthält als Pflichtangabe lediglich eine Absenderangabe und das Datum der Erstellung der E-Mail."
Was ich komisch finde ist, das die Ziel-Emailadresse demnach keine Pflichtangabe ist, nach dem obigen Zitat. Aber ohne Ziel-Adresse ist jede Email komplett sinnlos, keine Emailserver würde so eine Email verschicken, und selbst wenn, kein angeschlossener Emailserver würde so eine Email weiterleiten, denn wohin sollte sie auch geschickt werden? Ich frage mich also: ist es wirklich korrekt das die Ziel-Emailadesse kein Header-Pflichtfeld ist? --Rava77 (Diskussion) 18:17, 5. Feb. 2016 (CET)

Ja, da das ist korrekt. Siehe https://tools.ietf.org/html/rfc5322#page-21

Erklärung dazu: RFC 5322 beschreibt den Aufbau einer E-Mail bestehend aus Header und Body. Das ist vergleichbar mit einem Brief bestehend aus Header und Body. Eine E-Mail wird anschließend per SMTP gemäß RFC 5321 an die Empfänger verschickt. Das ist vergleichbar mit dem Eintüten von Kopien des Briefes in Briefumschläge, die dann mit Anschriften der Empfänger versehen werden. Beim Brief wie auch bei E-Mail müssen die Empfänger im Briefkopf nicht mit den Adressen auf den Briefumschlägen übereinstimmen. Es kann also auch eine E-Mail ohne Ziel-E-Mail-Adressen geschrieben werden. --Fomafix (Diskussion) 20:45, 5. Feb. 2016 (CET)

Das wird auf https://tools.ietf.org/html/rfc5322#page-21 nicht weiter erklärt (oder ich war zu dumm es zu finden...), aber heißt das, das in so einem Falle SMTP die To: Angabe (sagen wir es geht an x@example.com ) mit der Email extra "mitgibt" und so die To: Angabe doch in den Header geschrieben wird? Also vom nächsten Email-Server, der sich angesprochen fühlt die Email anzunehmen bevor er diese weiterreicht?

Oder würde in so einem Falle die Email zwar an x@example.com versendet werden (also die Zieladresse-Info, die jeder Email-Server, der die Email weiterreicht nur per SMTP empfängt und nur per SMTP weitergibt, es aber nie in den Header geschrieben wird), der Empfänger hätte dann aber keine Möglichkeit zu erfahren, ob es seine Hauptadresse oder eines seiner Aliase ist, an die die Email ging? (z.B. ob diese stattdessen an x1@example.com oder alias@example.com ging?)

Was besonders im Falle einer Spam-Mail von Belang sein könnte. --Rava77 (Diskussion) 01:03, 6. Feb. 2016 (CET)

In der Tabelle steht zu to, cc und bcc Min number 0.

Deine Überlegungen beziehen sich eher auf die Funktionsweise von SMTP. Dort wird bereits erklärt, dass sich die Adressen aus dem Header und den Adressen in SMTP unterscheiden können. --Fomafix (Diskussion) 20:27, 6. Feb. 2016 (CET)

Einleitung sowie "Darstellung und Anzeige"

Mir fällt auf, dass der zweite Absatz am Anfang doch recht unverständlich wirken kann: "Der Header enthält keine für die technische Zustellung einer E-Mail notwendigen Informationen. Absender und Empfänger werden durch den Envelope Sender und Envelope To angegeben."

Ich schlage die eben geänderte Formulierung vor. (Es ergibt sich allerdings eine minimale Überschneidung mit der Einleitung im Abschnitt "Beispielmail".)

Außerdem füge ich im Abschnitt "Darstellung und Anzeige" eine kurze Info zur Adressangabe ein.

Gruß, Ed --79.224.211.151 15:11, 3. Apr. 2016 (CEST)

Problem mit IP des Senders

So wie ich es ermittelt habe, scheint im E-Mail-Kopf nicht die IP-Adresse des Senders zu stehen! Haben sich die Regeln geändert mit Rücksicht auf den Datenschutz? --GFHund (Diskussion) 12:14, 13. Apr. 2019 (CEST)

Revert vom 2.2.2022

Hallo @Itti, wieso hast du eben meinen Beitrag komm.los zurückgesetzt? WP:WEB empfiehlt die Erwähnung des Websiteanbieters. --80.84.97.179 14:50, 2. Feb. 2022 (CET)

Syntax

Generell finde ich dass der englische Artikel zum Thema um Einiges besser ist. Speziell finde ich, dass das Thema "folding/unfolding" (https://datatracker.ietf.org/doc/html/rfc5322#section-2.2.3) unbedingt erwähnt werden sollte. --Uhw (Diskussion) 14:53, 19. Jul. 2023 (CEST)

Courtesy Copy

Courtesy Copy wird im Artikel ohne Beleg als falsch bezeichnet. Dabei ist es nur eine andere Sichtweise. Carbon Copy klingt an das bei Papier verwendete Kohlepapier an und war möglicherweise die ursprüngliche Idee. Dagegen bezieht sich Courtesy Copy auf den Grund, die Nachricht an die weiteren Empfänger zu senden. Wer mag verbindlich entscheiden, was richtig ist, wenn beides verwendet wird? --Lapp (Diskussion) 08:39, 9. Feb. 2024 (CET)

Die Formulierung im Artikel als "fälschlicherweise benutzt" ist ungünstig. Besser wäre eine neutrale Formulierung wie "entgegen der ursprünglichen Bedeutung" oder ähnliches. --Matthäus Wander 09:24, 9. Feb. 2024 (CET)

Gibt es einen Nachweis dazu, was von wem als "ursprüngliche Bedeutung" gedacht war? Falls es keine sicheren Belege gibt, kann man ja im Artikel beide Deutungen einfach ohne Wertung nebeneinander stehen lassen. --Lapp (Diskussion) 14:23, 12. Feb. 2024 (CET)

"Carbon copy" und "blind carbon copy" wurden von den Schöpfern von E-Mail so definiert. Nachweise finden sich in alten RFCs: RFC 733 ("Blind carbon"), RFC 2076 ("cc = Carbon Copy"). --Matthäus Wander 18:58, 12. Feb. 2024 (CET)