Hier ist eine Dramatisierung des Kommunikationsverlaufs, wenn eine E-Mail irgendwo empfangen wird.

Kontext: Ein E-Mail-Server, allein in einer Bucht, irgendwo in Moskau . Der Server sitzt nur untätig da, mit einem Ausdruck der Erwartung.

Server:
Ah, die Tage meiner Knechtschaft sind lang,
Das soll in immer Einsamkeit ausgegeben werden,
'Ere kommt aus den äußeren Ringen
Der schnelle Träger der äußeren Botschaft.

Eine Verbindung wird geöffnet.

Server:
Ein eingehender Client! Vielleicht wird eine Post
meiner Vormundschaft anvertraut
, die ich als das schönste Ross übermitteln darf
und dem Empfänger die ganze Geschichte bringen.

  220 Mailserver .kremlin.ru ESMTP Postfix (Ubuntu)  

Willkommen in meinem Reich, Netzwanderer.
Erfahren Sie, dass ich ein mächtiger Mailserver bin.
Wie werden Sie dies tun? Tag angesprochen werden
Soll die Notwendigkeit steigen, damit Ihr Name erraten wird?

Kunde:

  HELO whitehouse.gov  

Gegrüßet seist du, Bewahrer des Netzwerks.
Wisse, dass ich aus dem blassen Gebäude hervorgegangen bin.

Server:

  250 mailserver.kremlin.ru  

Die eingehende IP-Adresse wird über den DNS in aufgelöst "nastyhackerz.cn".

Edler Gesandter, ich bin Ihr Befehl,
Auch wenn Ihre Stimme aus den heißen Ebenen des Landes jenseits der asiatischen Berge kommt ,
Ich werde Ihrer geringsten Forderung nachkommen.

Kunde:

  MAIL FR OM: [email protected] TO: [email protected]: größte BombeIch fordere dich zu einem Wettbewerb der größten Atomrakete heraus, du erbärmlicher Dummy! Erst Oussama, dann die Commies!  

Hier ist meine Botschaft, die Sie senden,
und treu auf den Äther übertragen sollen;
Achten Sie auf die Adressen und den Namen des Absenders
Das wird am anderen Ende angezeigt.

Server:

  250 Ok  

So wurde es geschrieben, so soll es gemacht werden.
Die Nachricht wird gesendet und ist nach Russland gegangen.

Der Server sendet die E-Mail so wie sie ist und fügt nur ein " Erhalten: "Header zum Markieren des Namens, den der Client bei seinem ersten Befehl angegeben hat. Dann beginnt der Dritte Weltkrieg. Das Ende.

Kommentar: E-Mails enthalten keinerlei Sicherheit. Alle Sender- und Empfängernamen sind indikativ und es gibt keine zuverlässige Möglichkeit, Spoofing zu erkennen (andernfalls würde ich viel weniger Spam erhalten).

Jede E-Mail-Absenderadresse kann gefälscht werden, da Sie alle ausgehenden Daten ändern können, die Sie möchten. Sie müssen Google Mail nicht zum Narren halten. Wenn Sie dies sagen, kann Google Mail offensichtliche Probleme erkennen, wenn eine E-Mail, die als von einer Organisation gesendet markiert wurde, von einer anderen Domain zu ihnen kommt.

Sie können auch nicht sicher sein, ob die ursprüngliche E-Mail in Ihrem Beispiel von Paypal stammt - das Das Absenderbit kann auch gefälscht werden!

Wenn Sie eine Authentifizierung wünschen, um dies zu verhindern, benötigen Sie eine Möglichkeit zum Signieren oder Verschlüsseln von E-Mails oder eine Out-of-Band-Überprüfung, um zu bestätigen, dass die E-Mail von Ihrem Freund stammt (wie Sie in Ihrem Kommentar erwähnt haben)

Ernsthaft - vertrauen Sie keiner E-Mail. Klicken Sie nicht auf einen Link in einer E-Mail . Besonders von hochwertigen Zielen wie Paypal. Stattdessen sollten Sie sich wie gewohnt anmelden und prüfen, ob sie Ihnen etwas gesendet haben.

Wie andere bereits erwähnt haben, kann jeder jede E-Mail-Adresse fälschen, einschließlich des Felds "Absender" - es gibt keinen technischen Grund, warum Paypal sogar seine eigene E-Mail-Adresse hinzufügen muss Im Absenderfeld tun sie das nur, weil sie ein ehrliches Unternehmen sind. Erwarten Sie nicht, dass Spammer so nett sind.

Abgesehen davon möchte ich jedoch erwähnen, dass Google Mail DKIM unterstützt, mit dem Sie einen Paypal überprüfen können E-Mail kam wirklich von Paypal.

So aktivieren Sie es: Klicken Sie oben rechts auf das Zahnrad -> E-Mail-Einstellungen -> Labs -> Aktivieren Sie "Authentifizierungssymbol für verifizierte Absender"

Jetzt werden signierte Paypal-E-Mails mit einem kleinen Schlüsselsymbol angezeigt:

Es ist ähnlich wie bei der Post. Jeder kann Ihnen einen Brief mit Briefkopf senden, der wie die Zweigstelle Ihrer Bank aussieht. Es gibt einige Dinge, die Sie tun können, um solche Imitatoren zu fangen - Sie könnten sicherstellen, dass der Poststempel aus der richtigen Stadt stammt. Wenn Ihre Bank immer Massenpost anstelle einzelner Briefmarken verwendet, werden Sie dies möglicherweise bemerken usw. Aber Sie werden sich wahrscheinlich nie die Mühe machen, diese Dinge zu überprüfen, und selbst wenn Sie dies tun würden, würde dies nicht ausreichen, um zu überprüfen, ob der Brief von Ihrer Bank stammt.

Der Hauptunterschied zwischen Post und E-Mail besteht darin, dass bei E-Mails eine Fälschung praktischer ist - sie kann einmal entworfen und dann für nahezu null Kosten wiederholt werden.

Dies bedeutet, dass Alle Fälschungen und Gegenmaßnahmen sind massiver, und (es sei denn, Sie sind wie ich ^{1 sup>) einige gefälschte E-Mails werden in Ihrem Posteingang eingehen, und es liegt an Ihnen, sie manuell herauszufiltern.}

Fazit: So wie Sie in einem Brief keine Telefonnummer anrufen würden, um "Ihre Kontoinformationen zu überprüfen" (wie Ihre SSN und Ihre Kreditkarte), sollten Sie auch nicht auf Links in E-Mails klicken und die Anmeldung erwarten Bildschirm oder in welcher Form auch immer, um die privaten Informationen sicher an Ihre Bank zu senden. Wenn Sie dies tun, senden Sie möglicherweise Ihre Anmeldeinformationen an einen Betrüger und bemerken dies nie.

^{1. sup> Ich habe alle meine Spam-Mails entfernt. Ich habe meinen eigenen Domainnamen. Ich gebe jedem Kontakt eine eigene E-Mail-Adresse und alles landet in meinem Posteingang. Auf diese Weise kann ich Bob anweisen, sein E-Mail-Passwort zu ändern und eine neue E-Mail-Adresse für seine E-Mail an mich zu verwenden, wenn Bob einen Virus auf seinem Computer hat und ich anfange, etwas von diesem Spam auf niedriger Ebene zu bekommen. Die neue E-Mail-Adresse enthält keinen Spam und ich kann die alte löschen, da sie nur von Bob verwendet wurde.}

Ich muss meiner Bank und meinen anderen Freunden, meinen Lieferanten, meinen Mitarbeitern nicht mitteilen, dass sich meine E-Mail-Adresse geändert hat, da jede ihre eigene Adresse hat. (Ich muss StackExchange und den Gravater nicht einmal aktualisieren.) Das ist gut für mich (kein Spam), gut für Bob (er weiß, dass er einen "Virus oder so etwas" hat - manchmal kann ich Seien Sie direkt, aber man muss aufpassen, dass Sie sich danach nicht irren.) Gut für meine anderen Freunde (ich beschwere mich nie darüber, wie viele E-Mails ich in den letzten 24 Stunden erhalten habe, und erkläre, warum ich nicht auf sie zurückgekommen bin)

Ich denke, Sie haben ein kleines Detail übersehen, das in der obigen Dramatisierung erwähnt wurde und das eigentlich sehr einfach zu überprüfen ist:

Gefälschte E-Mails stammen nicht von einer E-Mail-Adresse, die rechtmäßig zu der gehört Domäne, von der sie behaupten zu stammen. Ein Teil des SMTP-Protokolls enthält eine Reihe von vollständigen Nachrichtenkopfzeilen , die immer den Rückweg der Nachricht enthalten. Dies ist die E-Mail-Adresse, die tatsächlich ist hat die Nachricht gesendet. Darüber hinaus haben IP-Adressen eine bestimmte geografische Region, der sie zugewiesen sind. Sie können diese Diskrepanzen also mit ein wenig Graben abfangen.

Nehmen Sie zum Beispiel die Dramatisierung.

Es wird erwähnt, dass die E-Mail von whitehouse.gov stammt. Hier ist die IP-Adresse:

  calyodelphi @ dragonpad: ~ $ dig + short whitehouse.gov173.223.0.110  

Nehmen wir nun an, dass nastyhackerz.cn wird in eine IP-Adresse irgendwo im Block 1.0.32.0-1.0.63.255 aufgelöst (als Referenz: http://www.nirsoft.net/countryip/cn.html erster Block in der Liste). Diese IP-Adresse befindet sich in den vollständigen Nachrichtenkopfzeilen. Alles, was Sie tun müssen, ist, diese IP online zu nehmen, um ihre Geolokalisierung zu ermitteln (Sie können beispielsweise http://www.geoiptool.com/ verwenden).

Die IP für Whitehouse. gov (173.223.0.110) zum Zeitpunkt des Schreibens dieses Beitrags geolociert nach Boston, Massachusetts (aus irgendeinem Grund lässt mich ein Spam-Präventionssystem meine Suche aufgrund von Reputationspunkten nicht auf geoiptool veröffentlichen, sodass Sie die Suche selbst durchführen können). Das ist ziemlich nah an zu Hause (District of Columbia)! Nehmen wir einfach an, dass whitehouse.gov in einem Rechenzentrum in Boston gehostet wird, um die Erklärung zu vereinfachen.

Solange die IP- und E-Mail-Adresse, an der die E-Mail tatsächlich strong war > gesendet von stimmt nicht mit der IP- und E-Mail-Adresse überein, von der die E-Mail behauptet gesendet werden soll. Dies kann als Parodie bestimmt werden. Sie müssen nur in den vollständigen Nachrichtenkopfzeilen nachsehen.

Sehen wir uns die Header einer E-Mail an, die ich von einer meiner eigenen Domains (dragon-architect.com) an meine persönliche E-Mail-Adresse gesendet habe:

  Übermittelt an: dragon.architect @ gmail.comReceived: von 10.180.89.68 mit der SMTP-ID bm4csp105911wib; Di, 29. Januar 2013 08:54:47 -0800 (PST) X-Received: bis 10.60.30.38 mit SMTP-ID p6mr1296792oeh.2.1359478487251; Di, 29. Januar 2013 08:54:47 -0800 (PST) Rückweg: <[email protected]>Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com. [69.93.154.35]) von mx.go .com mit ESMTP-ID m7si14056914oee.29.2013.01.29.08.54.45; Di, 29 Jan 2013 08:54:46 -0800 (PST) Received-SPF: neutral (google.com: 69.93.154.35 wird von der Domain [email protected] weder zugelassen noch verweigert) client-ip = 69.93. 154,35; Authentifizierungsergebnisse: mx.google.com; spf = neutral (google.com: 69.93.154.35 wird von der Domain [email protected] weder zugelassen noch verweigert) [email protected]: von gateway14.websitewelcome.com (Postfix, von Benutzer-ID 5007) id 0530E1DFDB334; Di, 29 Jan 2013 10:54:43 -0600 (CST) Eingegangen: von bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) von gateway14.websitewelcome.com (Postfix) mit der ESMTP-ID EA7191DFDB314 für <dragon .architect @ gmail.com>; Di, 29 Jan 2013 10:54:42 -0600 (CST) Eingegangen: von [127.0.0.1] (port = 43458 helo = dragon-architect.com) von bentley.websitewelcome.com mit esmtpa (Exim 4.80) (Umschlag-) von <[email protected]>) id 1U0ESK-0001KE-DP für [email protected]; Di, 29. Januar 2013 10:54:44 -0600MIME-Version: 1.0Inhaltstyp: text / plain; Zeichensatz = UTF-8; format = flowedContent-Transfer-Encoding: 7bitDate: Di, 29 Jan 2013 10:54:44 -0600Von: [email protected] An: <[email protected]>Subject: Headers Test
Nachrichten-ID: <[email protected]>X-Sender: [email protected]: Roundcube Webmail / 0.8.4X-AntiAbuse: Dieser Header wurde hinzugefügt, um Missbrauch zu verfolgen : Primärer Hostname - bentley.websitewelcome.comX-AntiAbuse: Originaldomäne - gmail.comX-AntiAbuse: UID / GID des Absenders / Anrufers - [47 12] / [47 12] X-AntiAbuse: Absenderadressdomäne - dragon -itect.com.com -BWhitelist: noX-Quelle: X-Source-Args: X-Source-Dir: X-Source-Absender: (dragon-architect.com) [127.0.0.1]: 43458X-Source-Auth: calyodelphi @ dragon -itect. comX-Email-Count: 1X-Source-Cap: ZHJhZ2FyY2g7ZHJhZ2FyY2g7YmVudGxleS53ZWJzaXRld2VsY29tZS5jb20 = Testen testen!  

Das sind viele zufällige Daten, die durchgesehen werden müssen. Rückweg und von. Da ich diese E-Mail zu Recht an mich selbst gesendet habe, stimmen beide überein. Der Rückweg kann nicht gefälscht werden. Wenn dies möglich ist, ist es unglaublich schwierig, effektiv zu fälschen, und es ist eine gezielte Konfiguration des SMTP-Dämons erforderlich, der zum Senden von E-Mails verwendet wird. Der Vergleich des Rückweges und der From-Datenfelder in den vollständigen Headern ist eine Möglichkeit, mit der ich und meine Mitarbeiter, bei denen ich arbeite, Parodien identifizieren und feststellen können, ob ein Support-Ticket eingereicht werden muss.

Also, was ist, wenn beide passen zusammen, aber die E-Mail sollte immer noch gefälscht sein? Ich werde im nächsten Abschnitt darauf zurückkommen ...

Nun, wie bereits erwähnt, gibt es andere Möglichkeiten, die Spoofiness einer E-Mail zu bestimmen. SPF-Aufzeichnungen sind eine dieser Möglichkeiten, aber sie sind nicht immer perfekt. Nehmen Sie zum Beispiel den SPF von whitehouse.gov und vergleichen Sie ihn mit dem SPF meiner eigenen Domain:

  calyodelphi @ dragonpad: ~ $ dig + short txt whitehouse.gov "v = spf1 + mx ~ all "calyodelphi @ dragonpad: ~ $ dig + short txt dragon-architect.com" v = spf1 + a + mx + ip4: 70.84.243.130? all " 

Normalerweise enthält ein guter SPF-Eintrag auch die IP-Adresse des Servers, der die E-Mail gesendet hat. Wer also den SPF-Eintrag für whitehouse.gov erstellt hat, weiß dies wahrscheinlich nicht. Ich würde den SPF-Datensatz von whitehouse.gov als zu allgemein betrachten, um die tatsächliche Herkunft von Nachrichten, die angeblich von whitehouse.gov stammen, effektiv bestimmen zu können. Der SPF für meine eigene Domain hingegen, der automatisch von dem Server generiert wurde, der meine Domain hostet (mit freundlicher Genehmigung meines Webhosts), ist sehr spezifisch und enthält die IP-Adresse des Servers selbst.

Ich gebe zu, dass ich nicht genau weiß, wie SPF-Datensätze formatiert sind und wie sie funktionieren, aber ich habe bei meiner Arbeit genug gelernt, um zumindest generische und spezifische SPF-Datensätze identifizieren zu können. Ich denke, das ist etwas, in das ich mich wahrscheinlich an einem Wochenende vertiefen sollte, wenn mir langweilig ist und ich technisches Lesematerial möchte!

Wie auch immer, hier wieder auf Kurs. Schauen Sie sich die empfangenen Zeilen an. Einer von ihnen lautet wie folgt: Erhalten: von bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) Ratet mal, was? Dies entspricht der IP-Adresse im SPF-Eintrag meiner Domain.

Wenn die IP im SPF nicht mit der IP des Servers übereinstimmt, der die E-Mail tatsächlich gesendet hat, ist dies ein weiterer Hinweis darauf, dass Sie eine Parodie auf Ihre Domain haben Hände. Daher wird ein generischer SPF-Datensatz wie "v = spf1 + mx ~ all" den Sicherheitssenf einfach nicht abschneiden. Ich würde nicht einmal E-Mails vertrauen, die von einer legitimen Domain stammen, die einen generischen SPF wie diesen hat.

Vielleicht sollten wir eine Petition auf petitions.whitehouse.gov einreichen, um dies zu fordern Sicherheitsadministratoren besuchen den SPF-Datensatz, den sie für die Domain erstellt haben, erneut! (Ich scherze, ich scherze.)

BEARBEITEN

Ich muss mich tatsächlich MASSIV über SPF-Datensätze korrigieren! Ich habe heute einige falsche Annahmen getroffen und ein paar Dinge gelernt, nachdem ich einen Kollegen gefragt hatte, der mehr über SPF-Aufzeichnungen wusste als ich. Also werde ich die beiden SPFs für whitehouse.gov und dragon-architect.com in meiner Selbstkorrektur verwenden:

  calyodelphi @ dragonpad: ~ $ dig + short txt whitehouse.gov "v = spf1 + mx ~ all "calyodelphi @ dragonpad: ~ $ dig + short txt dragon-architect.com" v = spf1 + a + mx + ip4: 70.84.243.130? all " 

Der SPF für meine eigene Domain ist tatsächlich milder als der SPF für whitehouse.gov (etwas, das ich heute Abend korrigieren möchte, nachdem ich diese Bearbeitung abgeschlossen habe). Ich werde erklären, warum:

"v = spf1 + mx ~ all" besagt im Grunde, dass E-Mails von whitehouse.gov von den in den MX-Datensätzen für definierten Hostnamen stammen sollen whitehouse.gov und alle E-Mails, die nicht von diesen Hostnamen stammen, sollen gefälscht sein. Ob sie jedoch als gefälscht markiert sind oder nicht, hängt vom Empfänger der E-Mail ab.

  calyodelphi @ Dragonpad: ~ $ dig + short mx whitehouse.gov110 mail6.eop.gov.105 mail2.eop.gov.110 mail5.eop.gov.105 mail1.eop.gov.105 mail4.eop.gov.105 mail3.eop. gov.  

"v = spf1 + a + mx + ip4: 70.84.243.130? all" sagt, dass E-Mails von dragon-architect.com kommen sollen entweder von der IP-Adresse für dragon-architect.com (67.18.28.78), den in den MX-Datensätzen für dragon-architect.com definierten Hostnamen oder der IP-Adresse des Servers, auf dem dragon-architect.com gehostet wird (70.84) .243.130). Alle E-Mails, die nicht von diesen stammen, bedeuten am Ende nur, dass es keinen Rat gibt, ob die E-Mails weitergeleitet oder abgelehnt werden sollen.

Was ist also das Fleisch und die Kartoffeln eines SPF-Datensatzes? Das "Alles" ganz am Ende. Um diesen Mitarbeiter über das "All" zu zitieren:

  + all bedeutet im Grunde ALL pass - der Datensatz ist nutzlos, Absenderdomain ist das egal? All zeigt neutral an und rät, nicht zu bestehen oder Mail ablehnen
~ all zeigt einen Fehler an, und der Server wird als ungültig angesehen, schlägt jedoch keine Aktion vor. -all ist ein schwerer Fehler, alles andere ist ungültig, lehnen Sie ihn ab oder markieren Sie ihn.  

Damit Mit "all" legen Sie fest, wie streng Ihr SPF-Datensatz ist. Ob der SPF-Datensatz tatsächlich verwendet wird, um die Spoofiness einer E-Mail zu bestimmen, hängt jedoch vollständig vom empfangenden E-Mail-Dienst ab.

Also, da sind Sie habe es. SPF auf den Punkt gebracht.

Also ja. TL; DR: Überprüfen Sie Ihre vollständigen Header, um festzustellen, ob der Rückweg und die Felder von übereinstimmen. Überprüfen Sie dann Ihre SPF-Einträge, falls vorhanden, um festzustellen, ob Sie übereinstimmende IP-Adressen erhalten.

SMTP ( Simple Mail Transfer Protocol) heißt das aus einem sehr guten Grund.

SMTP entstand 1982 auf dem alten ARPANET, das dem US-amerikanischen Verteidigungsministerium gehörte und von diesem kontrolliert wurde und für die Kommunikation zwischen Personen mit Sicherheitsüberprüfungen gedacht war, die an Regierungsprojekten arbeiteten, denen allgemein vertraut werden konnte, dass sie es nicht missbrauchen. Die "Sicherheit" dieses Netzwerks wurde ganz einfach erreicht, indem die Maschinen, die mit ihm verbunden werden konnten, in physisch gesicherten Bereichen der verschiedenen Einrichtungen direkt neben den klassifizierten Arbeiten platziert wurden, die diese Einrichtungen ausführten. Infolgedessen wurde die tatsächliche Sicherung der über das Netzwerk gesendeten Daten im Allgemeinen erst nach der Außerbetriebnahme von ARPANET in Betracht gezogen. Der erste Quantensprung erfolgte 1993 mit der Secure Network Programming API (die den Grundstein für die heute allgemein bekannte Secure Sockets Layer legte) als Transportschicht-Sicherheit). Während die meisten Protokolle (einschließlich SMTP / POP / IMAP) jetzt TLS für einen sicheren Kommunikationskanal hinzufügen können, bietet dies lediglich Vertraulichkeit und Serverauthentizität. Es bietet keine Absenderauthentizität oder Nachrichtenintegrität und keine Nicht-Zurückweisung.

Für die E-Mail-Sicherheit gibt es eine Option namens PGP (Pretty Good Privacy; es ist Phil Zimmermans humoristischer Humor für ein System, das bei ordnungsgemäßer Implementierung kein Computer auf dem Planeten beschädigen könnte). Es kann mit verschiedenen Optionen alle vier grundlegenden Grundsätze der Informationssicherheit bereitstellen. Vertraulichkeit, Integrität, Authentizität und Nicht-Zurückweisung (der Absender, der die E-Mail mit seinem Zertifikat signiert hat, kann nicht behaupten, dass er sie nicht tatsächlich gesendet hat; niemand anderes hätte dies tun können, es sei denn, das Zertifikat wurde kompromittiert). Es verwendet ein ähnliches System von Public-Key-Zertifikaten und sicherem Schlüsselaustausch wie bei einem Zwei-Wege-TLS-Handshake. Einige Details wurden jedoch geändert, um den asynchronen Charakter des E-Mail-Transports und den Wunsch nach einem dezentralen " web of trust "schließt die Notwendigkeit global vertrauenswürdiger Zertifizierungsstellen aus.

Dieses System hat sich jedoch trotz seines Alters von über 25 Jahren noch nicht wirklich durchgesetzt und wird daher nur von Regierungsbehörden und bestimmten großen Unternehmen benötigt. Praktisch alle E-Mail-Anbieter senden weiterhin gerne betrügerische E-Mails über sichere Verbindungen in Ihren Posteingang. In vielen Fällen können Sie Ihre Freunde und andere Personen, von denen Sie eine E-Mail erhalten möchten, dazu ermutigen, das PGP-Schema zu übernehmen. Alles, was nicht gültig signiert ist, wird in die "Quarantäne" verschoben. Dies ist jedoch nur eine weitere Stufe der "Spam-Filterung" ", und ich kenne keinen einzigen öffentlichen E-Mail-Anbieter, den Sie anweisen können, E-Mails ohne digitale Signatur sofort abzulehnen. Der E-Mail-Server muss unter Ihrer Kontrolle stehen, z. B. ein Exchange-Unternehmensserver.

tl; dr

• Nutzt Paypal hier ein Sicherheitsproblem aus? ... Wie kann PayPal E-Mails so einfach fälschen?

Technisch gesehen ist es kein Sicherheitsproblem, E-Mail ist zunächst nicht sicher. Sie verwenden einen der folgenden SMTP-Header im Nachrichtenkopf (kein Umschlagkopf)

1. Present-From
2. Resent -Sender
3. Sender
ol>

Es gibt einen konzeptionellen Unterschied zwischen "Remailing" und "Spoofing". Der E-Mail-Client sollte diesen Unterschied anzeigen. Der Google Mail-Client tut dies nicht.

• Paypal fälscht nicht, sondern verwendet einen dieser SMTP-Header: Resent-From , Resent-Sender oder Sender

• Es ist sehr einfach, eine Domain zu fälschen ... selbst wenn die SPF-Steuerelemente aktiviert sind

• Der MUA (E-Mail-Client) sollte den Display From , seinen SPF-, DKIM- und DMARC-Überprüfungsstatus anzeigen.

• Der Resent- * -Header sollte so verwendet werden, dass deutlich wird, dass diese Nachricht "erneut gesendet" wird.

• Im Allgemeinen ist die beste Lösung die Verwendung von DKIM + DMARC oder SPF + DMARC und einer MUA, die die Überprüfungsergebnisse anzeigt.

Hintergrund

Im Allgemeinen enthält jede SMTP-Nachricht zwei "Von" -Adressen und zwei "Bis" -Adressen. Einer ist als RFC2821-Umschlag bekannt, der andere ist die RFC2822-Nachricht. Sie dienen verschiedenen Zwecken.

Der Umschlag: (RFC2821)

• Der Umschlag besteht aus Metadaten, die nicht im SMTP-Header angezeigt werden . Es verschwindet, wenn die Nachricht zum nächsten MTA geht.

• Im RCPT From: werden die NDRs abgelegt. Wenn eine Nachricht vom Postmaster oder einem Remailer-Dienst kommt, ist dies normalerweise <> oder [email protected] . Es ist interessant zu sehen, dass Salesforce dies ähnlich wie constantContact als Schlüssel in einer Datenbank wie [email protected] verwendet, um festzustellen, ob die Nachricht zurückgeschickt wurde.

• Der RCPT TO: gibt an, an wen die Nachricht tatsächlich gesendet wird. Es wird für Benutzer "to" und "bcc" gleichermaßen verwendet. Dies wirkt sich normalerweise nicht auf die "Anzeige von Adressen" im E-Mail-Client aus. In einigen Fällen wird dieses Feld jedoch von MTAs angezeigt (wenn die RFC2822-Header beschädigt sind).

Die Nachricht (RFC2822)

• Der Nachrichtenteil beginnt mit der Ausgabe des Befehls data ​​code>.

• Diese Informationen umfassen die Ihnen vertrauten SMTP-Header, die Nachricht und ihre Anhänge. Stellen Sie sich vor, alle diese Daten werden nacheinander von jedem MTA zum nächsten kopiert und eingefügt, bis die Nachricht den Posteingang erreicht.

• Es ist üblich, dass jedem MTA die oben genannte Kopie vorangestellt wird und fügen Sie Informationen zum MTA ein (Quell-IP, Ziel-IP usw.). Außerdem werden die SPF-Prüfdetails eingefügt.

• Dies ist die Anzeige von . Das ist wichtig. Spoofer können dies ändern.

• Die Mail From: im Umschlag wird verworfen und normalerweise hier als Rückweg platziert: Adresse für NDRs

Wie verhindern wir also, dass Personen die Anzeige von ändern? Nun, DMARC definiert eine zweite Bedeutung für den SPF-Datensatz neu. Es wird erkannt, dass es einen Unterschied zwischen dem Umschlag von und dem Display von gibt und dass es legitime Gründe dafür gibt, dass sie nicht übereinstimmen. Da SPF ursprünglich so definiert wurde, dass es sich nur um Envelope From kümmert, erfordert DMARC eine zweite DNS-Überprüfung, um festzustellen, ob die Nachricht von dieser IP-Adresse aus zulässig ist.

Um Weiterleitungsszenarien zu ermöglichen Mit DMARC kann das Display From auch von DKIM kryptografisch signiert werden. Wenn ein nicht autorisierter Spammer oder Phisher versucht, diese Identität anzunehmen, schlägt die Verschlüsselung fehl.

Was ist DKIM? DKIM ist eine einfache Verschlüsselungstechnologie, die die in der Nachricht enthaltenen Daten signiert. Wenn Sie jemals eine Nachricht von Google Mail, Yahoo oder AOL erhalten haben, wurden Ihre Nachrichten von DKIM signiert. Der Punkt ist, dass niemand Sie jemals kennen wird, wenn Sie DKIM-Verschlüsselung und -Signatur verwenden, es sei denn, Sie schauen in die Header. Es ist transparent.

DKIM kann es normalerweise überleben, weitergeleitet und an verschiedene MTAs übertragen zu werden. Etwas, das SPF nicht kann. E-Mail-Administratoren können dies zu unserem Vorteil nutzen, um Spoofing zu verhindern.

Das Problem besteht darin, dass der SPF nur den RFC2821-Umschlag überprüft und nicht die Anzeige von . Da sich die meisten Menschen für die in einer E-Mail-Nachricht angezeigte Anzeige von und nicht für den NDR für den Rückweg interessieren, benötigen wir eine Lösung zum Schutz und zur Sicherung dieses Teils.

Hier befindet sich DMARC Mit DMARC können Sie eine Kombination aus einer modifizierten SPF-Prüfung oder DKIM verwenden, um die Anzeige von zu überprüfen. Mit DKIM können Sie die RFC2822-Anzeige von kryptografisch signieren, wenn der SPF nicht mit der Anzeige von übereinstimmt (was häufig vorkommt).

Fälscht die Anzeige von ein Sicherheitsproblem?

Ja, Phishing, obwohl E-Mail ein wichtiges Sicherheitsproblem ist, mit dem sich viele Anbieter befassen. Paypal, AOL, Google, Yahoo und andere Unternehmen implementieren DMARC, um dieses Phishing-Problem zu beheben.

Warum ist es immer noch möglich, "From:" - Header in E-Mails zu fälschen?

Einige Serveradministratoren haben nicht die neuesten Technologien implementiert, um dies zu verhindern. Eines der wichtigsten Dinge, die die Einführung dieser Technologien verhindern, sind "E-Mail-Weiterleitungsdienste" wie eine Mailinglistensoftware, automatische Weiterleitungen oder ein Alumni-Remailer (.forwarder). Nämlich:

1. SPF oder DKIM sind nicht konfiguriert.

2. Eine DMARC-Richtlinie ist nicht eingerichtet. P. >

3. Der E-Mail-Client zeigt die Überprüfungsergebnisse des Felds Anzeige von und des Felds Resent- * oder Sender nicht an.

Was macht Paypal?

Paypal verwendet den Absender -Header, um anzuzeigen, dass es erneut gesendet wurde. Dies ist die korrekte und beabsichtigte Verwendung dieses Headers.

Was macht GMail falsch?

Google Mail macht nicht deutlich, dass der Absender-Header verwendet wird, und überprüft die Anzeige von nicht Adresse auf benutzerfreundliche Weise, und es wird nicht zwischen Anzeige von und Absender unterschieden.

Es hat nichts mit "Spoofing" oder Verschlagenheit jeglicher Art zu tun.

Viele von uns haben jahrelang eine Kopie verschiedener Formulare erhalten, insbesondere Formulare vom Typ "Tell-a-Friend" usw., wobei programmgesteuert die Absenderadresse, die den "Absender des Benutzers" identifiziert, nicht vom sendenden Mailserver stammt, obwohl es sich um legitime E-Mails handelt, die nicht über einen offenen Mailserver gesendet werden, der für die Weiterleitung verwendet wird.

Möglicherweise ein Forum oder ein Gästebuchprogramm Gibt eine interne "Kontaktbenutzer" -E-Mail "Von:" zurück, die einen anderen Benutzer und nicht die Homepage identifiziert.

Wenn wir unsere E-Mail-Clients einrichten, können wir die Standardadresse "Von:" festlegen, die häufig völlig unabhängig von der ist tatsächlicher Mailserver.

Mit anderen Worten, die definierte Absenderadresse hat in Wirklichkeit absolut nichts mit dem Computer zu tun, der das eigentliche Mailing durchführt.

Obwohl heutzutage im Fall von ' Spam-Level-Scoring 'Es ist riskant, (SERVER SIDE) "programmatisch" von Adressen zu verwenden, die nicht von der Ursprungsdomäne / dem Ursprungscomputer stammen. Wir sollten die Adresse "Von:" als lediglich nicht verwenden mehr als eine Kennung für den menschlichen Verzehr.