Maddy Mail Server mx1.yannir.xyz

Posté 08/11/2025

Par Yann

22 min lire

Maddy Mail Server met en œuvre toutes les fonctionnalités requises pour faire fonctionner un serveur de courrier électronique. Il peut envoyer des messages via SMTP (fonctionne comme MTA), accepter des messages via SMTP (fonctionne comme MX) et stocker des messages tout en y donnant accès via IMAP. En outre, il met en œuvre des protocoles auxiliaires qui sont obligatoires pour assurer une sécurité raisonnable du courrier électronique (DKIM, SPF, DMARC, DANE, MTA-STS).
Il remplace Postfix, Dovecot, OpenDKIM, OpenSPF, OpenDMARC et d’autres encore par un seul démon avec une configuration uniforme et un coût de maintenance minimal.

Maddy Mail Server

Mise en place un serveur de messagerie utilisant maddy

Prérequis

Serveur Debian 13
- Vérifier que le fournisseur d’accès internet ne bloque pas le trafic SMTP port TCP 25
  - Depuis un poste externe : sudo nmap -sS -p25 144.91.89.149

        Starting Nmap 7.95 ( https://nmap.org ) at 2024-11-30 09:27 CET
        Nmap scan report for yannir.xyz (144.91.89.149)
        Host is up (0.0082s latency).

        PORT   STATE    SERVICE
        25/tcp filtered smtp

        Nmap done: 1 IP address (1 host up) scanned in 0.43 seconds

Vérifier le DNS Reverse IPV4 yannir.xyz (activation chez le fournisseur de VPS

        dig -x 144.91.89.149 +short            # --> yannir.xyz.
        dig -x 2a02:c207:2278:6143::1 +short     # --> yannir.xyz.

Contabo VPS: Control panel --> Reverse DNS Management
Domaine OVH : yannir.xyz
- Protection DNS contre le transfert
- DNSSEC activé
- DNS OVH

    $TTL 3600
    @	IN SOA dns200.anycast.me. tech.ovh.net. (2025110701 86400 3600 3600000 60)
            IN NS     dns200.anycast.me.
            IN NS     ns200.anycast.me.
            IN MX     10 yannir.xyz.
            IN A     144.91.89.149
            IN AAAA     2a02:c207:2278:6143::1
    *        IN A     144.91.89.149
    *        IN AAAA     2a02:c207:2278:6143::1

Enregistrement DNS MX

Installer des outils
1 sudo apt install net-tools
Installer cron car pas par défaut dans debian 13
1 sudo apt install cron
On vérifie si aucun service est en écoute sur le port 25

        
    # Ecoute sur le port 25 ?
    sudo ss -ltnp | grep -w ':25'

    `LISTEN 0      20             [::1]:25            [::]:*    users:(("exim4",pid=215389,fd=6))`

ATTENTION: exim est installé avec cron, l’arrêter et le désactiver
sudo systemctl stop exim4.service
sudo systemctl disable exim4.service

Parefeu UFW

Ports utilisés par le serveur de messagerie

Autoriser le trafic sur le port 25 pour le SMTP standard: sudo ufw allow 25
Autoriser le trafic sur le port 587 pour la soumission de messages: sudo ufw allow 587
Autorisez le trafic sur le port 993 pour la sécurité IMAP (IMAPS): sudo ufw allow 993
Vérifiez l’état de l’UFW pour vous assurer que les règles sont correctement appliquées: sudo ufw status

Exécuter les instructions suivantes

        
      
sudo ufw allow 25
sudo ufw allow 587
sudo ufw allow 993

Installation

Utilisation image préconstruite (Linux, amd64)
Disponible sur GitHub ou maddy.email/builds.

Archive au format zst, installer l’outil zstd (est installé par défaut sur Debian 13):

Téléchargement et décompression

        
      
# Téléchargement
wget https://github.com/foxcpp/maddy/releases/download/v0.8.1/maddy-0.8.1-x86_64-linux-musl.tar.zst
# décompression
tar -I zstd -xvf maddy-0.8.1-x86_64-linux-musl.tar.zst

Contenu archive

./maddy-0.8.1-x86_64-linux-musl/
./maddy-0.8.1-x86_64-linux-musl/systemd/
./maddy-0.8.1-x86_64-linux-musl/systemd/maddy.service
./maddy-0.8.1-x86_64-linux-musl/systemd/maddy@.service
./maddy-0.8.1-x86_64-linux-musl/maddy
./maddy-0.8.1-x86_64-linux-musl/maddy.conf

Copier l’exécutable maddy que vous pouvez copier dans /usr/local/bin

sudo cp maddy-0.8.1-x86_64-linux-musl/maddy /usr/local/bin/

Systemd service + utilisateur maddy

distribution basée sur systemd

On a utilisé une archive préconstruite, copiez manuellement systemd/*.service dans /etc/systemd/system (maddy.service et maddy@.service)

sudo cp maddy-0.8.1-x86_64-linux-musl/systemd/*.service /etc/systemd/system/

Vous devez recharger la configuration du gestionnaire de service pour rendre le service disponible

sudo systemctl daemon-reload

En outre, vous devez créer l’utilisateur et le groupe maddy (maddy ne s’exécute jamais en tant que root)

sudo useradd -mrU -s /sbin/nologin -d /var/lib/maddy -c "maddy mail server" maddy

Créer le répertoire et copier le fichier de configuration

sudo mkdir -p /etc/maddy
sudo cp maddy-0.8.1-x86_64-linux-musl/maddy.conf /etc/maddy/

Hôte mx1.yannir.xyz

Si vous installez un très petit serveur de messagerie, vous pouvez utiliser yannir.xyz dans les deux champs.
Cependant, pour faciliter une future migration de service, il est recommandé d'utiliser une entrée DNS séparée à cet effet. Il s’agit généralement de mx1.yannir.xyz, mx2, etc. Vous pouvez bien sûr utiliser un autre sous-domaine, par exemple : smtp1.yannir.xyz. Un serveur de basculement de courrier électronique sera possible si vous transférez mx2.yannir.xyz vers un autre serveur (à condition que vous le configuriez pour gérer votre domaine).

Ouvrir /etc/maddy/maddy.conf

$(hostname) = mx1.yannir.xyz
$(primary_domain) = yannir.xyz
$(local_domains) = $(primary_domain)

Si vous souhaitez gérer plusieurs domaines, vous devez toujours en désigner un comme “primaire”.
Ajoutez tous les autres domaines à la ligne local_domains

$(local_domains) = $(primary_domain) example.com other.example.com

Certificat TLS mx1.yannir.xyz

Une chose qui ne peut pas être configurée automatiquement, ce sont les certificats TLS (/etc/maddy/maddy.conf).

Créer le dossier de stockage des certificats

        
      
# hostmane --> mx1.yannir.xyz
sudo mkdir -p /etc/maddy/certs/mx1.yannir.xyz
sudo chown $USER:root /etc/maddy/certs/mx1.yannir.xyz # pour écriture dess certificats par acme

ACME.sh

Création des certificats SSL Let’s encrypt via Acme

# Git
git clone https://github.com/acmesh-official/acme.sh.git
cd ./acme.sh
./acme.sh --install
# déconnexion et reconnexion

Les clés OVH API

export OVH_AK="xxxxxxxxxxxxxxxxx"
export OVH_AS="xxxxxxxxxxxxxxxxxxxxxxxxxxx"

Certificat mx1.yannir.xyz
Exécuter une première fois pour récupérer le lien de validation API OVH DNS

acme.sh --dns dns_ovh --server letsencrypt --issue --keylength ec-384 -d 'mx1.yannir.xyz' -d 'yannir.xyz'

Seconde exécution pour créer le certificat mx1.yannir.xyz

acme.sh --dns dns_ovh --server letsencrypt --issue --keylength ec-384 -d 'mx1.yannir.xyz' -d 'yannir.xyz'

Si vous utilisez acme.sh pour gérer vos certificats, vous pouvez simplement exécuter

acme.sh --ecc --install-cert -d 'mx1.yannir.xyz' \
  --key-file       /etc/maddy/certs/mx1.yannir.xyz/privkey.pem  \
  --fullchain-file /etc/maddy/certs/mx1.yannir.xyz/fullchain.pem

Lors de l’exécution --cron, tout nouveau certificat sera automatiquement installé, et le reloadcmd sera exécuté.

Vous devez vous assurer que maddy peut les lire lorsqu’il tourne en tant qu’utilisateur non privilégié (maddy ne tourne jamais en tant que root, même au démarrage)

ERREUR: nov. 04 13:36:23 vps-1780de45 maddy[20046]: failed to load /etc/maddy/certs/mx1.yannir.xyz/fullchain.pem and /etc/maddy/certs/mx1.yannir.xyz/privkey.pem: open /etc/maddy/certs/mx1.yannir.xyz/privkey.pem: permission denied
maddy ne peut pas lire les certificats!!!

on doit utiliser les ACLs

        
sudo apt install acl # si non installé
sudo setfacl -R -m u:maddy:rX /etc/maddy/certs/mx1.yannir.xyz/fullchain.pem /etc/maddy/certs/mx1.yannir.xyz/privkey.pem

Vérification: sudo getfacl /etc/maddy/certs/mx1.yannir.xyz/*.pem

getfacl : suppression du premier « / » des noms de chemins absolus
# file: etc/maddy/certs/mx1.yannir.xyz/fullchain.pem
# owner: yair
# group: yair
user::rw-
user:maddy:r--
group::rw-
mask::rw-
other::r--

# file: etc/maddy/certs/mx1.yannir.xyz/privkey.pem
# owner: yair
# group: yair
user::rw-
user:maddy:r--
group::---
mask::r--
other::---

Le groupe maddy a les droits en lecture

maddy recharge les certificats TLS à partir du disque une fois par minute, de manière à ce qu’il remarque le renouvellement. Il est possible de forcer le rechargement via systemctl reload maddy

Lancer le service: sudo systemctl start maddy

Lancement et activation maddy.service

On vérifie si le service “maddy” est en écoute sur le port 25

        
# Ecoute sur le port 25 ?
sudo ss -ltnp | grep -w ':25'

LISTEN 0 4096 *:25 *:* users:(("maddy",pid=222332,fd=9))

Activer maddy

sudo systemctl enable maddy --now 

maddy initie le répertoire /var/lib/maddy/ et génère la clé DKIM

sudo systemctl status maddy

Les informations

● maddy.service - maddy mail server
     Loaded: loaded (/etc/systemd/system/maddy.service; enabled; preset: enabled)
     Active: active (running) since Fri 2025-11-07 22:57:34 CET; 3min 59s ago
 Invocation: 6c75ce5eddcd4fb485fa01138be3fd54
       Docs: man:maddy(1)
             man:maddy.conf(5)
             https://maddy.email
   Main PID: 222332 (maddy)
     Status: "Listening for incoming connections..."
      Tasks: 8 (limit: 9507)
     Memory: 9.1M (peak: 9.5M)
        CPU: 491ms
     CGroup: /system.slice/maddy.service
             └─222332 /usr/local/bin/maddy run

nov. 07 22:57:34 yannir.xyz maddy[222332]: table.file: ignoring non-existent file: /etc/maddy/aliases
nov. 07 22:57:34 yannir.xyz maddy[222332]: smtp: listening on tcp://0.0.0.0:25
nov. 07 22:57:34 yannir.xyz maddy[222332]: modify.dkim: generating a new rsa2048 keypair...
nov. 07 22:57:34 yannir.xyz maddy[222332]: modify.dkim: generated a new rsa2048 keypair, private key is in dkim_keys/yannir.xyz_default.key, TXT record with public key is in dkim_keys/yannir.xyz_default.dns,
nov. 07 22:57:34 yannir.xyz maddy[222332]: put its contents into TXT record for default._domainkey.yannir.xyz to make signing and verification work
nov. 07 22:57:34 yannir.xyz maddy[222332]: submission: listening on tls://0.0.0.0:465
nov. 07 22:57:34 yannir.xyz maddy[222332]: submission: listening on tcp://0.0.0.0:587
nov. 07 22:57:34 yannir.xyz maddy[222332]: imap: listening on tls://0.0.0.0:993
nov. 07 22:57:34 yannir.xyz maddy[222332]: imap: listening on tcp://0.0.0.0:143
nov. 07 22:57:34 yannir.xyz systemd[1]: Started maddy.service - maddy mail server.

DKIM, DMARC, MTA-STS et TLS(DANE)

DKIM

L’enregistrement DKIM est un enregistrement TXT modifié qui ajoute des signatures cryptographiques à vos messages électroniques. Vous ajoutez un enregistrement DKIM à votre système de nom de domaine (DNS), et il contient la cryptographie à clé publique utilisée par le serveur de messagerie récepteur pour authentifier un message.

DKIM, norme technique Domain Keys Identified Mail (DKIM) est une forme de processus d’authentification par courriel. Il permet à une organisation d’ajouter une signature numérique à ses messages électroniques, de sorte que les destinataires ont un moyen de valider l’email en jumelant sa clé cryptographique publique aux enregistrements DNS. Le processus de signature DKIM comporte trois étapes principales, à commencer par l’expéditeur qui identifie les champs à inclure dans leur signature d’enregistrement DKIM. La plateforme email de l’expéditeur crée alors un hachage des champs de texte, qui inclut la signature DKIM. Dans la dernière étape, la passerelle électronique validera la signature DKIM en jumelant la clé publique à la clé privée.

Et la dernière, la clé DKIM, est un peu délicate. maddy a généré une clé pour vous lors du premier démarrage.
Vous pouvez la trouver dans /var/lib/maddy/dkim_keys/yannir.xyz_default.dns
Vous devez la mettre dans un enregistrement TXT pour le domaine default._domainkey.yannir.xyz

default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANB...hQIDAQAB"

DMARC

DMARC est une norme technique qui aide à protéger contre l’hameçonnage, le spoofing et le spam. C’est un protocole d’authentification par courriel qui utilise SPF et DKIM pour déterminer l’authenticité du message par courriel. Avec une politique DMARC en place, vous pouvez vérifier si le SPF et le DKIM s’alignent sur le domaine d’adresse indiqué sur le “Header” et spécifier ce que le serveur récepteur doit faire en cas d’échec du SPF et du DKIM.

Définir sa politique de sécurité DMARC !

La politique de sécurité DMARC consiste à dire aux serveurs distants (qui sont capables d’interpréter ces politiques) quoi faire en cas de non-conformité d’un email. À ce jour, il n’existe que TROIS valeurs possibles qui s’appliqueront au domaine où DMARC sera implémenté (p=) ou à tous ses sous-domaines (sp=) :

La policy none (ou p=none) : Aucun traitement de l’email non-conforme ne sera fait, l’email pourra être délivré en boite de réception ou en spam.
La policy quarantine (ou p=quarantine) : L’email non-conforme sera délivré en courrier indésirable.
La policy reject (p=reject) : L’email non-conforme ne sera pas délivré et un bounce sera envoyé à l’expéditeur.

Toute autre déclaration de policy amènera chez les FAI / Webmails des comportements différents :

Gmail : Transforme la valeur existante par none (dmarc=pass p=NONE sp=NONE) ;
Microsoft : Produit comme résultat une erreur permanente (dmarc=permerror) ;
Yahoo : Produit un résultat inconnu (dmarc=unknown) ;
La Poste : Ignore l’enregistrement (dmarc=none reason= »No policy found »).

Ces politiques ne sont pas enregistrées sous forme de phrases lisibles par l’homme, mais plutôt sous forme de commandes lisibles par la machine afin que les services de messagerie puissent les interpréter automatiquement. Cette politique DMARC ressemblerait en fait à ceci :

politique de sécurité valide pour un enregistrement DMARC
v=DMARC1; p=quarantine; rua=mailto:postmaster@yannir.xyz;

Politique DMARC yannir.xyz

_dmarc        IN TXT     "v=DMARC1; p=quarantine; rua=mailto:postmaster@yannir.xyz"

SPF

Les enregistrements SPF sont un type d’enregistrement DNS TXT couramment utilisé pour l’authentification d’e-mails. Les enregistrements SPF incluent une liste d’adresses IP et de domaines autorisés à envoyer des e-mails depuis ce domaine.

    IN TXT     "v=spf1 a mx -all"

MTA-STS

MTA-STS, Google vise à rendre Gmail plus sécurisé avec l’agent de transfert de courrier/Strict Transport Security (MTA-STS). Le mécanisme charge le serveur SMTP de s’assurer que l’autre serveur SMTP doit être chiffré et que le nom de domaine figurant sur le certificat doit correspondre au domaine. Lorsque MTA-STS a été activé pour votre domaine, vous demandez que les serveurs de messagerie externes n’envoient des messages à votre domaine que lorsque la connexion SMTP est à la fois cryptée avec TLS 1.2 ou supérieur et authentifiée avec un certificat public valide. MTA-STS protège contre les attaques Man-in-the-Middle (MITM) et les attaques de dégradation et résout les problèmes de sécurité SMTP tels que les certificats TLS expirés.

Prérequis, caddy ou nginx installé

Le MTA-STS est un protocole qui permet le transport crypté de messages entre deux serveurs de messagerie SMTP. MTA-STS spécifie aux serveurs d’envoi que les courriers électroniques ne doivent être envoyés que par une connexion cryptée TLS, et ne doivent pas être délivrés du tout dans le cas où une connexion sécurisée n’est pas établie via la commande STARTTLS. En renforçant la sécurité des courriers électroniques en transit, MTA-STS contribue à atténuer les attaques de type “Man-In-The-Middle” (MITM) telles que les attaques de déclassement SMTP et les attaques de spoofing DNS.

Stratégie pour serveur de messagerie yannir.xyz

version: La version du protocole du fichier. Au moment de la rédaction de ce document, il doit s’agir de STSv1.
mode: Il s’agit du mode de la politique. Les valeurs disponibles sont testing, enforce, ou none.
- testing: Les expéditeurs enverront vos rapports (TLSRPT) indiquant les échecs d’application de la politique. Cela nécessite que TLSRPT soit également implémenté pour fonctionner. Les échecs de connexion TLS ne seront pas bloqués, tout en étant capable de recevoir des rapports.
- enforce: Les serveurs de messagerie expéditeurs qui prennent en charge MTA STS ne délivreront pas de courrier à votre domaine lorsque l’authentification du certificat échoue, ou ne peut pas négocier TLS. Des rapports sur ces échecs sont également envoyés.
- none: Les expéditeurs traiteront le domaine comme s’il n’avait pas de politique active. Cela désactive effectivement le MTA STS.
mx: Les enregistrements MX pour le domaine. Ils doivent correspondre aux enregistrements MX publiés dans le DNS de votre domaine. Vous pouvez spécifier le FQDN ou un hôte joker (mx : mail.example.org ou mx : *.example.org). Assurez-vous que chaque enregistrement MX est ajouté sur sa propre ligne dans le fichier de stratégie.
max_age: La durée de vie maximale de la politique exprimée en secondes. Cela représente la durée pendant laquelle un expéditeur mettrait en cache la politique du domaine. Il est recommandé d’utiliser une valeur équivalente à plusieurs semaines ou plus, mais ne dépassant pas 31557600 (environ 1 an).

Pour le domaine yannir.xyz

A - caddy (UTILISE)

Using Caddy to enable MTA-STS

La directive respond de Caddy sert le fichier de politique MTA-STS

Ajouter un nouveau bloc Server à votre fichier Caddy /etc/caddy/Caddyfile :

mta-sts.yannir.xyz {

respond "version: STSv1
mode: testing
mx: mx1.yannir.xyz
max_age: 86401"

header Content-Type "text/plain; charset=utf-8"

}

Ce simple bloc serveur vous permettra d’obtenir un certificat HTTPS brillant, de rediriger tous les visiteurs HTTP vers HTTPS, et de fournir aux demandeurs votre fichier de politique MTA. (remplacer si besoin nom de domaine et entrées MX).

Les observateurs attentifs remarqueront que le fichier de politique MTA-STS devrait être hébergé à l’adresse https://mta-sts.yannir.xyz/.well-known/mta-sts.txt… mais c’est là toute l’élégance de la directive respond de Caddy où que vous alliez sur mta-sts.yannir.xyz, vous obtiendrez exactement la même réponse !

Tester

curl https://mta-sts.yannir.xyz/.well-known/mta-sts.txt

version: STSv1
mode: testing
mx: yannir.xyz
max_age: 86401

MTA-STS Checker - Check MTA-STS Record

Créez et publiez votre enregistrement DNS MTA-STS (enregistrement TXT “_mta-sts”) pour indiquer aux serveurs de réception que vos courriels doivent être cryptés par TLS pour être considérés comme authentiques et qu’ils ne doivent être autorisés à accéder à la boîte de réception de votre destinataire que si c’est le cas.

L’enregistrement TXT suivant est un exemple qui déclare la prise en charge de MTA-STS, l’ID a été défini à 05 h 30, heure UTC du 08 novembre 2025 :

; Mark domain as MTA-STS compatible 
_mta-sts.yannir.xyz.   TXT    "v=STSv1; id=20241108053000Z;"
; and request reports about failures to be sent to postmaster@yannir.xyz
_smtp._tls.yannir.xyz. TXT    "v=TLSRPTv1;rua=mailto:postmaster@yannir.xyz"

TLSA (DANE)

Le résumé du RFC 6698 « The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol : TLSA”, dans lequel DANE est proposé, décrit assez bien ce qu’est DANE : « Les communications cryptées sur l’internet utilisent souvent le protocole TLS (Transport Layer Security), qui dépend de tiers pour certifier les clés utilisées. Ce document améliore cette situation en permettant aux administrateurs de noms de domaine de spécifier les clés utilisées dans les serveurs TLS de ce domaine. Cela nécessite des améliorations correspondantes dans le logiciel client TLS, mais aucun changement dans le logiciel serveur TLS ».

TLS représente la sécurité de la couche de transport. Le protocole cryptographique fournit une sécurité de bout en bout des données et est généralement implémenté pour chiffrer les protocoles Application Layer comme SMTP, HTTP, FTP et IMAP. Ce mécanisme est mis en œuvre en collaboration avec le MTA-STS et le DANE. Le protocole permet à un domaine de signaler des problèmes de livraison d’emails lorsque l’email manque de chiffrement TLS. Grâce au support MTA-STS, il garantit que les courriels envoyés au domaine obtiennent le chiffrement TLS et sont livrés en toute sécurité.

DANE, DNS-based Authentification of Named Entities (DANE) for SMTP fournit une méthode sécurisée pour le transport de courrier en permettant au propriétaire du domaine de certifier les clés utilisées par ses clients ou serveurs et de générer un certificat. Le mécanisme est censé être publié dans le domaine MX. La vérification DANE peut encore être supportée par un serveur de messagerie de domaine différent en demandant à l’administrateur et en mettant en place des enregistrements TLSA. Les extensions de sécurité du système de noms de domaine (DNSSEC) sont une exigence pour DANE. Pour que le modèle de sécurité fonctionne, l’enregistrement DNS doit être signé avec DNSSEC.

How to use DANE/TLSA

Il est également recommandé de définir un enregistrement TLSA (DANE). Utilisez https://www.huque.com/bin/gen_tlsa pour en générer un.
Copier/coller le contenu du certificat /etc/maddy/certs/mx1.yannir.xyz/fullchain.pem, port sur 25, le protocole de transport sur “tcp” et le nom de domaine sur le nom d’hôte MX.

Et cliquer sur generate

_25._tcp.mx1.yannir.xyz. IN TLSA 3 1 1 (d38fbbd2302743d803522089a4e2797f92e29659cedf3858d6cf64ed17085cf3)

Ajouter une entrée TLSA à l’enregistrement DNS yannir.xyz OVH

Test: dig _25._tcp.mx1.yannir.xyz tlsa +dnssec +multi

Extraits du résultat

; <<>> DiG 9.20.15 <<>> _25._tcp.mx1.yannir.xyz tlsa +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58695
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;_25._tcp.mx1.yannir.xyz. IN TLSA

;; AUTHORITY SECTION:
8B350IP5AKIOCSKCT11EVEHQ4QNM71M0.yannir.xyz. 60	IN NSEC3 1 0 0 - (
				BAL...NQTJKIUTJTBOP
				A NS SOA MX TXT AAAA RRSIG DNSKEY NSEC3PARAM )
8B350IP5AKIOCSKCT11EVEHQ4QNM71M0.yannir.xyz. 60	IN RRSIG NSEC3 8 3 60 (
				2025...MeeRfcVzU= )
BALK3J47LH7EIJUQ35JNQTJKIUTJTBOP.yannir.xyz. 60	IN NSEC3 1 0 0 - (
				IB9OM...IEST4JBL )
BALK3J47LH7EIJUQ35JNQTJKIUTJTBOP.yannir.xyz. 60	IN RRSIG NSEC3 8 3 60 (
				20251....pvcRHzTvww4= )
V7A5U9TOAGC8PN32TOER0AL0O3NQ55HO.yannir.xyz. 60	IN NSEC3 1 0 0 - (
				545MBP...32RTCE
				A AAAA RRSIG )
V7A5U9TOAGC8PN32TOER0AL0O3NQ55HO.yannir.xyz. 60	IN RRSIG NSEC3 8 3 60 (
				20251208...GC5/IJIlMW2vA= )
yannir.xyz.		60 IN SOA dns200.anycast.me. tech.ovh.net. (
				2025110802 ; serial
				86400      ; refresh (1 day)
				3600       ; retry (1 hour)
				3600000    ; expire (5 weeks 6 days 16 hours)
				60         ; minimum (1 minute)
				)
yannir.xyz.		60 IN RRSIG SOA 8 2 3600 (
				20251...89qjjTXw= )

;; Query time: 71 msec
;; SERVER: 192.168.0.205#53(192.168.0.205) (UDP)
;; WHEN: Sat Nov 08 09:26:04 CET 2025
;; MSG SIZE  rcvd: 1027

OVH DNS yannir.xyz complet

DNS yannir.xyz

$TTL 3600
@	IN SOA dns200.anycast.me. tech.ovh.net. (2025110809 86400 3600 3600000 60)
        IN NS     dns200.anycast.me.
        IN NS     ns200.anycast.me.
        IN MX     10 mx1
        IN A     144.91.89.149
        IN AAAA     2a02:c207:2278:6143::1
        IN TXT     "v=spf1 mx -all"
*        IN A     144.91.89.149
*        IN AAAA     2a02:c207:2278:6143::1
_25._tcp        IN TLSA     3 1 1 d3...f3
_dmarc        IN TXT     "v=DMARC1; p=quarantine; rua=mailto:postmaster@yannir.xyz"
_mta-sts        IN TXT     "v=STSv1; id=20241108053000Z;"
_smtp._tls        IN TXT     "v=TLSRPTv1;rua=mailto:postmaster@yannir.xyz"
default._domainkey        IN TXT     ( "v=DKIM1;p=MIIBI...AB;" )
mx1        IN A     144.91.89.149
mx1        IN AAAA     2a02:c207:2278:6143::1

Utilisateur Mail mx1.yannir.xyz

Contrairement à des logiciels comme postfix et dovecot, le serveur de messagerie maddy utilise par défaut des "utilisateurs virtuels", ce qui signifie qu’il ne se préoccupe pas des utilisateurs du système et n’en a pas connaissance.

Gestion base sqlite3

Comptes utilisateurs gérer par base sqlite3

Les boîtes aux lettres IMAP (“comptes”) et les identifiants d’authentification sont séparés.

Pour enregistrer les informations d’identification d’un utilisateur, utilisez la commande maddy creds create
Ajout utilisateur local linux au serveur de messagerie et le stockage local

        
      
sudo -u maddy maddy creds create yair@yannir.xyz # on vous demande de saisir le mot de passe du compte

Notez que le nom d'utilisateur est une adresse électronique. Ceci est nécessaire car le nom d’utilisateur est utilisé pour autoriser l’accès IMAP et SMTP (à moins que vous ne configuriez des mappings personnalisés, non décrits ici).

Après avoir enregistré les informations d’identification de l’utilisateur, vous devez également créer un compte de stockage imap local

sudo -u maddy maddy imap-acct create yair@yannir.xyz

Vous avez maintenant votre première adresse électronique.

Lorsque vous vous authentifiez avec votre client de messagerie, n’oubliez pas que le nom d’utilisateur est “yair@yannir.xyz”, et pas seulement “yair”.

L’exécution de maddy creds --help et maddy imap-acct --help peut s’avérer utile pour connaître les autres commandes.

Notez que les comptes IMAP et les identifiants sont gérés séparément, mais que les noms d’utilisateur doivent correspondre par défaut pour que les choses fonctionnent.

Liste des utilisateurs : sudo maddy creds list et des stockages : sudo maddy imap-acct list

Alias messagerie

Les alias de messagerie sont stockés dans le fichier /etc/maddy/aliases sous le format suivant

# adresse mail alias: adresse mail destinataire
postmaster@yannir.xyz: yair@yannir.xyz
abuse@yannir.xyz: yair@yannir.xyz

Redémarrer le service

sudo systemctl restart maddy

Msmtp

msmtp est un client SMTP très simple et facile à configurer pour l’envoi de courriels.

Installer le paquet msmtp et définir des permissions restrictives sur le fichier /etc/msmtprc :

        
      
sudo apt update
sudo apt install msmtp  # Enable AppArmor --> Non
touch $HOME/.msmtprc
chmod 600 $HOME/.msmtprc

Définir msmtp comme le programme par défaut pour sendmail :

sudo ln -fs /usr/bin/msmtp /usr/sbin/sendmail

La configuration $HOME/.msmtprc pour yair@yannir.xyz

defaults
auth on
tls on
tls_trust_file /etc/maddy/certs/mx1.yannir.xyz/fullchain.pem
logfile ~/.msmtp.log
#
account yair_maddy
host mx1.yannir.xyz
port 587
from yair@yannir.xyz
user yair@yannir.xyz
password mot_de_passe_user 
#
account default : yair_maddy

Msmtp envoi message depuis xoyaz.xyz en une ligne de commande

        
      
printf "To: yanfi@yanfi.net\nFrom: yair@yannir.xyz\nSubject: Test msmtp yannir.xyz...\n\nCeci est un test...\n" | \
msmtp --account=yair_maddy \
      yanfi@yanfi.net

Test et vérification serveur mail

17 outils SMTP pour diagnostiquer et tester la sécurité du courrier électronique

Validateur MTA-STS

Validateur MTA-STS gratuit

CheckTLS

CheckTLS vous permet de vérifier la sécurité de votre messagerie et le fonctionnement de vos courriels. EmailSentry Outlook vous aide à vous assurer que tous les courriels que vous envoyez sont privés, légaux et sûrs.

L’outil est approuvé par HIPAA, CCPA, PCI, GDPR et d’autres réglementations de conformité pour la sécurité des emails. CheckTLS vous aide également à résoudre les problèmes détectés dans vos courriels après le test.

Patienter pour la réception du message…

MTA-STS Lookup

MTA-STS Lookup - Check domains for Inbound Transport Layer Security (TLS) Enforcement - MxToolbox

Mx lookup

Mx lookup - MxToolBox

Vérifier DKIM

Vérifier DMARC

Mail-tester

mail-tester.com est un service en ligne gratuit qui vous permet de tester vos e-mails pour les problèmes de configuration Spam, Contenu Malformé et Mail Server

Allez au testeur de courrier https://www.mail-tester.com/.

Résultats

Note 10/10 avec 2 remarques sans conséquences:

Il n’y a pas de version HTML de votre message.
Vérifiez si votre message est bien formaté ou non
Votre message ne contient pas d’en-tête List-Unsubscribe
L’en-tête List-Unsubscribe est nécessaire si vous envoyez des emails en masse, il permet à l’utilisateur de facilement de désinscrire de vos listes.

Machine, VPS

messagerie

Cet article est sous licence CC BY 4.0 par l'auteur.