Problème d'authentification mail (headers DKIM non présents dans les mails envoyés)

Mon serveur YunoHost

Matériel: VPS acheté en ligne
Version de YunoHost: 11.2.10.3 (stable)
J’ai accès à mon serveur : En SSH | Par la webadmin
Êtes-vous dans un contexte particulier ou avez-vous effectué des modifications particulières sur votre instance ? : non

Description du problème

Je souhaite utiliser yunhost pour la gestion de mes mails perso

J’ai l’impression d’avoir tout configuré, mais je n’ai pas la note parfaite sur mail-tester
En effet les mails ne sont pas signés par DKIM d’après mail-tester

J’ai pourtant bien la clé publique DKIM sur mon DNS avec le sélecteur mail

C’est bien la même valeur que celle dans /etc/dkim/

Pour info, j’envoie les mails soit depuis un client iOS, soit depuis snappymail installé sur la même instance yunhost.

Pour essayer de comprendre, je me suis envoyé à moi meme un email sur l’instance yunohost et j’ai fait analysé les headers par mxtoolbox et là le diagnostic montre que ça n’est pas ok.

Help! merci

Tu as bien ajouté ces valeurs ?

@ 3600 IN MX 10 domain.tld.
@ 3600 IN TXT "v=spf1 a mx -all"
 mail._domainkey 3600 IN TXT "v=DKIM1; h=sha256; k=rsa; p=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
_dmarc 3600 IN TXT "v=DMARC1; p=none"

bien ajouté les reverse dns pour les IPv4 et IPv6 ?

Le diagnostic de yunohost ne te renvoi pas d’erreurs ?

Salut oui tout était bon

A vrai dire je ne comprends pas ce qui s’est passé. plusieurs jours plus tard tout fonctionne à 100% sans avoir rien changé. Il fallait peut être un reboot (pas si courant sur un VPS)

EDIT: j’ai dû halluciner.

Bon, c’est un peu ennuyeux comme situation, mais le problème est revenu ou alors j’ai halluciné quand j’ai cru que ça fonctionnait.
SPF est ok.
Les clés publiques DKIM sont bien présentes dans les enregistrements DNS et ont été copiées collées depuis l’interface yunohost.
MAIS…
les mails sortants envoyés par postfix n’ont pas de headers DKIM.
J’ai fait un regen-conf qui me dit ok, j’ai rebooté yuno, j’ai fait les diagnostics qui sont tous ok.
Et toujours pas de headers DKIM dans les mails sortants qui ne sont donc pas ok.

Merci pour toute suggestion !

NB : ca dépends de comment tu testes exactement … par exemples les mails envoyés via la commande mail en CLI ne sont pas signés DKIM car ils ne passent pas par SMTP. Par contre les mails qui passent par SMTP sont censés être signés

Merci
J’envoie par snappymail ou par un client mail classique donc normalement il devrait y avoir la signature dkim

Dans le dossier avec les clés dkim je n’ai pas les mêmes propriétaires pour les fichiers
*.key avec la clé privée appartiennent à _rspamd
*.txt avec les instructions dns / clés publiques appartiennent à root

C’est normal ?

Salut, j’ai des permissions ressemblantes à ceci

-r-------- 1 _rspamd root 891 Feb  3  2022 domain.tld.mail.key
-rw------- 1 root    root 341 Feb  3  2022 domain.tld.mail.txt

Merci
Pareil.

Et quand tu envoies ça mets bien les headers dkim ?

Sur mail-tester par exemple

Il me semble…
Par exemple une en-tête d’un message reçu (envoyé avec un alias) sut Thunderbird

Return-Path: <user_alias@domain.tld>
Delivered-To: user@domain.tld
Received: from [IPV6:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:xxxx:xxx] (unknown [IPv6:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:xxxx:xxx])
	by domain.tld (Postfix) with ESMTPSA id 366632985F1;
	Thu,  9 May 2024 12:27:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=domain.tld; s=mail;
	t=1715250442;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=;
	b=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/X/XXXXXXXXXXXXXXXXXXX+XXXXXXXXXXXX
	XXXXXXXXXXXX/XXXXXXXXXXXXXXXXXXXXX=
Content-Type: multipart/alternative;
 boundary="------------iFbCBdYsNYfTTjeZSUQmTUp2"
Message-ID: <b4df2c13-8448-452f-9be8-60dbceb221fd@domain.tld>
Date: Thu, 9 May 2024 12:27:20 +0200
MIME-Version: 1.0
user_alias-Agent: Mozilla Thunderbird
Content-Language: fr
From: Nom User Alias <user_alias@domain.tld>
Subject: =?UTF-8?Q?Avis_sur_changement_=C3=A9diteur_sur_BLA_BA?=
Organization: Orga
To: destinataires inconnus: ;

This is a multi-part message in MIME format.
--------------iFbCBdYsNYfTTjeZSUQmTUp2
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Bon merci
Pour le test

Une idée de comment diagnostiquer ou réparer le problème?

Sans signature dkim les mails sont flagges comme du spam

Est-ce que ce n’est pas juste un mail interne ? je crois que les mails interne au serveur ne sont pas signés… Pour vérifier, envoie un message à toi toi et un autre utilisateur pour que le mail transite aussi par iun autre serveur.

mxtoolbox n’est parfois pas fiable.

Tu peux essayer d’installer un rapport Postfix des emails avec pflogsumm. Il suffit de l’installer:

apt-get install pflogsumm

Un crontab pour envoyer envoie un mail journalier à ton adresse

crontab -e
# Stats mails ( pflogsumm )
00 20 * * * /usr/sbin/pflogsumm -d today /var/log/mail.log | mail -s "Postfix Rapport du `date`" monuser@domain.tld

C’est très utile pour voir des erreurs. J’ai pu ainsi détecter des mails agressifs qui me considérait comme spam par des protections outlook par exemple…

Est-ce que le diagnostic te renvoie des erreurs ?

Sinon il y ,a un test ici pour dkim DKIM validator - Mailhardener tools

Il faut entrer par exemple

mail._domainkey.monndomaine.tld

Salut

Non ce ne sont pas des mails internes ce sont des mails que j’envoie à des serveurs externes
Vers gmail et que je récupère dans des spans ou bien vers des services spécialisés comme mxtoolbox ou mail-tester.com

Le problème est que mes en têtes de mail n’ont pas de signature dkim. Les champs ne sont pas présents

J’ai installé pflogsumm qui me donne des stats et où apparaît une erreur fatale

May  8 09:15:05 base postfix/smtp[28721]: fatal: valid hostname or network address required in server description: []:58

Ça pourrait être une piste ? Pas de signature de nom de serveur si ca ne concorde pas ?

J’ai essaye un hostnamectl qui me donne le nom de serveur base.name.tld

Dans mon /etc/hosts je n’ai pas ce nom

127.0.0.1 localhost 
127.0.1.1 instance-base instance-base 

J’ai essayé de remplacer instance-base instance-base par ´base.name.tld’ mais c’est revenu après redémarrage

J’ai fait un postfix check qui me renvoie des erreurs

# postfix check
postfix: Postfix is running with backwards-compatible default settings
postfix: See http://www.postfix.org/COMPATIBILITY_README.html for details
postfix: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload"
postfix/postfix-script: warning: not owned by root: /etc/postfix/.
postfix/postfix-script: warning: not owned by root: /etc/postfix/./app_senders_login_maps.db
postfix/postfix-script: warning: not owned by root: /etc/postfix/./app_senders_login_maps ```

J’ai déjà testé dkim validator mais ça permet de vérifier que les clés publiques sont bien présentes dans les enregistrements dns
Ça c’est bon

Mon orobleme c’est que les mails quittent mon serveur sans avoir été signés au moins de ma clé privée

Après analyse des logs j’ai un suspect

postfix/cleanup[6849]: warning: milter inet:localhost:11332: can't read SMFIC_BODYEOB reply packet header: Connection timed out

Ça semble lié au dkim sur internet mais les solutions sont basées sur opendkim et ça ne fonctionne pas sur mon système debian - postfix/smtpd: warning: connect to Milter service unix:/var/run/opendkim/opendkim.sock: No such file or directory - Unix & Linux Stack Exchange

Salut,
peut-être qu’il faut arranger le hostname

le fichier /etc/hostname devrait être

instance-base.tld

Pour le /etc/hosts, j’essaierai ceci (MON_IPv4 = IP du serveur)

127.0.0.1 localhost 
127.0.1.1 instance-base.tld instance-base 
MON_IPv4 instance-base.tld instance-base

::1	localhost	ip6-localhost	ip6-loopback
ff02::1	ip6-allnodes
ff02::2	ip6-allrouters

127.0.0.1	instance-base

Puis un yunohost tools regen-conf dns

Ok je viens de faire.

Pour info il faut aussi modifier /var/spool/postfix/etc/hosts qui est une copie sinon postfix râle parce que les fichiers sont différents.

J’ai fait regen conf derrière et rebooté

Les modifications ne sont pas persistantes

Elles devraient être persistantes…

C’est un VPS hébergé où ?

Est-ce qu’il n’y a pas un cloud-init qui prend la main et écrase tes changements ?

regarde ici
https://community.ovh.com/t/echec-de-tentative-pour-changer-le-hostname/32054/6

Une méthode un peu bourrin est de supprimer le cloud-init…
Ou bien de trouver comment l’empêcher de remettre à jour le fichier hosts

1 Like

argh en fait c’est expliqué en début de fichier /etc/hosts

Your system has configured ‘manage_etc_hosts’ as True.
As a result, if you wish for changes to this file to persist
then you will need to either
a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl
b.) change or remove the value of ‘manage_etc_hosts’ in
/etc/cloud/cloud.cfg or cloud-config from user-data

Je recommence…