Outils pour utilisateurs

Outils du site


services:dkim

DomainKeys Identified Mail

DKIM est une norme liée au courrier électronique qui ajoute une identification du nom de domaine de l'expéditeur d'un message. Elle permet ainsi de responsabiliser les fournisseurs de service et de lutter contre les usurpations d'adresses électroniques.

Description

Avec DKIM, le serveur expédiant un message y ajoute une signature cryptographique avec une clef liée à son nom de domaine.

Un serveur recevant un message récupère par DNS la clef publique correspondant au nom de domaine de l'expéditeur, et vérifie le signature cryptographique éventuelle :

  • s'il y a une signature valide, le message est considéré comme authentifié1) ;
  • s'il n'y a aucune signature :
    • si le nom de domaine précise que tous ses messages sont censés être signé, le message peut être considéré comme frauduleux,
    • si le nom de domaine ne précise pas de politique particulière, le message peut être considéré comme non authentifié ;
  • s'il y a une signature invalide, le message peut être considéré comme frauduleux, c'est à qu'il s'agit d'un faux ou qu'il a été modifié en chemin.

Syntaxe

Clefs DKIM

Un nom de domaine peut avoir plusieurs clefs DKIM, associées à différents sélecteurs : c'est utile lorsqu'un même nom de domaine est utilisé par plusieurs services, éventuellement sous-traités ; lorsque ce n'est pas utile on utilise un sélecteur par défaut. Ces clefs DKIM d'un nom de domaine se publient dans le DNS au moyen d'enregistrements de type TXT.

Ainsi, l'enregistrement suivant indique la clef DKIM associée au sélecteur default pour le nom de domaine example.com :

default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS…wIDAQAB"

Cet enregistrement se compose des éléments suivants :

  • dans le nom de domaine :
    • default est le sélecteur, qui identifie cette clef particulière — il pourrait y en avoir d'autres pour example.com,
    • _domainkey, obligatoire, permet de distinguer ce nom de domaine d'un nom d'hôte ou de service quelconque,
    • example.com indique le nom de domaine administratif auquel cette clef appartient ;
  • dans le contenu :
    • v=DKIM1 indique la norme utilisée : DKIM, version 1,
    • k=rsa indique l'algorithme de la clef,
    • p=… indique la clef elle-même.

Politique de signature

Un nom de domaine peut publier une politique de signature ADSP, qui indique la façon dont il utilise DKIM, en précisant par exemple que tous les messages sont censés être signés, voire même que les messages non signés ou avec une signature incorrecte doivent être jetés. Une telle politique se publie dans le DNS au moyen d'un enregistrement de type TXT, par exemple :

_adsp._domainkey.example.com. TXT "dkim=all"

Cet enregistrement se compose des éléments suivants :

  • dans le nom de domaine :
    • _adsp._domainkey, obligatoire, indique qu'il s'agit d'une politique ADSP,
    • example.com indique le nom de domaine administratif auquel cette politique correspond ;
  • dans le contenu, dkim=all indique que tous les message sont censés être signés ; les valeurs possibles sont :
    • unknown les messages peuvent être ou ne pas être signés2),
    • all tous les messages sont censés être signés,
    • discardable les messages non signés ou avec une signature incorrecte peuvent être jetés.

Exemple

Voici le genre de requêtes DNS faites par le serveur SMTP destinataire pour récupérer la clef publique de l'émetteur et sa politique (en supposant que le courriel est issu du domaine example.com :

# dig default._domainkey.example.com TXT
;; ANSWER SECTION:
default._domainkey.example.com. 10800 IN TXT    "v=DKIM1\; k=rsa\; p=MIGfMA0GCS…wIDAQAB"

# dig _adsp._domainkey.example.com TXT
;; ANSWER SECTION:
_adsp._domainkey.example.com. 10800 IN  TXT     "dkim=all"

Avant la mise en place d'une politique DKIM, les serveurs SMTP qui recoivent un courriel du domaine example.com ajouteront cet en-tête au courriel :

Authentication-Results: smtp.destinataire.example.org  from=example.com;
domainkeys=neutral (no sig);  from=example.com; **dkim=neutral** (no sig)

Après la mise en œuvre d'une politique DKIM :

Authentication-Results: smtp.destinataire.example.org  from=example.com;
domainkeys=neutral (no sig);  from=example.com; **dkim=pass** (ok)

Mise en œuvre

DKIM peut être utilisé de deux façons :

  • pour vérifier les signatures DKIM des messages reçus ;
  • pour signer les messages envoyés.

Dans les deux cas, cela nécessite un module spécialisé de votre serveur de courrier. Les implémentations de DKIM prennent généralement en charge ces deux modes ; je vous conseille OpenDKIM qui est l'implémentation libre la plus avancée de DKIM : c'est un module milter, qui peut s'intégrer à la plupart des serveurs de courrier modernes.

Intégrer OpenDKIM au serveur de courrier

Installez OpenDKIM, vérifiez qu'il est bien lancé. La suite dépend de votre serveur de courrier.

Postfix

Le serveur SMTP de Postfix tourne souvent dans un chroot : il faut configurer OpenDKIM pour qu'il écoute sur un socket à l'intérieur de ce chroot. Sous Debian, cela se configure dans /etc/default/opendkim :

opendkim
SOCKET="local:/var/spool/postfix/var/run/opendkim/opendkim.sock" # Postfix' chroot

Après cela, créez le répertoire en question puis relancez OpenDKIM :

# install -o opendkim -g opendkim -d /var/spool/postfix/var/run/opendkim/
# service opendkim restart

Configurez enfin Postfix pour qu'il utilise OpenDKIM, dans /etc/postfix/main.cf :

main.cf
smtpd_milters = unix:/var/run/opendkim/opendkim.sock
non_smtpd_milters = unix:/var/run/opendkim/opendkim.sock

Postfix chiffrera chaque courrier sortant et vérifiera la signature des courriers entrants, le tout en communiquant avec OpenDKIM par le socket que nous venons de définir. Ce rôle doit être joué pour le courrier soumis au démon smtpd ou celui envoyé par la commande sendmail, d'où les deux directives paramétrées dans la configuration de Postfix.

Finalement, ajoutez Postfix au groupe d'OpenDKIM pour qu'il ait le droit d'écrire dans son socket, puis relancez-le :

# adduser postfix opendkim
# service postfix restart

Mettre en place votre clef DKIM

Générer la paire de clefs

Placez-vous dans un répertoire dédié, par exemple /etc/dkim/example.com, puis utilisez la commande opendkim-genkey, en l'adaptant à votre propre nom de domaine :

opendkim-genkey -d example.com

Cela créera deux fichiers :

  • default.txt est la clef publique, à publier dans votre zone DNS,
  • default.private est la clef privée, à conserver sur votre serveur qui l'utilisera pour signer les messages envoyés.

Configurer OpenDKIM

OpendDKIM se configure dans le fichier /etc/opendkim.conf. Si vous n'utilisez qu'un seul nom de domaine, la configuration sera assez simple :

opendkim.conf
Domain                 example.com
KeyFile                /etc/dkim/example.com/default.private
Selector               default

Vérifiez qu'OpenDKIM a accès au fichier de clef privée. Je vous conseille pour cela d'autoriser sa lecture par le groupe opendkim :

# chgrp opendkim /etc/dkim/example.com/default.private
# chmod 640 /etc/dkim/example.com/default.private

Puis relancez OpenDKIM :

# service opendkim restart

Essayer

Avant de publier votre clef DKIM, essayez d'envoyer un message vers une adresse externe. Une fois le message reçu, vérifiez qu'il contient bien un en-tête DKIM-Signature.

Publier votre clef et votre politique DKIM

Il ne vous reste plus qu'à publier votre enregistrement de clef publique — le contenu du fichier default.txt généré tout à l'heure — dans votre zone DNS.

Vous pouvez y ajouter un enregistrement de politique ADSP indiquant que tous vos messages sont censés être signés :

_adsp._domainkey.example.com. TXT "dkim=all"

Essayer

Essayez maintenant d'envoyer un message vers une adresse externe dont le serveur vérifie les signatures DKIM, par exemple chez Yahoo! ou Google. Une fois le message reçu, vérifiez le contenu de l'en-tête Authentication-Results : il doit contenir « dkim=pass ».

Signer les courriels pour plusieurs noms de domaine

Si vous voulez signer les courriers pour plusieurs noms de domaine, la configuration mise en place précédemment devra un peu évoluer mais il ne suffira pas de dupliquer les lignes de configuration OpenDKIM. Il faudra plutôt remplacer la déclaration du domaine par une table référençant pour chaque domaine la clef privée à utiliser. Sachez qu'il existe plusieurs formats de tables décrits par le manuel opendkim(8). Voici simplement un exemple :

/etc/opendkim.conf
KeyTable     refile:/etc/dkim/keytable
SigningTable refile:/etc/dkim/signingtable
/etc/dkim/keytable
default._domainkey.example.com example.com:default:/etc/dkim/example.com/default.private
default._domainkey.example.org example.org:default:/etc/dkim/example.org/default.private
/etc/dkim/signingtable
*@example.com default._domainkey.example.com
*@example.org default._domainkey.example.org

La création de la nouvelle clef privée, les droits à lui donner et la diffusion de la clef privée dans la zone du second nom de domaine ne change pas par rapport à ce qui a été expliqué plus tôt.

1) Cela n'implique pas qu'il ne s'agit pas d'un spam : il peut être indésirable, mais on sait alors qui en est responsable.
2) Dans ce cas, autant ne pas publier de politique ADSP…
services/dkim.txt · Dernière modification: Sat Jun 4 16:51:48 2016 par samael