En l'état, vous pouvez recevoir et envoyer des messages. Cependant, il se peut que certains serveurs de messagerie considèrent vos mails comme des spams. Heureusement, il existe quelques petites manipulations pour rendre vos messages légitimes. Nous allons les détailler dans les paragraphes suivants. Gardez à l'esprit qu'elles se complètent sans se suffire à elles-mêmes.

Chez votre Fournisseur d'Accès à internet, cherchez les options correspondant à votre adresse IP. Vous pourrez configurer un reverse DNS ou en français DNS inverse.

Alors que votre nom de domaine est relié à l'IP du serveur, il faut aussi configurer la réciproque, c'est-à-dire relier à votre IP le nom de domaine.

Un petit mail à votre fournisseur permettra de savoir comment s'y prendre si vous ne trouvez pas ;).

Si vous ne pouvez pas faire cette manipulation, ce n'est pas une catastrophe, du moment que vous pouvez mettre en place SPF et DKIM (voir paragraphes suivants).

Une autre possibilité consiste à louer un VPN pour obtenir une nouvelle IP dédiée à votre serveur. Les fournisseurs de VPN proposent souvent un reverse DNS configurable.

Normalement, seul votre serveur est autorisé à envoyer des messages avec vote nom de domaine. Un enregistrement SPF dans votre zone permet de le préciser. Puisque normalement, c'est l'administrateur du serveur de mail qui gère aussi la zone, c'est une preuve de bonne foi. L'absence de champ SPF est très mauvais pour la réputation d'un mail.

Ajoutez un champ DNS de type SPF dans votre zone DNS qui correspond au champ A utilisé pour vos mails (chez votre registrar ou sur votre serveur de noms si vous l'hébergez aussi) tel que celui-ci :

chezmoi.tld.   SPF "v=spf1 a mx ~all"

ou bien sous forme de champ TXT si le SPF n'est pas disponible :

chezmoi.tld. TXT "v=spf1 a mx ~all"

Cette technique complète SPF et consiste à signer avec le serveur les messages émis par le serveur à l'aide d'une clé privée. On ajoute ensuite dans un champ DNS la clé publique correspondante qui permettra au destinataire de vérifier que le mail reçu provient bien de votre serveur.

Hum… Pas sûr d'avoir compris.

Je reprends. Nous allons créer une clé privée et une clé publique.

La clé privée servira à signer les messages. On l'appelle “privée” car vous devez être la seule personne capable de signer (comme pour vos chèques ou vos impôts). La clé publique est là pour vérifier que la signature est bien authentique. On peut voir ça comme une pièce de puzzle unique, qui est la seule à pouvoir entrer dans l'empreinte créée par la signature.

C'est l'outil dkimproxy qui nous permettra de signer les messages. Notez que c'est aussi possible avec rspamd (voir la page correspondante), la méthode de génération des clés restant identique.

On installe dkimproxy comme d'habitude :

# pkg_add dkimproxy

Les commandes suivantes permettent de fabriquer la paire de clés qui servira à signer les mails émis :

• Création du dossier pour les clefs : # mkdir -p /etc/dkim/
• On modifie les permissions : # chmod 770 /etc/dkim/
• On va dans le dossier # cd /etc/dkim/
• On génère les clefs

  # openssl genrsa -out private.key 1024               
  # openssl rsa -in private.key -pubout -out public.key

• On protège les clefs

  # chown -R _dkimproxy:_dkimproxy /etc/dkim/
  # chmod 400 private.key

Afin de configurer la signature des messages envoyés, il faut éditer le ficher/etc/dkimproxy_out.conf ainsi :

listen    127.0.0.1:10027
relay     127.0.0.1:10028
domain    chezmoi.tld
signature dkim(c=relaxed)
signature domainkeys(c=nofws)
keyfile   /etc/dkim/private.key
selector  dkimpubkey

Euh, c'est quoi tout ça?

Quelques menues explications :

• Les lignes listen et relay indiquent l'adresse avec le port où dkimproxy recevra respectivement les mails à chiffrer et où il les fera suivre. Tout se passe dans votre serveur, donc à l'adresse 127.0.0.1.
• domain décrit votre nom de domaine : à modifier selon votre cas.
• keyfile permet d'indiquer où se trouve le chemin vers la clé servant à signer les mails.
• selector définit l'identifiant qui sera présent dans le champ DNS que l'on va préciser ensuite.

Bien, reste à indiquer à opensmtpd de signer les mails. On va donc ajouter dans le fichier /etc/mail/smtpd.conf une ligne pour écouter sur le port 10028 en local, afin d'envoyer les mails que dkimproxy aura signé. On leur colle l'étiquette “DKIM” pour les repérer ensuite.

listen on lo0 port 10028 tag DKIM   

Les messages qui auront l'étiquette “DKIM” peuvent être envoyés. On n'envoie plus les mails s'ils ne sont pas passés par dkimproxy.

match tag DKIM for any action "envoi"
match auth tag DKIM from any for any action "envoi"

Enfin, les messages pas encore signés doivent être envoyés à dkimproxy. On définit l'action correspondante :

action dkimproxy relay host smtp://127.0.0.1:10027 

S'ensuit les règles de correspondance qui vont bien, à placer à la fin du fichier smtpd.conf:

match auth from any for any action dkimproxy
match for any action dkimproxy

Le fichier /etc/mail/smtpd.conf ressemble désormais à ça :

# Configuration generale
## Tables 
table aliases "/etc/mail/aliases"
table passwd "/etc/mail/passwd"
table virtuals "/etc/mail/virtuals"

## Certificats
pki chezmoi.tld key "/etc/ssl/private/chezmoi.tld.key"
pki chezmoi.tld cert "/etc/ssl/chezmoi.tld-fullchain.pem"

### Ecoute pour messages signes avec dkimproxy
listen on lo0 port 10028 tag DKIM   

### Reception
listen on all tls pki chezmoi.tld 
### Envoi avec client de messagerie
listen on all port submission tls-require pki chezmoi.tld auth <passwd> 


# ACTIONS
action "envoi" relay 
action dkimproxy relay host smtp://127.0.0.1:10027 

action local_mbox mbox alias <aliases>
action virtual_maildir maildir "/var/vmail/%{dest.domain}/%{dest.user}/Maildir" virtual <virtuals>

# Correspondances
## Reception
### Message pour les utilisateurs locaux qui lisent avec la commande "mail"
match for local action local_mbox
### Message pour les utilisateurs virtuels
match from any for domain "chezmoi.tld" action virtual_maildir

## Envoi
### Mail sortant portant une signature DKIM
match tag DKIM for any action "envoi"
match auth tag DKIM from any for any action "envoi"

### Mail en envoi pas encore signe avec DKIM
match auth from any for any action dkimproxy
match for any action dkimproxy

Ça va? Vous suivez toujours? Je vois à votre regard pétillant que vous attendez la fin avec impatience ! ^^

Courage, c'est presque fini. ;)

Pour terminer, nous allons ajouter un nouveau champ dans vos DNS auprès de votre registrar ou dans votre zone. Eh oui, encore ! On va en réalité indiquer le nécessaire pour pouvoir vérifier la signature des messages qui auront un drapeau “dkimpubkey”.

Il s'agira d'un champ DKIM ou TXT selon ce qui est disponible. Remplissez-le ainsi :

• Nom du champ : dkimpubkey._domainkey.
• Contenu : v=DKIM1; k=rsa; p=…

Recopiez à la place des points de suspension le contenu du fichier public.key, que vous pouvez afficher avec la commande cat :

# cat /etc/dkim/public.key

Ce qui nous donnera dans la zone DNS votre domaine :

dkimpubkey._domainkey    IN TXT    ( "v=DKIM1; k=rsa; t=s;p=v+Fb...vhP/oB")

Finalement, activez dkimproxy puis rechargez opensmtpd avant de tester si vous avez réussi à configurer correctement l'envoi de vos mails.

# rcctl enable dkimproxy_out
# rcctl start dkimproxy_out
# rcctl restart smtpd

Pour vérifier que vos messages envoyés ne sont pas considérés comme spam, suivez les indications du site mail-tester. Vous allez envoyer un message à l'adresse donnée, et normalement, vous devriez obtenir au moins une note de 8/10 :

Il se peut qu'on vous parle d'un enregistrement dmarc. Libre à vous de l'ajouter à vos DNS, mais ce n'est pas obligatoire. En réalité, “ça fait juste bien” d'en avoir un… À vrai dire, le score obtenu est déjà meilleur qu'avec nombre de “grands” services de messagerie (testez avec gmail pour rigoler : 6.1/10 lors de mon dernier test…).