it-swarm.com.de

Wie habe ich diese E-Mail ohne ein "An" -Feld erhalten?

Ich habe eine leere E-Mail in meiner Sprache (Hebräisch) mit nur einem Titel erhalten, der in I am still waiting for your feedback Übersetzt werden kann (Original: עדיין מחכה למשוב שלך)

Da mein Google Mail-Konto mehrere Konten verwaltet (nach Weiterleitung und nach Benutzer\Pass), habe ich versucht, herauszufinden, welches Konto das Ziel war, und zu meiner Überraschung - Keine!

(Strange email without To

Meine Frage ist einfach: Warum hat Google Mail diese E-Mail in meinen Posteingang gestellt? Im Anhang unten finden Sie die vollständige Quelle der E-Mail (aus Google Mail) außer meiner zensierten E-Mail. Wie ist dies keine Sicherheitsverletzung, die durch Spam-Filter gestoppt wird ?


Originale Nachricht:

  • Nachrichten-ID <[email protected]>
  • Erstellt am: Di, 16. Januar 2018 um 2:54 PM (Lieferung nach 2 Sekunden)
  • Von: joseph andrew Mit Mail.Ru Mailer 1.0
  • Zu:
  • Betreff: עדיין מחכה למשוב שלך
  • SPF: PASS mit IP 217.69.138.160 Weitere Informationen
  • DKIM: 'PASS' mit Domain bk.ru Erfahren Sie mehr
  • DMARC: 'PASS' Erfahren Sie mehr
Delivered-To: ****<cencored>****@gmail.com
Received: by 10.2.76.217 with SMTP id q86csp4037724jad;
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
X-Google-Smtp-Source: ACJfBotHqXkzj6W7Gd+8IjEmxrwG9SqXBSC+QiTqyAB1j2Dt4ASXtmXr5UpqIpdU7Mge/EFmnzVI
X-Received: by 10.46.101.207 with SMTP id e76mr192303ljf.115.1516107261904;
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1516107261; cv=none;
        d=google.com; s=arc-20160816;
        b=O+SDwmDS2Y7Jxi+mhwkV/+svfXK0KI3VvepeQgBpyhlgYY5gK3wln+RC4YPO+MMn71
         tyrGBUoc1iGKpeGcilWAovf0XLceJY+EAGoMX4Hl4Pse8C5mWiP0DJQXfmolB5myOFD/
         EoSl7Km4KDcQsvSC0DGwcni1yUPjgiQr+KIY+y19WCqVfm5EtCkbYkUCnFP1RWh/BUBp
         YZHKJrRYH/gWsSqBuIm/fDuSFk4bYAFaCOfkq5LfJcnkf7lpRFBnNYseignqwnnYMEzB
         aScqj1ppvCoYLbBuEiw+yLo1iQLoNdXwGOLShsGXELxkpdFpmchOEV44Wx2vp+RlJMF0
         v1/A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:message-id:reply-to:date:mime-version
         :subject:from:dkim-signature:arc-authentication-results;
        bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
        b=IPjf/U3N1a7Dx8HIw59iWKeccU4mS7Bd0Iy2FY/Be4Mx4QATd8uBvH7pLOVOLHRAXj
         iATzKUy69ZyLgu6gJVc+yjW3+i740O9ccPNbWAPQQASX1H9OkiMsmlhNYOU5u4KDKfbj
         nNm77TeMxrF57z4XKpbO3iE4YEv6JFankI949HvLnehC7wPP5M5YHpS8CllmV3zP8RX4
         2kb14n4PzguduwYoHL3q7wwWHHnyPUsa3UuhCKLvNJYw4KWKLWNY6Kt7fwReb83T+OsG
         lavZ7huDrCcf0P8Ee7YGepcNpGFyh2WjpA4o7l+gAlnqsb6+5FZloH6j7cmQx/gA+gKh
         aVng==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass [email protected] header.s=mail header.b=kgyoMcic;
       spf=pass (google.com: domain of [email protected] designates 217.69.138.160 as permitted sender)
       [email protected];
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bk.ru
Return-Path: <[email protected]>
Received: from f493.i.mail.ru (f493.i.mail.ru. [217.69.138.160])
        by mx.google.com with ESMTPS id 1si926950ljd.480.2018.01.16.04.54.21
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
Received-SPF: pass (google.com: domain of [email protected] designates 217.69.138.160 as permitted sender) client-ip=217.69.138.160;
Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=mail header.b=kgyoMcic;
       spf=pass (google.com: domain of [email protected] designates 217.69.138.160 as permitted sender)
       [email protected];
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bk.ru
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bk.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:From;bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=kgyoMcicHiqU/OvYmq/2sQYQ3607jIk9ZHkh3oVDZTrA6cWDxLGvol37xuQ3L0mfrqIOpSTYHuJzssIjww+4FL/h/GwBRRO1AsuLgxyjSQaOLVqidNe0MUIz6EVQxYXLcUCl9USryPLWAWKBiwL80efALu5znH8K96P6fF33Gzw=;
Received: by f493.i.mail.ru with local (envelope-from <[email protected]>) id 1ebQkt-0004Zj-4G; Tue, 16 Jan 2018 15:54:19 +0300
Received: by e.mail.ru with HTTP; Tue, 16 Jan 2018 15:54:19 +0300
From: joseph
  andrew <[email protected]>
Subject: עדיין מחכה למשוב שלך
MIME-Version: 1.0
X-Mailer: Mail.Ru Mailer 1.0
Date: Tue, 16 Jan 2018 15:54:19 +0300
Reply-To: joseph
  andrew <[email protected]>
X-Priority: 3 (Normal)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Authentication-Results: f493.i.mail.ru; auth=pass [email protected] [email protected]
X-7FA49CB5: 0D63561A33F958A5898151702DBFE222A841889EBAE90B8E20672C31CB87FE38725E5C173C3A84C39B8A9203B4187291E49527301AB7C5D479C543ECCDAE434EC4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F20A889B128FC2D163B503F486389A921A5CC5B56E945C8DA
X-Mailru-Sender: AEEF7784B292FD580FA14CB39DA65BAAC14FF9386EF48BFAB56EC34AB37A73FC68AD8B15A0E9EE36875DC23763F10D8F75E89B9EB25B1370F805D6321A69DA8E2FB9333096616C166E245241366DF001CF5B8F1B83B229A3C432A6261406F5E9E7E03437FF0094633453F38A29522196
X-Mras: OK
X-Spam: undefined

Bearbeiten:

Versucht mit bcc zu senden und leer "an" und Google Mail zeigte den bcc. Derzeit scheint die @ Luc-Antwort die eigentliche Antwort zu sein (RCPT TO Wurde verwendet).

(BCC try fail

58
YoniXw

Warum?

Zwei Erklärungen:

  • BCC
  • Spam

Ich habe oft Spam bekommen, wo sie sich verstecken wollen, an wen es aus irgendeinem Grund gerichtet war. Da ich auf meiner Domain einen Sammelbegriff habe, wird dieser für mich unabhängig von der verwendeten Adresse eintreffen (es sei denn, sie haben eine verwendet, die ich auf die schwarze Liste gesetzt habe).

Wie ist das möglich?

Der SMTP-Verkehr sieht folgendermaßen aus:

EHLO example.com 
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
RCPT TO:<[email protected]>
RCPT TO:<[email protected]>
DATA
Subject: test
From: <[email protected]>
To: <[email protected]>
CC: <[email protected]>

Hi Jake,
Just letting you know that email works.

.
QUIT

Sie können eine TCP -Verbindung zu einem beliebigen Mailserver öffnen und diese eingeben. Diese antwortet Ihnen und übermittelt Ihre E-Mail (im Beispiel habe ich die Antworten weggelassen). Installieren Sie unter Windows Telnet Geben Sie im Windows-Funktionsmenü telnet example.com 25 ein, um unter example.com an Port 25 eine Verbindung zum Server herzustellen.

Wie Sie sehen können, wurde user4 im RCPT TO Adressiert und landet in ihrem E-Mail-Posteingang, wird jedoch nicht in den Headern from, to oder cc der E-Mail-Daten erwähnt. Die E-Mail-Daten, vom Befehl DATA bis zum . In einer Zeile für sich, sind der Teil, den Sie sehen, wenn Sie "Quelltext anzeigen" in Ihrem E-Mail-Client öffnen. Es hat also wenig mit dem eigentlichen E-Mail-Austausch zu tun. Natürlich passt es normalerweise zusammen, aber in einem böswilligen Fall ist es ihnen egal, was "üblich" ist. Und im Fall von BCC werden Sie es auch nicht sehen.

Ich habe oft Spam bekommen, wo sie sich verstecken, wohin er gesendet wurde. Um es verfolgen zu können, muss ich in meinen Mailserver-Protokollen graben.

Ein Serveradministrator kann auch solche BCCs nachschlagen, allerdings natürlich nur von seiner eigenen Domain (wenn es sich um BCCs für [email protected] Und [email protected] Handelt, wird der Administrator von a.example.com Dies tun stefan nicht sehen).

Warum Sie GMail im BCC an sich selbst senden und ein BCC-Feld mit sich selbst auf der Empfangsseite sehen können: Das E-Mail-Programm/der E-Mail-Anbieter kann einfach separate SMTP-Nachrichten für jeden Empfänger im BCC mit der BCC Header, der im verschachtelten E-Mail-Header erstellt wurde, um nur diesen Empfänger aufzulisten.

84
Luc

Überschriften wie To, Cc und Bcc sind im Wesentlichen alle kosmetisch; Sie steuern nicht den tatsächlichen Empfänger einer E-Mail gemäß dem SMTP-Protokoll. Es ist möglich, alles, was Sie möchten, in diese Felder einzugeben und trotzdem die separate Kontrolle darüber zu haben, an wen die E-Mail auf Protokollebene geht.

Wenn Sie eine E-Mail im Internet senden, kommuniziert Ihr sendender Mailserver über SMTP mit dem empfangenden Mailserver. Um eine E-Mail zu senden, sendet der sendende Server eine Reihe von Befehlen an den empfangenden Server.

  1. Ein HELO Befehl, der den Hostnamen des sendenden Servers angibt (dieser kann in neueren Versionen des Protokolls durch EHLO (kurz für "Extended HELO") ersetzt werden).
  2. EIN MAIL FROM Befehl, der die Adresse des Absenders der E-Mail angibt.
  3. EIN RCPT TO Befehl zur Ankündigung der Adressen der Nachrichtenempfänger.
  4. Ein DATA Befehl, der den Start der Nachricht selbst ankündigt, einschließlich Header und Body.

Überschriften in der Nachricht wie To, Cc oder Bcc werden nicht bearbeitet oder verwendet, sondern ohne Änderung übertragen.

Wenn diese Header von den sendenden und empfangenden Mailservern ignoriert werden, warum existieren sie dann?

Da es sich um eine gängige Konvention handelt, die von der Software Mail User Agent (Mail Client) verwendet wird, mit der der Benutzer tatsächlich interagiert, um E-Mails zu senden. Die übliche Funktionsweise eines E-Mail-Clients besteht darin, dass der Benutzer Empfängeradressen in drei Felder innerhalb des E-Mail-Clients mit den Namen "An", "Cc" und "Bcc" eingibt, die der E-Mail-Client als Grundlage für die Person verwendet, an die die Nachricht gesendet werden soll . Der Mail-Client nimmt dann das, was in den Feldern "An" und "Cc" geschrieben wurde, und platziert es in Mail-Headern mit den Namen "An" und "Cc" als Indikator für den Empfänger dessen, was der Absender ursprünglich in diese Felder eingegeben hat. Dies ist lediglich eine Höflichkeit für den empfangenden E-Mail-Client. Der sendende E-Mail-Client kann dieses Geheimnis geheim halten - genau das passiert mit seinem Feld "Bcc": Der E-Mail-Client erstellt in der gesendeten E-Mail niemals einen "Bcc" -Header, da der Sinn dieser Funktion darin besteht, dass sie nicht enthalten ist in der Mail selbst.

Der E-Mail-Client enthält außerdem ein Feld "Betreff", das er als "Betreff" -Header in die E-Mail einfügt, und erstellt in der E-Mail einen "Von" -Header mit Informationen zum Absender.

Wie ist das kein Sicherheitsproblem?

Es ist. Es macht es trivial einfach, gefälschte Informationen über den Absender oder die Empfänger in eine E-Mail zu schreiben. Wenn Benutzer darauf vertrauen, dass dies korrekt ist und nicht, ist dies ein potenzielles Sicherheitsproblem.

E-Mail-Clients könnten solche Header einfach ignorieren, aber dann würden Sie die Bequemlichkeit verpassen, zu wissen, an wen eine E-Mail adressiert wurde, wenn diese Informationen vorhanden und echt sind, und nach der gleichen Logik müssten Sie auch das "Von" und ignorieren Briefumschlagsender (MAIL FROM Befehl) und hinterlässt keinen Hinweis darauf, wer es gesendet hat. E-Mail-Clients gehen daher davon aus, dass die Anzeige dieser Informationen auch dann vorteilhafter ist, wenn sie gefälscht werden können.

Ein neuer Standard namens DMARC, der sich auf andere Standards wie DKIM und SPF stützt, kann es einem empfangenden E-Mail-Client ermöglichen, zu überprüfen, ob der Domain-/Hostname-Teil des "Von" -Headers echt ist. Während dies nur einen Teil von des "Von" -Headers überprüft und den "An" - oder "Cc" -Header nicht überprüft, können Sie wissen, dass der Mail war wirklich von dem System, von dem es behauptet zu kommen. Wenn dies ein vertrauenswürdiges System ist, können Sie zumindest schließen, dass die E-Mail und ihre Header von einem autorisierten Benutzer dieses Systems erstellt wurden.

Abgesehen von diesen Optionen war E-Mail einfach nicht dafür ausgelegt, dass all dies überprüfbar ist. Wenn Sie mehr möchten, müssen Sie eine Form der kryptografischen Überprüfung wie PGP zusätzlich zu Ihrer Nachricht verwenden und über eine Out-of-Band-Methode zur Überprüfung der Berechtigung verfügen.

32
thomasrutter

Bisher denke ich, dass Ihre Adresse als BCC verwendet wurde.

18
Mirsad

Es kann überraschend sein, aber dies ist im SMTP-Protokoll ganz normal. Eine Nachricht besteht aus Überschriften und einem Text. Es wird über eine Kette von Posttransportagenten gesendet. Kein Agent sollte den Body ändern, aber er kann die Header ändern, hauptsächlich um ein Received Feld, ein Date Feld hinzuzufügen, wenn es nicht vorhanden ist, und jedes andere Feld, wie es für seine eigene Verarbeitung erforderlich ist. Aber weder das Feld To noch das Feld From sind speziell, und insbesondere werden sie nicht zur Zustellung der Post verwendet . Die MTAs verwenden den sogenannten Umschlag, der in den Befehlen MAIL FROM Und RCPT TO Des SMTP-Protokolls übergeben wird.

Mail-Benutzeragenten (wie Thunderbird) verwenden die Felder An, Cc und Bcc, um den Umschlag zu erstellen. Wenn Sie jedoch das SMTP-Protokoll kennen, ist es einfach, eine Mail mit gefälschten oder fehlenden An und Von zu senden Überschriften.

15
Serge Ballesta