Qu’est-ce que l’ARC ? Définition, fonctionnement et vérification.

Nouvel article consacré à l’authentification des e-mails, ici je vais vous parler de l’ARC : Authenticated Received Chain !

Il y a moins d’un mois, j’annonçais lors de notre call hebdomadaire du lundi que j’allais écrire un article sur l’ARC… Tout à coup, Marion (dont je tairai le nom de famille ) monte au créneau «C’est quoi encore ton truc… SPF, DKIM, DMARC, BIMI… et là ARC, c’est un truc que t’as inventé ???»… Après un moment de solitude, je me suis dit que finalement cet article n’était pas une si mauvaise idée  Alors Let’s Gooooooo ! Attention, cet article vous présentera ARC, j’en prévois déjà un autre sur son paramétrage, be patient 

Définition de l’ARC

L’ARC ou Authenticated Received Chain est un protocole d’authentification e-mails défini par la RFC 8617. L’objectif d’ARC est de permettre de garder les résultats d’authentification d’un e-mail (on parle ici de SPF, DKIM, DMARC) quand ce dernier passe par un flux de messagerie indirect (une liste de diffusion, un service de transfert d’e-mail ou encore un service de filtrage). Si vous souhaitez en savoir plus sur l’historique d’ARC, n’hésitez pas à consulter le site officiel.

Pourquoi implémenter ARC ?

Vous êtes dans l’optique de protéger efficacement votre domaine contre le spam et le phishing en paramétrant DMARC avec une politique de sécurité à «reject». Et bien sachez qu’ARC est fait pour vous ! Je m’explique :

Lors d’un transfert d’e-mail, les systèmes d’authentification SPF & DKIM vont malheureusement être en échec car une IP différente va être utilisée lors du transfert (et donc cette IP ne figurera pas dans SPF) et la signature DKIM ne sera pas valide puisque l’e-mail ne sera pas émis du serveur d’envoi de l’annonceur mais du destinataire.

Ainsi, quand DMARC va tenter de valider SPF & DKIM, le résultat sera sans appel et amènera au rejet de l’e-mail puisque ceci ne pourra valider SPF & DKIM (et donc appliquera la politique de sécurité définie par l’administrateur).

Et c’est là qu’ARC intervient (comme par magie) ! En implémentant l’ARC, il va apporter une couche supplémentaire à la conformité DMARC en maintenant l’authentification de l’e-mail d’origine à chaque transfert  N’oubliez pas aussi que le transfert d’e-mail reste un signal positif pour votre réputation car vos abonnés/clients/prospects, en transférant votre e-mail, parlent de vous à leurs contacts… Et ça, ça n’a pas de prix !

Au final, la mise en place d’ARC vous permettra (si DMARC est à «reject») :

• D’améliorer la légitimité et conformité de vos e-mails.
• D’améliorer votre réputation.

Avantages et inconvénients d’ARC !

Heureusement ou malheureusement, ARC offre de nombreux avantages mais également des inconvénients pouvant impacter (positivement ou négativement) chaque destinataire… Ainsi ARC permettra :

• (+) De rendre visibles les résultats des systèmes d’authentification SPF, DKIM, DMARC dès le premier transfert (et pour tous les suivants). Ces signatures sont transmises intactes et les signatures des intermédiaires peuvent être liées de manière fiable à leur nom de domaine.
• (+) D’attribuer aux intermédiaires le droit de modifier le message original.
• (+) De fournir des données sur les intermédiaires à un système de réputation traquant leurs comportements.

Mais comme tout système, ARC a ses limites et ne permettra pas :

• (-) De donner des informations sur la fiabilité de l’expéditeur du message original ou des différents intermédiaires.
• (-) De donner des informations sur les contenus des messages transférés : un intermédiaire peut très bien injecter un mauvais contenu ou modifier/supprimer certains éléments d’ARC.

Concrètement, comment fonctionne ARC ?

On va essayer de vous expliquer comment fonctionne ARC grâce au schéma ci-dessous :

• A : L’expéditeur envoie un e-mail à un destinataire.
• B : Le serveur de mails entrant du destinataire réceptionne l’e-mail et valide les systèmes d’authentification SPF, DKIM et DMARC (voir ARC si l’e-mail vient déjà d’un transfert).
• C : Le destinataire transfère l’e-mail et son serveur de mails sortant insère les en-têtes ARC.
• D : Le destinataire final réceptionne l’e-mail et les systèmes d’authentification ARC, SPF, DKIM, DMARC.

Entre la validation du transfert de l’e-mail par le destinataire et l’envoi via le serveur d’e-mails sortant, le serveur intermédiaire devra effectuer les étapes suivantes :

• Copier le champ «Authentication-Results» dans un nouveau champ AAR «ARC-Authentication-Results» (commençant par i=1) et l’ajouter au message.
• Calculer l’AMS «ARC-Message-Signature» du message (avec l’AAR) et l’ajouter au message.
• Calculer l’AS «ARC-Seal» pour les en-têtes ARC-Seal précédentes et l’ajouter au message.

De son côté, le serveur de messagerie entrant du destinataire recevant le transfert devra pour effectuer les étapes suivantes pour valider ARC :

• Valider la chaine des en-têtes ARC-Seal.
• Valider la dernière signature de message ARC en fonction du numéro d’instance.

Comment vérifier dans un e-mail si ARC est présent ?

Pour savoir si ARC est implémenté, il va falloir fouiller dans l’entête d’un de vos e-mails sur Gmail et trouver les 3 tags suivants :

ARC-Authentication-Results (AAR)

Ce champ enregistre l’évaluation d’authentification de l’e-mail d’origine. On pourra donc y retrouver toutes les informations liées à SPF, DKIM & DMARC. Dans les deux exemples ci-dessous, on identifie bien (en vert) les résultats d’authentification de chaque annonceur.

ARC-Authentication-Results: i=1; mx.google.com; spf=pass(google.com: domain of neobounces@rueducommerce.com designates 178.251.200.41 as permitted sender)smtp.mailfrom=neobounces@rueducommerce.com

Champ «ARC-Authentication-Results» d’un e-mail de Rueducommerce

ARC-Authentication-Results: i=1; mx.google.com;

dkim=pass header.i=@accounts.google.com header.s=20161025 header.b=vjGrpQ1x;

spf=pass (google.com: domain of 3zx-twwgtctqde-h4fbo022ekdji.6ee6b4.2eci58.18ij0d6c08b.2ec@gaia.bounces.google.com designates 209.85.220.69 as permitted sender) smtp.mailfrom=3Zx-TWwgTCtQDE-H4FBO022EKDJI.6EE6B4.2ECI58.18IJ0D6C08B.2EC@gaia.bounces.google.com;

dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=accounts.google.com

Champ «ARC-Authentication-Results» d’un e-mail de Gmail

ARC-Message-Signature (AMS)

Ce champ est une combinaison d’un numéro d’instance (i) et d’une signature de type DKIM de l’ensemble du message (allant de l’adresse FROM à la dernière balise du code HTML), à l’exception du champ «ARC-Seal». On y retrouve, comme dans une signature DKIM, le domaine (d=) et son sélecteur (s=).

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;h=message-id:mime-version:reply-to:to:subject:date:from;bh=/MJZCOxVmR9iFbpVGw20Q0FiNtS4pfBaSeClVnhcrY4=;b=LUqzB4TJ9R3/WhqOaj0Ar5mKh0H5XJXdrbYCaU6t1QTAomlWsrgrfnuvXTmPo+2/WvgzNznOptInpUm9c2RzbxApLg5KYVqJX6Hr44qf69wBAoHtEdvCZcYTKsHhJsi4rTN5NFiAheKd+kNg0VMA1X7NMh6bVbCum5oT1HNTyv9Z5tvLitG/sviiEaKarVtvrRy68IV6pkWeKlFtCHLChgrRGS936RLwsYdrSA+dbIbbcrKo27DViwHWYQz/0w9vtQcYZfllh93lKAFar8m6EAjtOxh0SnGzieHDTnutWavrXwwuS4Ouvl9KFUu3FWfKViYfIQp094BjUS5fsk5YKA==

Champ «ARC-Message-Signature» d’un e-mail de Rueducommerce

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;h=to:from:subject:message-id:feedback-id:date:mime-version:dkim-signature;bh=6O3KORUzqD0WkIe5vS5NB3NlP0d6tsso3cA/RNIlEAM=;b=mqTA4V4YQrXFyc19butpFPxewHaXYQOYnK6ViP2zbUN98oBFsf+tdVi5toKHsdN6RDhN3niui5C48BPDTYhCUrDWUE19ZglG2vRRSdjOdd/FpQ8dgOaqN6SBaVWK9f+gjMDTbB9Azs+rBync1Wj7ymie0QCDeQzrVJLz020PZ2L+BBie4Uft1H45bS/Re9J0yuGSshigocih3MHBh7PGHgwdm5ESva36qQNw6HkS7V38CaLtcT85+6PO9hAl0tDMYrsJCDfPsAfJvPQnA4lKbSx5sdWQ9sFiMCo2wnOukEQ3Qkws00mDOxXbK4dtfFoD6C4HC8TAaccM3WyAp3Eqig==

Champ «ARC-Message-Signature» d’un e-mail de Gmail

ARC-Seal (AS)

Ce champ est une combinaison d’un numéro d’instance (i), d’une signature de type DKIM du champ «ARC-Seal» précédent et de la validité des entrées ARC antérieures. Comme précédemment, on retrouve dans les deux exemples le domaine (d=) et son sélecteur (s=).

ARC-Seal: i=1; a=rsa-sha256; t=1585815476; cv=none;d=google.com; s=arc-20160816;b=U55HkMyXyyuerzECYjLPqNgXpPgnejdOxX7xz60+EKKKVRdK5K3/T3owmUMLdUIsWTXw7/2B19BQPA7LnNpLQYs4p8S8ETe2RJ12rRUu+EOHXCQI7pimhwmVvhzrUbbkH+561kxvk0l69Ck7zWNvtRi+7rEJAIFaJwS9bQQtLYovLi1JICNgcyZCGd49yn/Ues2oNHpjstApQQ3yJ1z0vGKfmBAtO2ijLSMMZQIlOwCcYa7deU0TQCmehDhJ9GkjGqxP4HXssdGo8vFhGj3ya8VbAeHFMw7xSiqC2Uly5w7+dFt0vL4kRN9QFNxpzth+xjKNTiHxXyh18jipbwnkCg==

Champ «ARC-Message-Signature» d’un e-mail de Rueducommerce

ARC-Seal: i=1; a=rsa-sha256; t=1536368489; cv=none;d=google.com; s=arc-20160816;b=AU3leI36p81PkbNQHPV4wpVB4oKjzR+xBRpPt7eh3B1DYCfJFK5gbb6nJiO0KjxSKoVc/ubFz4hYFyYNqIpMbCvNLE7DMLYf0Df3JksYRJVeklAvOnNZhuORaNs2K+CoBBGrxbEa+oZI0Yv88VCPsNDGEB0EP4X8jYdQLyaU1Lpv/wLmgRxuMh2mXsWuSNatxsXZ2m4o9Wkl5CE7q8vnfUGOVUPrmdgc5avuGVLrGQvICUdAImGkT5haxYwxBGQD8F0jMRr1aK7e/J9tCbY3eCiZOtdlkeVkdWwcUFAxRehOSNhE2pOB3r+s9B2l5uep47fHZpuVwhtoqII2Me0EkQ==

Champ «ARC-Message-Signature» d’un e-mail de Gmail

On conclut !?!

Quand on connait aujourd’hui l’importance pour une entreprise de protéger ses domaines contre le spam et l’usurpation d’identité grâce à la mise en conformité DMARC, l’implémentation et le paramétrage d’ARC peut vite devenir une tâche prioritaire des équipes IT… Pour l’écriture de cet article, 3 sources ont été utilisées :

• Le site officiel d’ARC.
• Overview of the ARC Protocol for Email (par Steve Jones).
• Wikipedia (EN).

Consultez nos autres articles sur l’authentification des e-mails :

• Qu’est-ce que DKIM ?
• Et si vous passiez votre enregistrement SPF au qualifieur “-all” ?!?
• 10 conseils à mettre en place dans sa configuration SPF…
• Qu’est-ce que SPF ?
• Etat des lieux de l’usage de DMARC dans les entreprises du CAC40 en Juillet 2020
• BIMI c’est bon, mangez-en !
• Délivrabilité : SPF, DKIM, DMARC, … ce qu’il faut savoir sur l’authentification de vos emails !