Deliverability

Qu'est-ce que ARC (Authenticated Received Chain) ?

ARC permet aux serveurs qui transfèrent ou modifient un e-mail de conserver des enregistrements signés des résultats d'authentification antérieurs.

Un e-mail peut réussir l'authentification avant qu'une liste de diffusion ne le modifie. Le destinataire suivant a besoin de preuves de ce résultat antérieur pour distinguer un traitement légitime d'une usurpation d'identité.

Pourquoi un transfert légitime peut-il invalider l'authentification ?

Le transfert peut modifier le serveur d'envoi ou le contenu signé dont dépendent les vérifications d'authentification.

SPF vérifie si un serveur est autorisé pour le domaine d'expéditeur d'enveloppe utilisé pour les avis de non-remise. Un redirecteur peut se connecter depuis une IP non autorisée.

DKIM valide une signature associée à un domaine de signature. La signature peut survivre à un simple transfert. Une liste de diffusion qui modifie un Subject ou un corps signé peut l'invalider.

DMARC exige qu'un domaine SPF ou DKIM validé corresponde au domaine From visible. Cette correspondance s'appelle l'alignement. Si aucune des deux méthodes ne fournit une validation alignée, DMARC échoue même lorsque le message est légitime.

Qu'est-ce que ARC ajoute au message ?

Chaque intermédiaire participant ajoute trois en-têtes, appelés ensemble un jeu ARC.

En-têtePreuve fournie
ARC-Authentication-ResultsLes résultats d'authentification observés avant les modifications de l'intermédiaire
ARC-Message-SignatureUne signature sur le message tel que l'intermédiaire le transmet
ARC-SealUne signature protégeant le jeu ARC et la chaîne précédente

Le numéro d'instance i= ordonne les jeux. Le premier intermédiaire utilise i=1. Le suivant utilise i=2, rendant leur ordre explicite.

La valeur cv= du sceau enregistre la validation de la chaîne. La valeur none marque le premier jeu. La valeur pass enregistre une validation réussie d'une chaîne existante. La valeur fail enregistre un échec de validation.

La RFC 8617 décrit comment les destinataires vérifient l'intégrité de la chaîne. La vérification n'établit pas que l'évaluation déclarée par chaque intermédiaire est fiable.

Une chaîne valide garantit-elle la remise ?

Une chaîne ARC valide ne garantit pas la remise. Elle fournit des preuves pour la propre décision de traitement du destinataire.

Le destinataire décide s'il fait confiance aux intermédiaires qui ont fourni les preuves. Un intermédiaire inconnu ne devient pas fiable simplement parce qu'il produit une signature valide.

La spécification ARC est expérimentale, ce qui signifie qu'elle documente un protocole à évaluer plutôt qu'une spécification du chemin de normalisation Internet. La décision de remise reste contrôlée par le destinataire.

Qui doit implémenter ARC ?

Les redirecteurs et les listes de diffusion utilisent ARC pour préserver les preuves d'authentification à destination des destinataires en aval.

Votre rôleTâche concernée
Expéditeur d'origineAuthentifier votre courrier avec un domaine aligné
Redirecteur ou liste de diffusionÉvaluer la chaîne entrante et ajouter un jeu ARC lors du traitement du message
DestinataireValider les chaînes disponibles et décider quels intermédiaires sont fiables

Le guide d'envoi de Yahoo demande aux redirecteurs d'implémenter ARC. Cela peut aider les destinataires à évaluer le courrier légitime affecté par le transfert. Les destinataires décident toujours s'ils l'acceptent.

Si votre courrier direct échoue à DMARC, corrigez son authentification ou son alignement. L'ajout d'un sceau ARC ne corrige pas le décalage de domaine d'origine.

Que peut faire un expéditeur d'origine pour le courrier transféré ?

Un expéditeur d'origine peut fournir une signature DKIM alignée qui survit au transfert tant que le contenu signé reste intact.

Signez les en-têtes qui nécessitent une protection. Évitez une limite de longueur de corps qui laisse le contenu ajouté non signé. La page signature DKIM explique ces choix.

Si un intermédiaire ultérieur modifie le contenu signé, la préservation de la preuve du résultat antérieur nécessite la participation de cet intermédiaire. ARC lui donne un moyen d'enregistrer cette preuve. Le destinataire décide toujours du poids à lui accorder.

En bref

  1. Le transfert et les modifications peuvent affecter l'authentification.

    Un changement de serveur d'envoi peut invalider SPF. La modification du contenu signé peut invalider DKIM.

  2. Chaque intermédiaire participant ajoute un jeu ARC.

    Les trois en-têtes enregistrent les résultats d'authentification, signent le message sortant et scellent la chaîne.

  3. Une chaîne valide ne garantit pas la remise.

    Les destinataires décident s'ils font confiance aux intermédiaires et comment utiliser leurs preuves.

  4. Les expéditeurs d'origine et les intermédiaires ont des tâches différentes.

    Les expéditeurs d'origine authentifient leur courrier. Les intermédiaires peuvent préserver les preuves des résultats observés avant leurs modifications.

Développez sur le même réseau.

Une clé API de test est disponible immédiatement. La production est activée dès que vous ajoutez un moyen de paiement et vérifiez un expéditeur.

Votre prochaine idée.
Prête à se connecter.