Définir de quoi le réexpéditeur est responsable
Un service de repost authentifié reçoit un message et envoie une autre transaction SMTP . Cette description couvre différents services : un redirecteur d'adresses, une liste de discussion, une passerelle de sécurité ou une application qui redistribue le courrier. « Authentifié » est incomplet à moins qu'il ne nomme l'identité, le mécanisme et le saut de réception. Un service peut authentifier sa propre connexion sortante sans conserver l'authentification de l'auteur d'origine. La limite de responsabilité doit donc suivre le message tout au long du parcours, plutôt que suivre une étiquette de produit.
Commencez par un contrat de service écrit pour le flux de courrier. Identifiez qui accepte le message original, change l'enveloppe, modifie le contenu signé, gère les échecs de livraison et fournit des preuves au destinataire final. La carte de responsabilité proposée ci-dessous est une aide à la planification et non une observation d'un service déployé. Chaque opérateur doit être capable d'expliquer ses propres changements sans revendiquer le contrôle de la décision de filtrage d'un autre opérateur.
Séparez les trois questions d’identité
L'IP de connexion et SMTP expéditeur d'enveloppe importe pour SPF. Le domaine de signature et le contenu du message protégé sont importants pour DKIM. DMARC demande si un identifiant authentifié qualifiant s'aligne avec le domaine de l'auteur à partir du champ De du message. Le résultat SPF réussi d'un réexpéditeur pour son propre domaine d'enveloppe n'est pas automatiquement un résultat aligné pour un auteur original non lié. Ce sont des questions distinctes, même lorsqu'une interface utilisateur affiche une étiquette « authentifiée » rassurante. RFC 7208 , section 2.4 et RFC 9989 , section 4.4 définir les limites pertinentes.
La réécriture d'enveloppe peut rendre le transitaire responsable d'un nouveau chemin de retour et permettre SPF de décrire son infrastructure sortante. Il ne répare pas en soi l'auteur original alignement. De même, un nouveau Signature DKIM du remailer prouve quelque chose sur ce domaine de signature, pas nécessairement sur l'auteur original. Enregistrez les anciennes et les nouvelles identités afin qu'un analyste ultérieur puisse voir quelle relation a été préservée, remplacée ou perdue.
Propres modifications pouvant briser une signature
Un service qui ajoute un pied de page, modifie un champ Objet signé ou réencode du contenu protégé doit comprendre la signature DKIM appropriée et canonisation. Certaines transformations survivent à la canonisation choisie ; d'autres non. Ne présumez pas que chaque changement d'en-tête brise DKIM ou que la canonisation « détendue » permet des modifications arbitraires. Conservez une copie originale et comparez les en-têtes et le corps réellement signés lors du diagnostic d’un échec. RFC 6376 , sections 3.4 et 5.4 fournir le mécanisme, pas une promesse concernant un remailer particulier.
Les instructions de transfert de Google recommandent de protéger le contenu couvert par DKIM et indiquent que Gmail évalue lui-même les messages transférés. Il s'agit de conseils opérationnels spécifiques à Gmail et non d'un accord d'acceptation universelle. Un remailer reste responsable des modifications qu'il apporte, y compris une réécriture intentionnelle From utilisée par certaines conceptions de liste. Une telle réécriture modifie l'identité présentée aux destinataires et nécessite une décision explicite concernant les réponses et l'attribution. Conseils de transfert Google.
Traitez ARC comme une preuve avec une limite de confiance
ARC peut porter une évaluation d'authentification d'un intermédiaire et une chaîne de traitement vérifiable. Sa validation ne certifie pas un contenu inoffensif ni n'établit que chaque domaine de scellement est digne de confiance. Le destinataire final doit décider comment, le cas échéant, il utilisera ces informations. Conservez séparément la chaîne, les domaines d'étanchéité, l'évaluation du récepteur et la disposition locale. Un pass ARC ne remplace pas une entrée de remplacement pour un pass DKIM aligné. RFC 8617 , sections 7 et 9.
Le statut des normes nécessite également une date. Le 8 novembre 2026, RFC 8617 reste expérimentale. Le draft-ietf-dmarc-arc-to-historic-01 propose de mettre fin à l'expérience et de déplacer la RFC vers Historic ; il s’agit d’un travail en cours et non d’une reclassification promulguée. Une évaluation du service devrait divulguer cette proposition sans présenter comme un fait le déploiement universel ARC ou la retraite complète. Statut actuel du brouillon.
Suivez un message fictif à travers la frontière
Prenons un message fictif provenant de notices@sender.example , acheminé via un transitaire d'anciens élèves vers une boîte aux lettres finale. Supposons que le flux d'origine ait une signature DKIM alignée. Le transitaire change l'expéditeur de l'enveloppe en son propre domaine mais laisse le message protégé inchangé. La question attendue chez le destinataire final est de savoir si cette signature originale est toujours valide et alignée. Le résultat SPF de la nouvelle enveloppe répond à une question d’identité différente. Cet exemple est un exercice de raisonnement ; aucun message, réponse DNS ou résultat du récepteur n'a été collecté.
Supposons maintenant que le même service ajoute une clause de non-responsabilité concernant le corps. L'analyste doit comparer le contenu couvert par la signature avant et après cette étape. La propre signature d'un service ou Sceau ARC peuvent fournir des preuves supplémentaires, mais ni l’une ni l’autre ne doit être silencieusement décrite comme une restauration de la signature originale. Le travail correctif appartient en premier lieu à l'acteur qui a introduit la transformation concernée, tandis que l'expéditeur d'origine est toujours propriétaire de sa configuration de signature et que le destinataire est propriétaire de sa politique d'acceptation.
Accepter la responsabilité sans promettre la livraison
La responsabilité SMTP est transférée lorsque le serveur de réception donne une réponse d'achèvement positive après les données du message. Ce serveur est alors propriétaire de la livraison ou de la gestion appropriée des échecs ultérieurs. Cette responsabilité de transport diffère d'une promesse de placement dans la boîte de réception ou d'une authentification continue à chaque saut ultérieur. Un réexpéditeur doit conserver les identifiants de file d'attente, les horodatages et les enregistrements de diagnostic limités suffisants pour expliquer ce transfert. RFC 5321 , section 4.2.5.
RFC 9989 discute explicitement de l'interopérabilité des flux indirects et met en garde contre le traitement de la politique de domaine comme la seule entrée de disposition du récepteur. Examinez la participation à la liste et le transfert légitime lors de la planification de la politique de l'expéditeur, plutôt que d'exiger qu'un réexpéditeur garantisse le comportement de chaque destinataire. RFC 9989 , section 7.4.
Des preuves encore requises
Échantillons de livraison directe et indirecte avec comparaison de l'itinéraire, de l'enveloppe, des signatures et des résultats fiables. Cette exigence reste ouverte. Collectez des échantillons correspondants autorisés, marquez les résultats ajoutés par le récepteur fiable et comparez les identités et les modifications des sauts. La recherche de normes documentaires et le parcours fictif n'établissent pas le comportement d'un véritable service de repost.