10. Autres Sujets

Cette section traite de divers sujets liés au déploiement et au fonctionnement de DMARC.

10.1. Problèmes Spécifiques à SPF

SPF présente certains problèmes lorsqu'il est utilisé avec DMARC dont les propriétaires de domaines et les récepteurs de courrier doivent être conscients:

1. Authentification uniquement par SPF: Si un propriétaire de domaine publie uniquement une politique SPF et non une politique DKIM, tous les transferts de courrier (où le domaine RFC5321.MailFrom change) entraîneront des échecs d'Identifier Alignment.

2. Listes de diffusion: De nombreuses listes de diffusion utilisent le domaine de l'auteur d'origine dans le champ RFC5322.From mais changent le domaine RFC5321.MailFrom pour le leur. Cela rompt l'Identifier Alignment SPF.

3. Transferts: Le simple transfert (où un utilisateur transfère un courrier vers une autre adresse) ne change pas le domaine RFC5321.MailFrom mais peut causer des échecs SPF car l'adresse IP du serveur de transfert n'est pas listée dans l'enregistrement SPF du domaine d'origine.

10.2. Charge DNS et Mise en Cache

Les implémenteurs de DMARC doivent être conscients des considérations suivantes liées au DNS:

1. Volume de requêtes: Les récepteurs de courrier interrogeront le DNS pour les enregistrements DMARC pour chaque message soumis à l'évaluation DMARC. Les récepteurs à volume élevé doivent implémenter des stratégies de mise en cache appropriées.

2. Mise en cache: Les enregistrements DNS pour les politiques DMARC doivent être mis en cache selon leurs valeurs TTL (Time To Live). Les propriétaires de domaines doivent définir des valeurs TTL appropriées:

   • TTL courts (par exemple, 300 secondes) pendant le déploiement ou les modifications de politique
   • TTL plus longs (par exemple, 86400 secondes) pour les politiques stables

3. Mise en cache négative: L'absence d'un enregistrement DMARC doit également être mise en cache selon le TTL de cache négatif de l'enregistrement SOA.

10.3. Rejet de Messages

Lorsqu'une politique DMARC indique qu'un message doit être rejeté, les récepteurs de courrier doivent considérer ce qui suit:

1. Rejet SMTP vs. Post-SMTP:

   • Le rejet SMTP (pendant la transaction SMTP) est préféré car il fournit un retour immédiat au MTA émetteur et ne nécessite pas de générer un message de rebond.
   • Le rejet Post-SMTP (après avoir accepté le message) doit être évité car il peut conduire au backscatter.

2. Codes de rejet: Lors du rejet pendant SMTP, utilisez des codes de réponse SMTP 5xx appropriés. Un message approprié pourrait être:

   550 5.7.1 Message rejected per DMARC policy for example.com

3. Notification utilisateur: Considérez si vous devez notifier les utilisateurs légitimes si leurs messages sont rejetés en raison d'échecs DMARC.

10.4. Considérations sur l'Identifier Alignment

Plusieurs considérations s'appliquent à l'Identifier Alignment:

1. Alignment des sous-domaines: En mode relaxed, les sous-domaines sont considérés comme alignés. Les propriétaires de domaines doivent être conscients que cela signifie que le courrier de n'importe quel sous-domaine sera considéré comme aligné si SPF ou DKIM réussit pour le domaine organisationnel.

2. Expéditeurs tiers: Lors de l'utilisation de services de courrier électronique tiers, les propriétaires de domaines doivent s'assurer que:

   • Le tiers peut envoyer des messages signés DKIM avec le domaine du propriétaire de domaine dans la balise "d=", OU
   • Les adresses IP d'envoi du tiers sont incluses dans l'enregistrement SPF du propriétaire de domaine, et le domaine RFC5321.MailFrom peut être configuré pour être aligné

3. Sources d'envoi multiples: Les propriétaires de domaines avec plusieurs sources d'envoi (serveurs de messagerie internes, services de marketing par courrier électronique, systèmes CRM, etc.) doivent s'assurer que toutes les sources peuvent produire des messages alignés.

10.5. Problèmes d'Interopérabilité

Le déploiement de DMARC peut causer des problèmes d'interopérabilité avec certaines pratiques de courrier électronique:

1. Listes de diffusion:

   • Problème: Les listes modifient souvent les messages (ajout de pieds de page, balises de sujet, etc.) ce qui rompt les signatures DKIM
   • Solutions:
     • Les listes peuvent re-signer les messages avec leur propre signature DKIM
     • Les listes peuvent réécrire l'adresse RFC5322.From (mais cela change l'expéditeur apparent)
     • Les propriétaires de domaines peuvent utiliser une politique plus souple pour les domaines utilisés sur les listes de diffusion

2. Transfert:

   • Problème: Le transfert rompt SPF (l'IP du serveur de transfert n'est pas autorisée)
   • Solutions:
     • S'appuyer sur DKIM (qui survit au transfert si le contenu n'est pas modifié)
     • Les redirecteurs peuvent implémenter SRS (Sender Rewriting Scheme)

3. Flux de courrier indirects: Tout flux de courrier où les messages sont modifiés ou relayés par des intermédiaires peut avoir des problèmes DMARC. Voir [DMARC-INDIRECT] pour une discussion détaillée.

4. Messages de notification: Les systèmes de notification automatisés doivent être configurés pour utiliser des identifiants alignés ou peuvent avoir besoin d'utiliser un domaine de politique "p=none".

---