Par défaut, SMTP n'authentifie pas l'expéditeur. Cela signifie qu’on peut usurper l’identité d’un autre utilisateur, ou faire du spam.
Des protocoles complémentaires au SMTP permettent de modifier son comportement. Classiquement, on peut autoriser (via le DNS) seulement quelques MTA à émettre des mails venant d’un domaine, et ces serveurs MTA peuvent autoriser seulement certains utilisateurs authentifiés à autoriser certaines adresses complètes.
Il existe plusieurs technologies permettant de contourner ce problème d’usurpation/de spam: SPF, DKIM et DMARC qui est une généralisation des deux premiers.
SPF vérifie que l’IP distante (celle qui a ouvert la connexion) a le droit d’émettre pour le domaine déclaré au protocole SMTP (par la commande MAIL FROM).
SPF permet au DNS d’indiquer à tous les MTA quels MTA sont autorisés à émettre des mails avec un certain domaine. Il suffit d’indiquer quelles adresses IP sont autorisées à émettre. Les serveurs implémentant SPF peuvent donc rejeter des mails ne provenant pas d’une adresse IP autorisée. Cependant, l’implémentation de SPF n’est pas obligatoire. Un email frauduleux peut donc traverser toute une chaîne de MTA et arriver dans une boîte de réception si aucun n’implémente SPF.
DKIM vérifie la signature d’un mail pour authentifier le domaine d’un mail. Pour DKIM, le domaine est une métadonnée incluse dans la signature.
DKIM (pour DomainKeys Identified Email) est un protocole qui permet d’authentifier le MTA de début de chaîne (émetteur), et de confirmer l’intégrité du message. Concrètement c’est un mécanisme de chiffrement asymétrique dont la clé publique est publiée dans le DNS. Chaque mail contient alors un condensat c1 de ses champs1) chiffrés à l’aide de la clé privée. Le déchiffrage de ce condensat c1 et la comparaison de celui-ci au condensat c2 fraîchement calculé des informations du mail permet de vérifier l’intégrité du message et de s’assurer que le mail a bien été envoyé par la source renseignée dans le mail. Comme c’est le MTA émetteur qui signe le message, il a évidemment la capacité de contrôler les utilisateurs qui peuvent émettre par lui. Par conséquent, tout mail signé par lui provient forcément de lui et d’un utilisateur en qui ce serveur a confiance.
Il s’agit d’un protocole qui modifie le comportement:
DKIM modifie le protocole SMTP au niveau du contenu du fichier mail qui est transmis (couche application).
À noter : sous Debian, OpenDKIM peut s’intégrer dans le flux de données de Postfix.
DMARC vérifie la concordance des domaines trouvés par SPF et DKIM avec le domaine de l’en-tête From:.
Cette en-tête fait partie du contenu du mail; du point de vue de SMTP, elle est “à l’intérieur de l’enveloppe”, c’est-à-dire dans la charge utile. Ce n’est pas une métadonnée au sens de SMTP. (Elle n’est pas nécessaire au bon déroulement du protocole SMTP; mais c’est une métadonnée au sens de MIME et Internet Message Format: c’est l’adresse affichée par le client quand il lit un mail).
Cependant, de nombreux serveurs SMTP se permettent de lire (voire d’écrire) des en-têtes de mail. Quand DKIM signe un mail, il rajoute une en-tête.
DMARC tire parti de SPF et DKIM pour définir des politiques à appliquer sur les mails entrants. Elle permet au propriétaire du domaine expéditeur d’indiquer quels mécanismes de protection sont en vigueur (SPF, DKIM) et que faire en cas d’échec de l’authentification (les faire passer quand même, prévenir l’administrateur par mail, etc.). DMARC permet aussi d’autres vérifications, la plus importante est l’alignment. “L’alignement” renforce SPF et DKIM:
MAIL FROM, dans le protocole SMTP. Donc c’est aussi une vérification de la cohérence entre deux couches).Les politiques de l’expéditeur sont publiées via DNS, et les politiques sur les mails entrants (qui peuvent remplacer les politiques de l’expéditeur ou en être complémentaires) sont définies via la configuration des logiciels utilisés sur le MTA de bout de chaîne.
DANE est une solution complémentaire aux protocoles DNSSEC et SSL/TLS actuels. Ce protocole prévoit d’inclure dans l’enregistrement DNS d’un nom de domaine le certificat SSL/TLS de celui-ci. Une description plus détaillée est disponible ici : Le protocole DANE (DNS - based Authentication of Named Entities) pour la sécurisation de bout-en-bout.