Wer genauere Infos zum Thema haben möchte, möge bitte die RFCs und FAQs konsumieren, z.B. unter
http://home.snafu.de/laura/de.admin.net-abuse.mail.txt Frage 4.
Zitat:
Frage 4:
========
* Wie kommt es, daß ich eine Mail bekomme, wenn in der To:-Zeile
oder Cc:-Zeile gar nicht meine Adresse steht?
A: Hierzu hatte Heiko Schlichting in bln.announce.fub.zedat.d
mit 7ahusp$n6f$1@fu-berlin.de einen Artikel geschrieben, der
das so schön erklärt, daß ich ihn einfach übernehmen möchte:
---- 8 ----
> Ich versteh nicht, warum in meiner Mailbox (...) Emails wie
> die folgende landen. Kann mir das jemand erklären? Meine Adresse
> ist doch gar nicht im Header der Email aufgeführt.
Man unterscheidet bei E-Mail zwischen Envelope und Header. Die
Programme, die die Auslieferung durchführen (*), richten sich
nach der Adresse im Envelope. Dieser wird bei der letzten Zu-
stellung (also dem Anhängen der Mail in Deiner Mailbox) entfernt.
Was Dein Mail-Anzeigeprogramm (**) Dir anzeigt, ist nur der Header.
Er ist zu Deiner Information gedacht, hat aber bei der Auslieferung
keine Rolle gespielt.
Als Vergleich zur normalen Briefpost:
------------------------+-------------------------------------
E-Mail | Briefpost
========================+========================= ============
Envelope-Adresse | Adresse auf dem Umschlag
------------------------+-------------------------------------
Header | Briefkopf auf der ersten Seite
------------------------+-------------------------------------
Der Briefträger orientiert sich auch nicht an den Angaben im
Briefkopf, sondern immer nur an den Angaben auf dem Umschlag.
Genau wie bei der klassischen Briefpost sind folgende Angaben
übrigens leicht fälschbar (***):
- Absender im Envelope
- Adressat und Absender im Header
Wer in Mailinglisten eingetragen ist, wird die Unterscheidung von
Envelope und Header schon gesehen haben. Dort ist nämlich in der
Regel im HEADER der Autor der Nachricht im From und die Mailingliste
im To: eingetragen. In Wirklichkeit lief die Mail aber von dem
Mailinglisten-Verteiler an den Mailinglisten-Teilnehmer. Diese
beiden Adressen stehen im Envelope-Teil, der nach der Auslieferung
nicht mehr sichtbar ist. Manche Transport-Systeme tragen diese
Information aber in den Received:-Zeilen im Header ein, so daß man
das dort ggf. nachlesen kann (...).
Wenn eine Mail nicht zugestellt werden kann, wird die Fehlermeldung
übrigens grundsätzlich an die Absender-Information im Envelope (und
nicht etwa an die Adresse im From:-Header) zurückgeschickt. Wer
jetzt an die Einträge bei Mailinglisten denkt, wird sofort erkennen,
warum das so sein muß.
Wenn sich jemand bei der ZEDAT beklagt, daß seine Mail "verloren"
gegangen ist (nicht beim Empfänger angekommen und keine Fehlermeldung
zurückgekommen), dann liegt es in mehr als 90% der Fälle daran, daß
der Absender sein Programm bezüglich der Envelope-Absenderadresse
falsch konfiguriert hat und eine erzeugte Fehlermeldung daher nicht
richtig zurückgeschickt werden konnte. Das hat der Absender nur nie
bemerkt, weil normale Antworten immer den (meist richtig konfigurierten)
From:-Header verwenden. Wer seine Einträge testen möchte, kann eine
Mail an "echo@fu-berlin.de" schicken. Da sollte nach kurzer Zeit eine
Antwort zurück kommen. Wenn nicht, sind die Einträge vermutlich falsch
und sollten korrigiert werden.
(...)
(*) Message Transfer Agent (MTA) - in der ZEDAT heißt das Programm
"smail", ein häufiger Vertreter dieser Art ist auch das Programm
"sendmail".
(**) Mail User Agent (MUA) - dazu gehören pine, mutt, elm, Netscape,
Outlook Express, Eudora, Pegasus, Agent u.v.a.m.
(***) Das Versenden gefälschter Mail von einem FU-Account aus könnte
ggf. zur Sperrung der Nutzerkennung führen. Leicht fälschbar
bedeutet nicht, daß dieses mit geeigneten Zugriffsrechten nicht
nachvollziehbar wäre.
(...)
---- 8 ----
Neben dem erwähnten "Envelope" gibt es noch eine weitere Möglichkeit,
wieso man sich selbst nicht in "To:" oder "Cc:" sehen kann, aber eine
Mail dennoch bekommen hat:
Das Header-Feld "Bcc:" (Blind Carbon Copy).
Aus RFC 2822:
3.6.3. Destination address fields
(...)
The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
addresses of recipients of the message whose addresses are not to be
revealed to other recipients of the message. There are three ways in
which the "Bcc:" field is used. In the first case, when a message
containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
removed even though all of the recipients (including those specified
in the "Bcc:" field) are sent a copy of the message. In the second
case, recipients specified in the "To:" and "Cc:" lines each are sent
a copy of the message with the "Bcc:" line removed as above, but the
recipients on the "Bcc:" line get a separate copy of the message
containing a "Bcc:" line. (When there are multiple recipient
addresses in the "Bcc:" field, some implementations actually send a
separate copy of the message to each recipient with a "Bcc:"
containing only the address of that particular recipient.) Finally,
since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
sent without any addresses indicating to the recipients that blind
copies were sent to someone. Which method to use with "Bcc:" fields
is implementation dependent, but refer to the "Security
Considerations" section of this document for a discussion of each.
Deutschsprachige Ausführungen zum Thema "Bcc" (von Matthias Opatz):
* Das Geheimnis der »blinden Durchschläge«
http://www.trollpress.de/bcc/