Aller au contenu principal

Appendix D. SPF/Mediator Interactions (Interactions SPF/Médiateur)

Appendix D. SPF/Mediator Interactions (Interactions SPF/Médiateur)​

Cette annexe discute de l'interaction entre SPF et les médiateurs de messagerie (comme les listes de diffusion et les services de transfert) et de leurs impacts.

D.1 Originating ADMDs (ADMD d'origine)​

L'ADMD d'origine est le domaine administratif qui envoie initialement le courrier. En présence de médiateurs, l'ADMD d'origine doit considérer les services de transfert et de listes par lesquels ses courriers peuvent passer.

D.1.1 Identification du problème​

Hypothèse de base SPF:

  • Les courriers sont envoyés directement des serveurs autorisés aux destinataires
  • L'identité MAIL FROM reste inchangée
  • L'adresse IP d'envoi est autorisée dans l'enregistrement SPF

Hypothèses brisées par les médiateurs:

  • Les courriers passent par des systèmes intermédiaires
  • Peuvent être renvoyés depuis une adresse IP différente
  • MAIL FROM peut être modifié ou rester inchangé

D.1.2 Choix pour l'expéditeur​

Option 1: Utiliser une politique SPF souple

example.com IN TXT "v=spf1 mx ~all"

Avantages:

  • Permet le transfert légitime
  • Réduit les faux positifs

Inconvénients:

  • Affaiblit la protection SPF
  • Plus facile à usurper

Option 2: S'appuyer sur d'autres méthodes d'authentification

Publier des signatures DKIM:
- DKIM reste valide lors du transfert
- Indépendant de l'adresse IP d'envoi
- Fonctionne avec DMARC

Option 3: Accepter les échecs SPF

example.com IN TXT "v=spf1 mx -all"
  • Accepter que certains courriers légitimes puissent être marqués ou rejetés
  • Compter sur les utilisateurs pour utiliser la bonne méthode d'envoi
  • Recommander aux utilisateurs de ne pas transférer mais d'utiliser "Envoyer une copie"

D.1.3 Meilleures pratiques​

Configuration recommandée:

1. Publier un enregistrement SPF strict (-all)
2. Implémenter simultanément la signature DKIM
3. Publier une politique DMARC
4. Éduquer les utilisateurs sur les problèmes de transfert

Exemple de configuration DMARC:

_dmarc.example.com IN TXT "v=DMARC1; p=quarantine; sp=quarantine; adkim=r; aspf=r; pct=100; rua=mailto:[email protected]"

Explication des paramètres:

  • adkim=r: Alignement DKIM souple
  • aspf=r: Alignement SPF souple
  • p=quarantine: Mettre en quarantaine en cas d'échec

D.2 Mediators (Médiateurs)​

Les médiateurs sont des systèmes qui modifient ou renvoient des courriers dans la chaîne de transmission. Les médiateurs courants incluent les listes de diffusion, les services de transfert et les systèmes de réponse automatique.

D.2.1 Listes de diffusion​

Problème:

Les listes de diffusion traditionnelles conservent le MAIL FROM original:

Original: MAIL FROM:`<[email protected]>`
Après liste: MAIL FROM:`<[email protected]>`
IP d'envoi: list-server.mailinglist.org

Vérification SPF:

Interroger l'enregistrement SPF d'example.com
Vérifier l'IP de list-server.mailinglist.org
Résultat: fail (IP n'est pas dans l'enregistrement SPF d'example.com)

D.2.2 Solutions​

Solution 1: Réécrire MAIL FROM (recommandé)

Réécrit: MAIL FROM:`<[email protected]>`
Reply-To: [email protected]

Avantages:

  • La vérification SPF réussit
  • Les rebonds reviennent au serveur de liste
  • Le destinataire peut identifier correctement

Inconvénients:

  • Modifie les informations de l'expéditeur original
  • Les utilisateurs doivent s'adapter à Reply-To

Exemple d'implémentation (Mailman):

# Configuration Mailman
from_is_list = 2  # Munge From, add Reply-To

Solution 2: Utiliser SRS (Sender Rewriting Scheme)

SRS est un schéma de réécriture plus complexe:

Original: [email protected]
Réécrit en: [email protected]

Format SRS:

SRS0=<hash>=<timestamp>=<domain>=<localpart>@<forwarder>

Exemple:
[email protected]

Avantages:

  • Préserve les informations de l'expéditeur original (dans le local-part)
  • La vérification SPF réussit
  • Peut être tracé et vérifié

Inconvénients:

  • Implémentation complexe
  • Nécessite une base de données SRS
  • Le local-part devient difficile à lire

Solution 3: Utiliser DKIM au lieu de SPF

Configuration:

1. L'expéditeur original utilise la signature DKIM
2. Le serveur de liste conserve la signature originale
3. Le serveur de liste ajoute sa propre signature DKIM
4. Le destinataire vérifie DKIM (ignore l'échec SPF)

Configuration DMARC:

_dmarc.example.com IN TXT "v=DMARC1; p=none; adkim=r; aspf=r"
  • p=none: Pas d'application (permet l'échec SPF)
  • adkim=r: Alignement DKIM souple (permet la signature de liste)

D.2.3 Services de transfert de courrier​

Type 1: Transfert simple

Configuration utilisateur: [email protected] → [email protected]
Le service de transfert conserve: MAIL FROM:`<[email protected]>`
Envoie depuis l'IP du serveur de transfert

Problème SPF:

Gmail vérifie le SPF d'original.com
L'IP du serveur de transfert n'est pas dans l'enregistrement SPF
Résultat: fail

Solution A: Réécriture SRS

Le service de transfert utilise SRS:
MAIL FROM:<[email protected]>

Solution B: Utiliser ~all au lieu de -all

original.com IN TXT "v=spf1 mx ~all"

Les courriers transférés obtiendront softfail au lieu de fail, plus susceptibles d'être acceptés.

Type 2: Fichier .forward

# ~/.forward
[email protected]

Problème identique au transfert simple.

Meilleures pratiques:

1. Les services de transfert devraient implémenter SRS
2. L'expéditeur original devrait utiliser DKIM
3. Les destinataires devraient considérer les résultats DKIM, pas seulement SPF

D.2.4 Systèmes de réponse automatique et de notification​

Problème:

Courrier original: [email protected] → [email protected]
Réponse automatique: MAIL FROM:`<[email protected]>`
         (Envoyé depuis le serveur company.com)

La vérification SPF échouera.

Solution:

Envoyer des notifications avec MAIL FROM vide:
MAIL FROM:<>
From: Mail Delivery System `&lt;[email protected]&gt;`

Ou:

Utiliser une adresse locale:
MAIL FROM:`&lt;[email protected]&gt;`
From: Automatic Reply `&lt;[email protected]&gt;`
Reply-To: [email protected]

D.3 Receiving ADMDs (ADMD destinataires)​

L'ADMD destinataire doit gérer les courriers provenant de médiateurs et prendre des décisions appropriées.

D.3.1 Identification des courriers de médiateurs​

Identifiants:

1. Sauts intermédiaires dans les en-têtes Received
2. En-têtes List-* (listes de diffusion)
3. Precedence: bulk ou list
4. MAIL FROM au format SRS
5. Signature DKIM d'un service de liste connu

Exemple de logique de détection:

def is_mailing_list(message):
    # Vérifier les en-têtes List-*
    list_headers = [
        'List-Id', 'List-Post', 'List-Unsubscribe',
        'List-Help', 'List-Subscribe', 'List-Owner'
    ]
    
    for header in list_headers:
        if message.get(header):
            return True
    
    # Vérifier Precedence
    if message.get('Precedence') in ['bulk', 'list']:
        return True
    
    # Vérifier SRS
    mail_from = message.get('Return-Path', '')
    if mail_from.startswith('SRS0=') or mail_from.startswith('SRS1='):
        return True
    
    return False

D.3.2 Recommandations de politique​

Politique 1: Traitement souple des courriers de liste

if is_mailing_list(message):
    if spf_result == 'fail':
        # Vérifier DKIM
        if dkim_result == 'pass':
            accept_message()
        else:
            # Vérifier la réputation de la liste
            if list_is_trusted(list_id):
                accept_message()
            else:
                quarantine_message()

Politique 2: S'appuyer sur DMARC

if dmarc_result == 'pass':
    accept_message()
elif spf_result == 'fail' and dkim_result == 'fail':
    reject_message()
else:
    # SPF ou DKIM réussit
    if is_mailing_list(message):
        accept_message()
    else:
        apply_content_filtering()

Politique 3: Règles spécifiques à l'utilisateur

Les utilisateurs peuvent configurer des listes blanches:
- Listes de diffusion de confiance
- Adresses de transfert connues
- Traitement souple de domaines spécifiques

D.3.3 Recommandations d'implémentation​

Configuration SpamAssassin:

# Traitement souple des listes de diffusion
header LIST_ID exists:List-Id
score LIST_ID -0.1

# SPF fail mais avec en-tête List-Id
meta SPF_FAIL_LIST (SPF_FAIL && LIST_ID)
score SPF_FAIL_LIST 0.5

# SPF fail normal (sans en-tête de liste)
score SPF_FAIL 5.0

Configuration Postfix:

# smtpd_recipient_restrictions
reject_unauth_destination,
check_policy_service unix:private/spf-policy,
permit

# Le service de politique SPF peut identifier les courriers de liste et s'adapter

Configuration rspamd:

-- Configuration du module SPF
spf {
  -- Appliquer un poids différent pour les listes de diffusion
  symbol_fail = "R_SPF_FAIL";
  symbol_softfail = "R_SPF_SOFTFAIL";
  
  -- Règles personnalisées
  custom_symbols = {
    R_SPF_FAIL_LIST = {
      score = 2.0,
      description = "SPF failed but from mailing list",
      condition = function(task)
        local spf = task:get_symbol('R_SPF_FAIL')
        local list_id = task:get_header('List-Id')
        return spf and list_id
      end
    }
  }
}

D.4 Recommandations d'interopérabilité​

D.4.1 Standardisation​

Utiliser des en-têtes standard:

Les listes de diffusion devraient ajouter:
- List-Id: &lt;list-name.domain.com>
- List-Post: &lt;mailto:[email protected]>
- List-Unsubscribe: &lt;mailto:[email protected]>
- Precedence: bulk

Signature DKIM:

Les serveurs de liste devraient:
1. Conserver la signature DKIM originale (si présente)
2. Ajouter leur propre signature DKIM
3. Ne pas modifier les en-têtes signés

D.4.2 Communication​

Notification de l'expéditeur:

Le service de liste devrait informer les abonnés:
- Les courriers seront renvoyés depuis le serveur de liste
- MAIL FROM sera réécrit
- Recommandation d'utiliser Reply-To pour répondre à la liste

Documentation du destinataire:

Documenter les politiques de réception:
- Comment les courriers de liste sont traités
- Mécanisme de liste blanche
- Options configurables par l'utilisateur

D.5 Direction du développement futur​

D.5.1 ARC (Authenticated Received Chain)​

RFC 8617 a introduit ARC:

ARC permet aux médiateurs d'ajouter des informations d'authentification:
- ARC-Seal: Signature du médiateur
- ARC-Message-Signature: Signature du message
- ARC-Authentication-Results: Résultats d'authentification

Exemple:

ARC-Seal: i=1; a=rsa-sha256; t=1234567890; cv=none;
    d=mailinglist.org; s=arc-seal; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
    d=mailinglist.org; s=arc-msg; h=from:to:subject; b=...
ARC-Authentication-Results: i=1; mailinglist.org;
    spf=pass [email protected];
    dkim=pass header.d=example.com

Avantages:

  • Préserve les résultats d'authentification originaux
  • Permet la vérification en chaîne
  • Les destinataires peuvent faire confiance aux médiateurs

D.5.2 Recommandations​

Pour les nouveaux déploiements:

  1. Implémenter DKIM et SPF
  2. Publier une politique DMARC
  3. Considérer le support ARC (si médiateur)
  4. Tester l'interopérabilité avec les listes de diffusion courantes

Pour les systèmes existants:

  1. Examiner la rigueur des politiques SPF
  2. Surveiller les rapports DMARC
  3. Identifier les sources problématiques (listes, transferts, etc.)
  4. Ajuster les politiques ou implémenter SRS
Dernière mise à jour le