Sender Policy Framework (SPF) était à l'origine Sender Permitted From.

SPF est donc une méthode d'authentification des emails destinée à détecter les adresses de courriel sources forgées dans un courriel.

Cependant, SPF ne s'applique qu'à l'enveloppe du message (donc le champ MAIL-FROM ou RETURN-PATH d'un courriel), et non au contenu du message (le champ FROM).

SPF fonctionne en déclarant un enregistrement spécial de type TXT dans le DNS qui liste les serveurs autorisés à envoyer du courriel pour la zone/domaine en question.

Avec SPF, je pourrai par exemple dire que l'IP 184.107.112.64 est autorisée à envoyer les emails du domaine yerbynet.com, et interdire toute autre IP.

Ainsi, si un serveur (qui respecte SPF) reçoit un courriel qui a un champ MAIL-FROM de la forme email@yerbynet.com devra vérifier que le courriel a comme origine 184.107.112.64 avant de l'accepter.

1.1 - Enregistrement SPF

Exemple 1:

"v=spf1 ip4:184.107.112.64  -all"

• all : correspond à tout le monde. On le met à la fin de l'enregistrement pour qu'il est le sens "tout le reste".
• a : correspond à lIP (v4 ou v6) associé au domaine
• mx : correspond aux MX du domaine
• ip4: permet de spécifier un CIDR IPv4 accepté (exemple : ipv4:69.63.184.0/25)
• include : include d'autres enregistrements SPF valides
• redirect : redirect vers un autre enregistrement SPF valide
• ptr : permet de tricher avec le PTR (exemple : ptr:yahoo.com - si le reverse de l'IP du serveur emetteur est dans le domaine yahoo.com, c'est validé).

Les quantificateurs :

En SPF, on n'a pas encore accès au contenu du message, on se sert donc des entêtes et notamment des champs MAIL FROM et RETURN-PATH de l'enveloppe.

Il y a 2 modes d'alignement :

• Strict (s) : Dans le mode strict, il faut que le domaine dans le "MAIL FROM" soit exactement le même que le domaine déclaré dans l'enregistrement SPF.

• Relatif (r) : Dans le mode relatif, le domaine dans le "MAIL FROM" peut être exactement le même que le domaine déclaré dans l'enregistrement SPF ou un sous domaine.

1.3 - Authentification SPF

L'authentification SPF passe (ou est valide) lorsque l'IP du serveur du courriel est déclarée dans l'enregistrement SPF.

Exemple de succès d'authentification SPF :

	Adresse source = 184.107.112.64
	MAIL FROM = yerbynet.com
	Enregistrement SPF = "v=spf1 +a +mx +ip4:184.107.112.64 ~all"

Exemple d'échec d'authentification SPF :

DomainKeys Identified Mail (DKIM) est tout comme SPF, une technique d'authentification des expéditeurs de courriels contribuant à détecter les adresses d'expéditeur forgées.

Avec DKIM, un serveur récepteur de courriel aurait les moyens de valider qu'un courriel reçu provient bien d'un serveur qui a l'autorisation de le transmettre.

Le serveur émetteur du message signe le message ou partie du message avec une clé privée, le récepteur décrypte la signature avec une clé publique publiée dans le DNS.

Il faut donc un enregistrement DNS qui contient cette clé publique.

À noter que la paire de clé peut être générée avec les commandes ssh-keygen ou openssl. Il y a aussi plein de générateurs présents sur Internet.

openssl genrsa -out dkimexemple.com-priv.pem 2048 -outform PEM
openssl rsa -in dkimexemple.com-private.pem -out dkimexemple.com-pub.pem -pubout -outform PEM

Avant de continuer, il faut regarder le concept de sélecteur (s).

Pour un domaine, on peut avoir plusieurs serveurs qui sont autorisés à envoyer des emails du domaine, donc plusieurs signataires pour le domaine.

On pourrait même imaginer des partenaires externes qui ont le droit d'envoyer des emails pour notre domaine.

On ne voudrait pas partager une clé privée entre tous les acteurs, il nous faut donc pouvoir déclarer plusieurs enregistrements pour notre DKIM.

Par exemple, un pour notre serveur d'envoi principal, un pour notre partenaire de marketing, un autre pour ...

Le sélecteur permettra donc d'avoir autant de _domainkey qu'on souhaite.

• p : Le plus important des paramètres puisque c'est lui qui conserve la clé publique
• v : la version actuelle qui DKIM (facultatif)
• k : le type de clé (RSA par défaut)
• h : algorithmes de HASH acceptés (tous par défaut)

Avec DKIM, on a accès au corps du courriel (FROM).

Comme pour SPF, il y a 2 modes d'alignement :

• Strict (s) : Dans le mode strict, il faut que le domaine dans le champ d de la signature DKIM soit exactement le même que le domaine du FROM.

• Relatif (r) : Dans le mode relatif, ces deux domaines peuvent être exactement les même ou bien l'un est un sous domaine de l'autre.

DKIM-Signature: v=1; a=rsa-sha256; ... d=yerbynet.com; ...
From: dmarc@yerbynet.com
To: roger.yerbanga@out.com

• L'authentification DKIM consiste alors à :
  • récupérer l'enregistrement DNS 200608._domainkey.engage.windows.com
  • extraire la clé publique de cet enregistrement
  • déchiffrer la signature
  • et s'assurer que le texte signé par la source est pareil au texte déchiffré (par la destination).

• En gros, il s'agit de s'assurer que le message a été signé et que la signature est bien authentifiée.

Sendmail ne supporte pas nativement DKIM, il faut lui adjoindre un milter pour cette fonction.

Il existe Opendkim sous Linux qui s'installe facilement (paquet RPM et DEB).

Toute la config se fait dans /etc/opendkim.conf.

Un logiciel tel que Exim4 n'a pas besoin de Opendkim pour signer les messages sortants.

Un logiciel tel que SpamAssassin a un plugin qui permet de checker DKIM, mais encore une fois, les scores proposés par défaut sont assez bas.

3 - DMARC

3.1 - Enregistrement DMARC

Les paramètres du RR DMARC :

• Politique à none, ils sont en mode observation

"v=DMARC1; p=none; rua=mailto:d@rua.agari.com;ruf=mailto:d@ruf.agari.com;fo=1:s:d"

• Politique à reject et à 100%. Google et Microsoft sont très très sûrs de leur coup.

_dmarc.engage.windows.com. 3600    IN    TXT    "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com,mailto:sdc-dmarc-rua@microsoft.com;fo=1"

_dmarc.google.com.    300    IN    TXT    "v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

• Dans le SPF, on s'assure qu'aucune IP n'est autorisée pour ce domaine, et dans le DMARC, on rejette tout ce qui échoue (or tout va échoue).

interdit.net. TXT "v=spf1 -all" ; SPF
_dmarc.interdit.net.   TXT "v=DMARC1;p=reject;sp=reject;pct=100;aspf=s" ; DMARC

    Pour ce cas, aucun email ne devra être accepté pour le domaine interdit.net.

3.2 - Validations DMARC

Les mails sortants doivent être signés DKIM et être émis depuis un serveur qui a le droit parce qu'il est déclaré dans un SPF.

Delivered-To: yerbynet@gmail.com
Received: by 2002:a17:906:c053:0:0:0:0 with SMTP id bm19csp725743ejb;
        Wed, 27 Mar 2019 13:53:57 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJwHJ9ainivb4IrUuD7ekGDAUFvQYhjbbMHvuD84xJgPVhwkCOmjYtyl5uGY9OgqRtTR6m2k
X-Received: by 2002:a37:9b88:: with SMTP id d130mr25306374qke.66.1600289637342;
        Wed, 27 Mar 2019 13:53:57 -0700 (PDT)
Return-Path: <bounce-15_HTML-1504463008-800977-7279955-70@bounce.engage.windows.com>
Received: from mta3.engage.windows.com (mta3.engage.windows.com. [136.147.186.54])
        by mx.google.com with ESMTPS id z11si12558663qvm.116.2019.03.27.13.53.56
        for <yerbynet@gmail.com>
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Wed, 27 Mar 2019 13:53:57 -0700 (PDT)
Received-SPF: pass (google.com: domain of bounce-15_html-1504463008-800977-7279955-70@bounce.engage.windows.com designates 136.147.186.54 as permitted sender) client-ip=136.147.186.54;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@engage.windows.com header.s=200608 header.b=lcunZVqq;
       spf=pass (google.com: domain of bounce-15_html-1504463008-800977-7279955-70@bounce.engage.windows.com designates 136.147.186.54 as permitted sender) smtp.mailfrom=bounce-15_HTML-1504463008-800977-7279955-70@bounce.engage.windows.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=engage.windows.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=200608; d=engage.windows.com;
 h=From:To:Subject:Date:MIME-Version:Reply-To:List-ID:X-CSA-Complaints:
 Message-ID:Content-Type; i=email@engage.windows.com;
 bh=EehLaLunvBo17WnrX4bGFrWtLrrgvqSsHeOwNAPIO0I=;
 b=lcunZVqqn77wO3ZIhU4LDR3PwUdZKSyifj1r3Eg+A6DkrjFvnpkKSaIW43O2roBfAnWW0FRhwnWe
   Kq4vupEcVErHUvfuYvMaG1IgUzZXb7k6uLZ+3b0xQRPWFiMansw/9CShGbs2neH9aEEnaznqB++h
   3piwcvUMXq5MQe/XcK0=
Received: by mta3.engage.windows.com id hc9tma2fmd47 for <yerbynet@gmail.com>; Wed, 27 Mar 2019 20:53:46 +0000 (envelope-from <bounce-15_HTML-1504463008-800977-7279955-70@bounce.engage.windows.com>)
From: "Microsoft Account Team" <email@engage.windows.com>
To: <yerbynet@gmail.com>

Ce courriel envoyé de engage.windows.com vers gmail.com a bien passé les validations SPF, DKIM, et DMARC.

4- SRS (Sender Rewriting Scheme)

DMARC/DKIM/SPF viennent avec des limites et d'autres problèmes à résoudre.

Notamment, on aura de gros souci avec tout ce qui est redirection, ou même des listes de discussions.

Je ne vais pas trop m'atarder sur le sujet, le lecteur intéressé pourra trouver de la lecture sur Internet et discuter avec Stuart D. Gathman.

Pour résoudre ce problème, on va utiliser SRS.

SRS permet de la réécriture des entêtes de courriel pour rendre conforme à SPF tout courriel qui est transféré.

J'ai fait des tests avec la solution pysrs, on peut dire que les tests étaient concluants.

Sources :