Qu’est-ce que l’Authenticated Received Chain et pourquoi est-ce important ?

L’authentification est une préoccupation majeure dans le monde de l’email depuis un certain temps, mais l’engouement semble s’être amplifié après les annonces de Google et Yahoo en octobre 2023 concernant les exigences pour les expéditeurs. L’une des principales exigences est la mise en œuvre de SPF, DKIM et DMARC pour les expéditeurs en masse, ce qui signifie que nous devons également parler de l’ARC, qui prend le relais en cas de défaillance de ces authentifications.

L’Authenticated Received Chain (ARC) est un standard conçu pour résoudre les problèmes d’authentification liés à la livraison des emails, en particulier lorsque les messages transitent par des serveurs intermédiaires tels que des listes de diffusion ou des services de transfert. Il a été développé en 2016 pour soutenir d’autres authentifications qui peuvent parfois échouer lorsque les messages transitent par ces intermédiaires.

Avant d’explorer l’ARC plus en détail, passons en revue l’authentification des emails existante. Il existe trois authentifications clés qui fonctionnent de concert, DMARC, SPF et DKIM. DMARC s’appuie à la fois sur SPF et DKIM pour valider l’identité de l’expéditeur et l’authenticité des messages afin de se protéger contre les acteurs malveillants.

Cependant, les serveurs intermédiaires dans le processus de livraison des emails, tels que les services de transfert et les listes de diffusion, peuvent rompre par inadvertance l’authentification DMARC, ce qui entraîne le marquage d’emails légitimes comme spam ou leur rejet. C’est là qu’intervient l’ARC. L’ARC permet de surmonter les limites des authentifications des emails existantes en préservant les données d’authentification tout au long du processus de livraison des emails, y compris lors du passage par des intermédiaires.

L’adoption de l’ARC offre plusieurs avantages :

• Améliore la délivrabilité des emails en réduisant les risques d’usurpation et en instaurant un climat de confiance quant à l’origine et au contenu du message, évitant ainsi qu’il ne soit signalé comme spam.
• Renforce la sécurité des emails en vérifiant la chaîne de contrôle.
• Facilite le dépannage des emails en fournissant des informations précieuses sur le chemin parcouru par un email et sur les serveurs intermédiaires rencontrés en cours de route.

L’ARC fonctionne en créant une chaîne de contrôle vérifiable pour les messages d’email. C’est important car les serveurs intermédiaires que nous avons mentionnés peuvent altérer l’intégrité du message d’origine, entraînant ainsi l’échec de l’authentification. Voici quelques exemples simples de la façon dont les authentifications peuvent échouer sans l’ARC :

SPF est une authentification des emails standardisée qui vise à détecter les cas d’usurpation d’emails en procédant à une validation auprès du domaine de l’expéditeur. Voici comment elle peut échouer lors de l’utilisation d’un service de transfert d’emails :

• Expéditeur d’origine : OGbob@example.com
• Service de transfert : Forwardingexample.com
• Destinataire : Bob@example.com

Si forwardingexample.com ne dispose pas d’un enregistrement SPF incluant example.com, le serveur du destinataire risque de rejeter le message.

DKIM est une autre authentification des emails standardisée qui utilise des clés chiffrées et une signature dans l’en-tête pour valider l’authentification. Voici comment elle pourrait échouer :

• Expéditeur d’origine : OGbob@example.com
• Service de transfert : Forwardingexample.com
• Destinataire : Bob@example.com

Si la signature DKIM a été créée pour example.com mais que le service de transfert remplace l’en-tête par forwardingexample.com, l’authentification du message échouera.

DMARC exige un alignement avec SPF et DKIM pour le domaine « From ». Voici comment elle pourrait échouer :

• Expéditeur d’origine : OGbob@example.com
• Service de transfert : Forwardingexample.com
• Destinataire : Bob@example.com

Si le service de transfert remplace le domaine « From » par forwardingexample.com, l’alignement échouera puisque example.com était le domaine attendu.

Maintenant que nous savons pourquoi nous avons besoin de l’ARC, parlons de son fonctionnement et des raisons pour lesquelles il ne s’interrompt pas là où d’autres authentifications plus robustes échouent. L’ARC est un protocole simplement conçu pour créer une chaîne d’authentification de confiance afin que les en-têtes supplémentaires ou les modifications apportées par des intermédiaires n’entraînent pas l’échec du message.

Lorsqu’un email passe par un serveur intermédiaire, ce dernier ajoute sa signature cryptographique à l’en-tête du message, indiquant qu’il a pris en charge le message. Cette signature est ajoutée sans altérer le contenu du message d’origine pour garantir l’intégrité de l’email.

Le serveur du destinataire examine les en-têtes ARC pour valider l’authenticité des signatures des serveurs intermédiaires lors de la réception du message. En vérifiant la chaîne de contrôle, le serveur de réception peut prouver que le message n’a pas été altéré et qu’il provient d’une source légitime.

Pour mieux comprendre l’ARC en action, examinons un scénario :

Imaginez que l’entreprise A envoie un email à l’entreprise B, mais que le message transite par plusieurs serveurs intermédiaires, notamment un service de liste de diffusion et un service de transfert d’emails. Lorsque l’ARC est activé, chaque serveur intermédiaire ajoute sa signature à l’en-tête du message, ce qui permet à l’entreprise B de vérifier la chaîne de contrôle et de s’assurer de l’authenticité de l’email.

L’en-tête accompagne le message à chaque étape de son parcours et est utilisé par chaque serveur d’email pour valider l’authentification.

Si vous gérez votre propre infrastructure d’email, la mise en œuvre de l’ARC implique de configurer votre serveur d’email pour qu’il génère et valide les en-têtes ARC à mesure que les messages sont traités. Cela nécessite généralement d’intégrer des logiciels ou des modules spécifiques à l’ARC dans l’infrastructure de votre serveur d’email et de définir des politiques pour le traitement des messages dont les en-têtes ARC sont non valides ou manquants. Cela garantit la compatibilité avec les mécanismes d’authentification des emails existants tels que SPF, DKIM et DMARC, et permet de mettre à jour régulièrement votre configuration afin de vous aligner sur l’évolution des spécifications de l’ARC et des bonnes pratiques.

Si tout cela vous semble complexe, ne vous inquiétez pas, nous sommes là pour vous aider.

Si vous utilisez Sinch Mailgun, vous n’avez rien à faire.

Mailgun a amélioré son MTA pour utiliser le protocole Authenticated Received Chain (ARC) avec tous les messages entrants et transférés qui transitent par Mailgun. Cela signifie que nous avons lancé le support de l’ARC et que nous évaluons désormais DKIM et SPF, et ajoutons des en-têtes ARC signés si les messages sont transférés à l’aide de notre fonction Routes (emails entrants), ainsi que pour les messages envoyés ou auxquels il est répondu sur une liste de diffusion.

Dans l’exemple d’authentification ci-dessous, vous pouvez voir qu’en utilisant l’ARC, les résultats sont transmis à chaque étape par chaque serveur d’email tout au long de la chaîne. Et que les résultats sont définis pour chaque authentification réussie (DKIM, SPF et DMARC).

Des standards tels que l’ARC jouent un rôle crucial dans la protection contre les attaques d’hameçonnage et la garantie de l’intégrité des communications par email. En s’attaquant aux limites des authentifications existantes, l’ARC offre une solution pour valider la chaîne de messages, quels que soient les serveurs intermédiaires par lesquels un message peut transiter. Alors que les organisations continuent de donner la priorité à la sécurité des emails, l’adoption de l’ARC se généralisera.

Chez Sinch Mailgun, nous aimons garder une longueur d’avance, ce qui implique de vous tenir au courant des technologies émergentes et des actualités du secteur. Vous souhaitez rester dans la boucle ? N’oubliez pas de vous inscrire à notre newsletter pour ne rien manquer.

Auteur·trice: Em Blitstein Em Blitstein is a Sr. Content Marketing Manager at Sinch Mailgun. She manages the Mailgun Blog, curates top-notch content, and falls down SEO rabbit holes. She writes about all things email and loves a good dev deep dive.