Voici une dramatisation de la façon dont se déroule la communication, lorsqu'un mail est reçu n'importe où.

Contexte: un serveur de messagerie, seul dans une baie, quelque part à Moscou . Le serveur reste là, les bras croisés, avec une expression d’espérance.

Serveur:
Ah, longs sont les jours de ma servitude,
Cela se passera dans une solitude sans cesse,
'Ere vient des anneaux extérieurs
Le porteur rapide des nouvelles extérieures.

Une connexion est ouverte.

Serveur:
Un client entrant! Pour quelle raison un mail
A ma tutelle sera confié
Que je pourrai transmettre comme le plus beau chevalier
Et au destinataire apporter le récit complet.

  220 mail server .kremlin.ru ESMTP Postfix (Ubuntu)  

Bienvenue dans mon royaume, vagabond du réseau,
Apprenez que je suis un puissant serveur de messagerie.
Comment allez-vous dans ce domaine jour être abordé
Le besoin va-t-il augmenter, pour que votre nom soit deviné?

Client:

  HELO whitehouse.gov  

Salut à toi, gardien du réseau,
Sachez que je suis né du bâtiment pâle.

Serveur:

  250 mailserver.kremlin.ru  

L'adresse IP entrante est résolue via le DNS en "nastyhackerz.cn".

Noble envoyé, je suis à vous de commander,
Même si votre voix vient des plaines chaudes
De la terre au-delà des montagnes asiatiques ,
Je répondrai à votre demande la plus faible.

Client:

  MAIL FR OM: barack.obama@whitehouse.govRCPT À: vladimir.putin@kremlin.ru Sujet: la plus grosse bombe Je vous défie à un concours du plus gros missile nucléaire, espèce de mannequin pathétique! D'abord Oussama, puis les Commies!.  

Voici mon message, à envoyer,
Et à transmettre fidèlement sur l'éther;
Attention aux adresses et au nom de l'expéditeur
qui sera affiché à l'autre extrémité.

Serveur:

  250 Ok  

Commentaire: il n'y a aucune sécurité dans les e-mails. Tous les noms d'expéditeurs et de destinataires sont indicatifs et il n'y a aucun moyen fiable de détecter l'usurpation d'identité (sinon, il y aurait beaucoup moins de spams).

Toute adresse e-mail «de» peut être falsifiée, car vous pouvez modifier les données sortantes que vous aimez. Vous n'avez pas besoin de tromper Gmail. En disant cela, gmail peut détecter des problèmes évidents lorsqu'un e-mail marqué comme envoyé par une organisation lui arrive d'un autre domaine.

Vous ne pouvez pas non plus être sûr que l'e-mail d'origine provient de Paypal dans votre exemple - que L'expéditeur peut également être usurpé!

Si vous voulez une sorte d'authentification pour éviter que cela ne se produise, vous avez besoin d'un moyen de signer ou de chiffrer les e-mails, ou d'une vérification hors bande pour confirmer que l'e-mail provient de votre ami (comme vous l'avez mentionné dans votre commentaire)

Sérieusement - ne faites confiance à aucun e-mail. Ne cliquez sur aucun lien dans un e-mail . Surtout des cibles de grande valeur comme Paypal. À la place, vous devriez vous connecter comme vous le feriez normalement et vérifier s'ils vous ont envoyé quelque chose.

Comme d'autres l'ont mentionné, n'importe qui peut simuler n'importe quelle adresse e-mail, y compris le champ "Expéditeur" - il n'y a aucune raison technique pour que paypal doive même inclure sa propre adresse e-mail dans le champ expéditeur, ils le font uniquement parce qu'ils sont une entreprise honnête. Ne vous attendez pas à ce que les spammeurs soient aussi gentils.

En passant, cependant, j'aimerais mentionner que gmail prend en charge DKIM, qui vous permet de vérifier un compte Paypal l'e-mail vient vraiment de Paypal.

Pour l'activer: Cliquez sur l'engrenage en haut à droite -> paramètres de messagerie -> labs -> Activez "Icône d'authentification pour les expéditeurs vérifiés"

Les e-mails Paypal signés s'afficheront désormais avec une petite icône en forme de clé à côté d'eux:

C'est un peu comme le courrier postal. N'importe qui peut vous envoyer une lettre avec un en-tête qui ressemble à la succursale locale de votre banque. Il y a certaines choses que vous pouvez faire pour attraper des imitateurs comme ceux-ci - vous pouvez vous assurer que le cachet de la poste provient de la bonne ville. Si votre banque utilise toujours du courrier en masse au lieu de timbres individuels, vous remarquerez peut-être cela, etc. Mais vous ne vous souciez probablement jamais de vérifier ces choses, et même si vous le faisiez, cela ne suffirait pas pour vérifier que la lettre provient de votre banque.

La principale différence entre le courrier postal et le courrier électronique, c'est qu'avec le courrier électronique, un faux est plus pratique - il peut être conçu une fois, puis répété pour un coût presque nul.

Cela signifie que toutes les contrefaçons et contre-mesures sont à une échelle plus massive et (à moins que vous ne soyez comme moi ¹ ) certains faux e-mails arriveront dans votre boîte de réception, et c'est à vous de les filtrer manuellement.

En fin de compte, tout comme vous n'appelleriez pas un numéro de téléphone sur une lettre pour "vérifier les informations de votre compte" (comme votre SSN et votre carte de crédit), vous ne devez pas non plus cliquer sur les liens dans les e-mails et vous attendre à la connexion écran ou tout autre formulaire pour envoyer en toute sécurité les informations privées à votre banque. Si vous le faites, vous pourriez vous retrouver à envoyer vos informations d'identification à un imposteur, sans jamais vous en rendre compte.

^1. J'ai éliminé tous mes spams. J'ai mon propre nom de domaine. Je donne à chaque contact sa propre adresse e-mail, et tout arrive dans ma seule boîte de réception. De cette façon, si Bob attrape un virus sur son ordinateur et que je commence à recevoir une partie de ce spam de bas niveau, alors je peux dire à Bob de changer son mot de passe de messagerie et de commencer à utiliser une nouvelle adresse de courrier électronique pour son courrier électronique. La nouvelle adresse e-mail ne recevra pas de spam, et je peux supprimer l'ancienne, car seul Bob l'utilisait.

Je n'ai pas besoin d'aller dire à ma banque et à mes autres amis, mes vendeurs, mes collègues, que mon adresse e-mail a changé, car chacun a sa propre adresse. (Je n'ai même pas besoin de mettre à jour StackExchange et le Gravater.) C'est bon pour moi (pas de spam), bon pour Bob (il sait qu'il a un "virus ou quelque chose" - parfois je peux soyez direct, mais il faut faire attention de ne pas se tromper après), tant mieux pour mes autres copains (je ne me plains jamais du nombre de courriels que j'ai reçus au cours des dernières 24 heures, et explique pourquoi je ne leur ai pas répondu)

Je pense que vous avez tous oublié un petit détail qui a été mentionné dans la dramatisation ci-dessus, qui est en fait très facile à vérifier:

Les e-mails frauduleux ne proviennent pas d'une adresse e-mail qui appartient légitimement au domaine dont ils prétendent être originaires. Une partie du protocole SMTP comprend un ensemble d ' en-têtes de message complets qui incluent toujours le chemin de retour du message, qui est l'adresse e-mail qui en fait a envoyé le message. Non seulement cela, mais les adresses IP ont également une région géographique définitive à laquelle elles sont attribuées. Donc, vous pouvez attraper ces écarts avec un peu de fouille.

Prenons, par exemple, dit dramatisation.

Il mentionne que l'e-mail provient de whitehouse.gov. Voici son adresse IP:

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

Maintenant, disons que nastyhackerz.cn résout une adresse IP quelque part dans le bloc 1.0.32.0-1.0.63.255 (pour référence: http://www.nirsoft.net/countryip/cn.html premier bloc de la liste). Cette adresse IP va figurer dans les en-têtes complets du message. Tout ce que vous avez à faire est de prendre cette IP en ligne pour retrouver sa géolocalisation (vous pouvez utiliser http://www.geoiptool.com/ par exemple)

L'adresse IP de la maison blanche. gov (173.223.0.110) au moment de la rédaction de cet article se géolocalise à Boston, Massachusetts (pour une raison quelconque, un système de prévention du spam ne me permettra pas de publier ma recherche sur geoiptool en raison de points de réputation, vous pouvez donc faire la recherche vous-même) qui est assez proche de chez nous (District de Columbia)! Supposons simplement que whitehouse.gov soit hébergé dans un centre de données qui se trouve à Boston, juste pour rendre cela plus facile à expliquer.

Tant que l'adresse IP et l'adresse e-mail auxquelles l'e-mail était réellement fort > envoyé de ne correspond pas à l'adresse IP et à l'adresse e-mail desquelles l'e-mail prétend être envoyé, il peut être considéré comme une usurpation. Il vous suffit de regarder dans les en-têtes de message complets .

Regardons les en-têtes d'un e-mail que j'ai envoyé depuis l'un de mes propres domaines (dragon-architect.com) vers ma propre adresse e-mail personnelle:

  Delivered-To: dragon.architect @ gmail.com Reçu: par 10.180.89.68 avec l'ID SMTP bm4csp105911wib; Mar 29 janvier 2013 08:54:47 -0800 (PST) X-Received: par 10.60.30.38 avec l'ID SMTP p6mr1296792oeh.2.1359478487251; Mar, 29 Jan 2013 08:54:47 -0800 (PST) Return-Path: <calyodelphi@dragon-architect.com>Reçu: de gateway14.websitewelcome.com (gateway14.websitewelcome.com. [69.93.154.35]) par mx.google .com avec l'ID ESMTP m7si14056914oee.29.2013.01.29.08.54.45; Mar, 29 Jan 2013 08:54:46 -0800 (PST) Reçu-SPF: neutre (google.com: 69.93.154.35 n'est ni autorisé ni refusé par le domaine de calyodelphi@dragon-architect.com) client-ip = 69.93. 154.35; Résultats d'authentification: mx.google.com; spf = neutral (google.com: 69.93.154.35 n'est ni autorisé ni refusé par le domaine de calyodelphi@dragon-architect.com) smtp.mail=calyodelphi@dragon-architect.comReceived: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 0530E1DFDB334; Mar 29 Jan 2013 10:54:43 -0600 (CST) Reçu: de bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) par gateway14.websitewelcome.com (Postfix) avec l'ID ESMTP EA7191DFDB314 pour <dragon .architect @ gmail.com>; Mar, 29 Jan 2013 10:54:42 -0600 (CST) Reçu: de [127.0.0.1] (port = 43458 helo = dragon-architect.com) par bentley.websitewelcome.com avec esmtpa (Exim 4.80) (enveloppe- de <calyodelphi@dragon-architect.com>) id 1U0ESK-0001KE-DP pour dragon.architect@gmail.com; Tue, 29 Jan 2013 10:54:44 -0600MIME-Version: 1.0Content-Type: text / plain; jeu de caractères = UTF-8; format = flowedContent-Transfer-Encoding: 7bitDate: Mar, 29 Jan 2013 10:54:44 -0600 De: calyodelphi@dragon-architect.com À: <dragon.architect@gmail.com>Subject: Headers Test
Message-ID: <11c694cd1e07c66a404000008321d0c4@dragon-architect.com>X-Sender: calyodelphi@dragon-architect.comUser-Agent: Roundcube Webmail / 0.8.4X-AntiAbuse: Cet en-tête a été ajouté à un rapport d'abus s'il vous plaît : Nom d'hôte principal - bentley.websitewelcome.comX-AntiAbuse: Domaine d'origine - gmail.comX-AntiAbuse: UID / GID de l'expéditeur / appelant - [47 12] / [47 12] X-AntiAbuse: Domaine d'adresse de l'expéditeur - dragon-architect.comX -BWhitelist: noX-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dragon-architect.com) [127.0.0.1]: 43458X-Source-Auth: calyodelphi @ dragon-architect. comX-Email-Count: 1X-Source-Cap: ZHJhZ2FyY2g7ZHJhZ2FyY2g7YmVudGxleS53ZWJzaXRld2VsY29tZS5jb20 = Test des tests!  

C'est beaucoup de données aléatoires à parcourir, mais il y a deux lignes que nous examinons: chemin de retour et de. Puisque je me suis légitimement envoyé cet e-mail, ils correspondent tous les deux. Le chemin de retour ne peut pas être usurpé. Ou si c'est possible, il est incroyablement difficile d'usurper efficacement et nécessite une configuration délibérée du démon SMTP utilisé pour envoyer du courrier. Comparer le chemin de retour et les champs de données from dans les en-têtes complets est une façon pour moi et mes collègues où je travaille d'identifier l'usurpation d'identité et de déterminer si un ticket d'assistance doit être soumis.

Alors, que se passe-t-il si ils correspondent tous les deux, mais l'e-mail doit toujours être falsifié? J'y reviendrai dans la section suivante ...

Maintenant, comme mentionné précédemment, il existe d'autres moyens de déterminer l'usurpation d'un e-mail. Les enregistrements SPF sont l'un de ces moyens, mais ils ne sont pas toujours parfaits. Prenez, par exemple, le SPF de whitehouse.gov et comparez-le au SPF de mon propre domaine:

  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 " 

Habituellement, un bon enregistrement SPF comprend également l'adresse IP du serveur qui a envoyé le courrier, donc celui qui a créé l'enregistrement SPF pour whitehouse.gov ne le sait probablement pas. Je considérerais l'enregistrement SPF de whitehouse.gov trop générique pour être efficace pour déterminer les origines réelles de tout message prétendant provenir de whitehouse.gov. Le SPF pour mon propre domaine, en revanche, qui a été automatiquement généré par le serveur qui héberge mon domaine (avec l'aimable autorisation de mon hébergeur), est très spécifique et inclut l'adresse IP du serveur lui-même.

J'avouerai ne pas être intimement familier avec la façon dont les enregistrements SPF sont formatés et comment ils fonctionnent, mais j'en ai suffisamment appris sur mon travail pour que je puisse au moins identifier les enregistrements SPF génériques et spécifiques. Je suppose que c'est quelque chose que je devrais probablement approfondir un week-end quand je m'ennuie et que je veux des lectures techniques!

Quoi qu'il en soit, revenons sur la bonne voie ici. Regardez les lignes reçues. L'un d'eux déclare ainsi: Reçu: de bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) Devinez quoi? Cela correspond à l'adresse IP de l'enregistrement SPF de mon domaine.

Si l'adresse IP dans le SPF ne correspond pas à l'adresse IP du serveur qui a réellement envoyé l'e-mail, c'est une autre indication que vous avez usurpé votre mains. Par conséquent, un enregistrement SPF générique comme "v = spf1 + mx ~ all" ne va tout simplement pas couper la moutarde de sécurité. Je ne ferais même pas confiance aux e-mails provenant d'un domaine légitime qui a un SPF générique comme celui-ci.

Peut-être devrions-nous déposer une pétition sur petitions.whitehouse.gov pour exiger que leur les administrateurs de sécurité revisitent l'enregistrement SPF qu'ils ont créé pour le domaine! (Je plaisante, je plaisante.)

MODIFIER

En fait, je dois MASSIVEMENT me corriger à propos des enregistrements SPF! J'ai fait de fausses hypothèses et appris quelques choses aujourd'hui après avoir interrogé un collègue qui était plus au courant que moi au sujet des enregistrements SPF. Donc, j'utiliserai les deux SPF pour whitehouse.gov et dragon-architect.com dans mon auto-correction:

  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 " 

Le SPF pour mon propre domaine est en fait plus clément que le SPF pour whitehouse.gov (quelque chose que je prévois de corriger ce soir après avoir terminé cette modification). Je vais vous expliquer pourquoi:

"v = spf1 + mx ~ all" dit essentiellement que les e-mails de whitehouse.gov sont censés provenir des noms d'hôte définis dans les enregistrements MX pour whitehouse.gov, et tous les e-mails qui ne proviennent pas de ces noms d'hôte sont censés être usurpés, mais le fait de savoir s'ils sont marqués comme usurpation ou non dépend du destinataire de l'e-mail.

  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" indique que les e-mails de dragon-architect.com sont censés arriver depuis l'adresse IP de dragon-architect.com (67.18.28.78), les noms d'hôte définis dans le ou les enregistrements MX de dragon-architect.com, ou l'adresse IP du serveur qui héberge dragon-architect.com (70.84 .243.130). Tous les e-mails qui ne viennent pas de ceux-là, eh bien, cela? Tout à la fin signifie simplement qu'il n'y a aucun conseil sur l'opportunité de passer ou de rejeter les e-mails.

Alors, quelle est la viande et les pommes de terre d'un enregistrement SPF? Le «tout» à la toute fin. Pour citer ce collègue à propos du "tout":

  + tout signifie fondamentalement ALL passer - l'enregistrement est inutile, le domaine de l'expéditeur ne se soucie pas? Tout indique neutre et conseille de ne pas passer ou rejeter le courrier
~ tout indique un échec, et le serveur est considéré comme invalide, mais ne suggère pas spécifiquement une action.-tout est un échec brutal, tout le reste est invalide, rejetez-le ou marquez-le.  

Pour que "tout" est l'endroit où vous définissez à quel point votre enregistrement SPF est strict. Mais la question de savoir si l’enregistrement SPF est réellement utilisé pour déterminer l’usurpation d’un e-mail dépend complètement du service de messagerie de réception.

Alors voilà l'avoir. SPF en un mot.

Alors oui. TL; DR: vérifiez vos en-têtes complets pour voir si le chemin de retour et les champs from correspondent. Vérifiez ensuite vos enregistrements SPF s'il y en a pour voir si vous obtenez des adresses IP correspondantes.

SMTP ( Simple Mail Transfer Protocol) est nommé ainsi pour une très bonne raison.

Le SMTP est né en 1982 sur l'ancien ARPANET, qui était détenu et contrôlé par le DoD américain, et destiné à la communication entre des personnes avec des autorisations de sécurité travaillant sur des projets gouvernementaux à qui on pouvait généralement faire confiance pour ne pas en abuser. La «sécurité» de ce réseau a été réalisée tout simplement en plaçant les machines qui pouvaient s'y connecter dans des zones physiquement sécurisées des différentes installations, juste à côté des travaux classifiés que ces installations exécutaient. En conséquence, la sécurisation des données envoyées le long du réseau n'a généralement été envisagée qu'après la mise hors service d'ARPANET, le premier saut quantique ayant eu lieu vers 1993 avec l'API de programmation de réseau sécurisé (qui a jeté les bases de Secure Sockets Layer, désormais généralement connu. comme Transport Layer Security). Alors que la plupart des protocoles (y compris SMTP / POP / IMAP) peuvent désormais ajouter TLS pour un canal de communication sécurisé, tout cela assure la confidentialité et l'authenticité du serveur; il ne fournit pas l'authenticité de l'expéditeur ou l'intégrité du message, et il ne fournit pas non plus de non-répudiation.

Il existe une option disponible pour la sécurité des e-mails, appelée PGP (Pretty Good Privacy; c'est l'humour ironique de Phil Zimmerman pour un système qu'aucun ordinateur sur la planète ne pourrait casser s'il était correctement implémenté). Il peut, avec diverses options, fournir les quatre principes fondamentaux de la sécurité de l'information; la confidentialité, l'intégrité, l'authenticité et la non-répudiation (l'expéditeur, qui a signé l'e-mail à l'aide de son certificat, ne peut pas prétendre qu'il ne l'a pas réellement envoyé; personne d'autre ne pourrait le faire, à moins que le certificat n'ait été compromis). Il utilise un système similaire de certificats de clé publique et d’échange de clés sécurisé, comme on le voit dans une poignée de main TLS bidirectionnelle, mais certains détails sont modifiés pour refléter la nature asynchrone du transport des e-mails et pour refléter le désir d’un système décentralisé. » Web of Trust ", ce qui exclut le besoin d'autorités de certification de confiance mondiale.

Cependant, ce système n’a pas encore vraiment décollé, bien qu’il ait plus de 25 ans, et en tant que tel, il n’est requis que par les agences gouvernementales et certaines grandes entreprises. Pratiquement tous les fournisseurs de messagerie continueront à livrer volontiers des e-mails frauduleux via des connexions sécurisées à votre boîte de réception. Vous pouvez, dans de nombreux cas, encourager vos amis et les autres personnes dont vous souhaitez recevoir des e-mails à adopter le schéma PGP, et tout ce qui n'est pas valablement signé est mis en "quarantaine", mais il ne s'agit en réalité que d'un autre niveau de "filtrage anti-spam" ", et je ne connais pas un seul fournisseur de courrier électronique public auquel vous pouvez demander de rejeter les courriers électroniques sans signature numérique pure et simple; le serveur de messagerie devrait être sous votre contrôle, tel qu'un serveur Exchange d'entreprise.

• Est-ce que Paypal exploite un problème de sécurité ici? ... Comment PayPal peut-il usurper si facilement les e-mails?

Techniquement, non ce n'est pas un problème de sécurité, les e-mails ne sont pas sécurisés pour commencer. Ils utilisent l'un des en-têtes SMTP suivants situés dans l'en-tête du message (pas l'en-tête de l'enveloppe)

1. Resent-From
2. Renvoyé -Sender
3. Sender

Il y a une différence conceptuelle entre le «remailing» et le «spoofing». Le client de messagerie doit afficher cette différence. Le client Gmail ne fait pas cela.

• Paypal n'est pas une usurpation d'identité, il utilise l'un de ces en-têtes SMTP: Renvoyé depuis , Resent-Sender ou Sender[

• Il est très facile d'usurper un domaine ... même avec les commandes SPF activées

• Le MUA (client de messagerie) doit afficher le Afficher depuis , son état de vérification SPF, DKIM et DMARC.

• L'en-tête Resent- * doit être utilisé de manière à indiquer clairement que ce message est "renvoyé".

• En général, la meilleure solution consiste à utiliser DKIM + DMARC , ou SPF + DMARC et un MUA qui affiche les résultats de la vérification.

Quelques informations générales

D'une manière générale, il y a deux adresses «de» et deux adresses «à» dans chaque message SMTP. L'une est connue sous le nom d'enveloppe RFC2821, l'autre est le message RFC2822. Ils servent à des fins différentes

L'enveloppe: (RFC2821)

• L'enveloppe est des métadonnées qui n'apparaissent pas dans l'en-tête SMTP . Il disparaît lorsque le message est envoyé au prochain MTA.

• Le RCPT De: est l'endroit où les NDR vont aller. Si un message provient de Postmaster ou d'un service de messagerie, il s'agit généralement de <> ou de someSystem@place.com . Il est intéressant de voir que salesforce utilise ceci de manière similaire à constantContact comme clé dans une base de données telle que toUserContactID@salesforce.com pour voir si le message a rebondi.

• Le RCPT TO: est à qui le message est réellement envoyé. Il est utilisé pour les utilisateurs "to" et "bcc". Cela n'affecte généralement pas «l'affichage des adresses» dans le client de messagerie, mais il y a des occasions où les MTA afficheront ce champ (si les en-têtes RFC2822 sont corrompus).

Le message (RFC2822)

• La partie message commence lorsque la commande data est émise.

• Ces informations incluent les en-têtes SMTP que vous connaissez, le message et ses pièces jointes. Imaginez que toutes ces données soient copiées et collées de chaque MTA au suivant, successivement jusqu'à ce que le message atteigne la boîte de réception.

• Il est habituel que chaque MTA préfixe la copie mentionnée ci-dessus et collez avec des informations sur le MTA (IP source, IP de destination, etc.). Il colle également les détails du contrôle SPF.

• C'est le Afficher depuis qui est placé. C'est important. Les spoofers peuvent modifier cela.

• Le Mail From: dans l'enveloppe est supprimé et généralement placé ici comme return-path: adresse pour les NDR

Alors, comment empêcher les gens de modifier l'affichage de? Eh bien DMARC redéfinit une deuxième signification pour le record SPF. Il reconnaît qu'il existe une différence entre l ' Enveloppe de et l' Afficher à partir de , et qu'il existe des raisons légitimes pour lesquelles ils ne correspondent pas. Étant donné que SPF a été initialement défini pour ne s'occuper que de l'enveloppe de, si l'affichage de est différent, DMARC nécessitera une deuxième vérification DNS pour voir si le message est autorisé à partir de cette adresse IP.

Pour permettre des scénarios de transfert , DMARC permet également au Afficher depuis d'être signé de manière cryptographique par DKIM, et si un spammeur ou un hameçonnage non autorisé tentait de prendre cette identité, le cryptage échouerait.

Qu'est-ce que DKIM? DKIM est une technologie de cryptage légère qui signe les données résidant dans le message. si vous avez déjà reçu un message de Gmail, Yahoo ou AOL, vos messages étaient signés DKIM. Le fait est que personne ne saura jamais que vous utilisez le cryptage et la signature DKIM à moins que vous ne regardiez dans les en-têtes. C'est transparent.

DKIM peut généralement survivre à la transmission et au transfert vers différents MTA. Quelque chose que SPF ne peut pas faire. Les administrateurs de messagerie peuvent utiliser cela à notre avantage pour éviter l'usurpation d'identité.

Le problème réside dans le fait que le SPF ne vérifie que l'enveloppe RFC2821, et non le Afficher depuis . Étant donné que la plupart des gens se soucient de l ' affichage de affiché dans un e-mail, et non du chemin de retour NDR, nous avons besoin d'une solution pour protéger et sécuriser cette pièce.

C'est là que DMARC entre. DMARC vous permet d'utiliser une combinaison de vérification SPF modifiée ou DKIM pour vérifier le Afficher depuis . DKIM vous permet de signer cryptographiquement le RFC2822 Display From chaque fois que le SPF ne correspond pas au Display From (ce qui se produit fréquemment).

Usurpation de Display From un problème de sécurité?

Oui, le phishing par courrier électronique est un problème de sécurité important que de nombreux fournisseurs examinent. À savoir Paypal, AOL, Google, Yahoo et d'autres sociétés mettent en œuvre DMARC pour résoudre ce problème de phishing.

Pourquoi est-il encore possible de falsifier l'en-tête "From:" dans les e-mails?

Certains administrateurs de serveur n'ont pas implémenté les dernières technologies pour empêcher ce genre de chose de se produire. L'un des principaux obstacles à l'adoption de ces technologies est les «services de transfert d'e-mails» tels qu'un logiciel de liste de diffusion, des redirecteurs automatiques ou un remailer d'anciens élèves (.forwarder). À savoir:

1. Soit SPF, soit DKIM n'est pas configuré.

2. Aucune stratégie DMARC n'est configurée.

3. Le client de messagerie n'affiche pas les résultats de vérification des champs Afficher depuis et Renvoyé- * ou Expéditeur.

Que fait paypal?

Paypal utilise l'en-tête Sender pour indiquer qu'il a été renvoyé. Il s'agit de l'utilisation correcte et prévue de cet en-tête.

Qu'est-ce que GMail fait de mal?

Gmail ne précise pas que l'en-tête de l'expéditeur est utilisé, ils ne valident pas l'affichage de adresse d'une manière conviviale, et il ne fait pas la distinction entre l'affichage de et l'expéditeur.

Cela n'a rien à voir avec le "spoofing" ou la sournoiserie d'aucune sorte.

Pendant des années et des années, nous sommes nombreux à avoir reçu une copie de divers formulaires, en particulier des formulaires de type "dire à un ami" etc où, par programmation, l'adresse 'de' identifiant l '"expéditeur de l'utilisateur" n'est pas celle du serveur de messagerie d'envoi, bien qu'il s'agisse d'un courrier légitime non via un serveur de messagerie ouvert utilisé pour le relais.

Peut-être un programme de forum ou de livre d'or renvoie un e-mail interne "De:" identifiant un autre utilisateur et non le site d'accueil.

Lorsque nous configurons nos clients de messagerie, nous pouvons définir l'adresse par défaut "De:" souvent totalement indépendante du serveur de messagerie réel.

En d'autres termes, l'adresse 'de' définie n'a absolument rien à voir avec la machine effectuant le mailing proprement dit.

Bien que ces jours-ci, dans le cas de ' score au niveau du spam 'il est risqué de (SERVER SIDE) une utilisation "par programme" à partir d'adresses qui ne sont pas du domaine / de la machine d'origine, nous devrions prendre l'adresse "De:" comme simplement pas plus qu’un identifiant pour la consommation humaine.