Mettre en place un serveur email perso

Sommaire

Si les emails sont quelque chose de courant sur internet, la mise en place d’un serveur d’emails n’est pas quelque chose de trivial. On trouve donc de nombreux tutoriaux sur le net, plus ou moins fiable, plus ou moins complets et plus ou moins obsolètes. Chacun ayant une manière de faire et ses logiciels préférés, voici la mienne.

Les pré-requis
#

Ce guide suppose que vous :

ayez les droits d’administration sur une machine (physique ou virtuelle) tournant sous un OS de type UNIX et reliée à internet ;
possédiez un nom de domaine ;
sachiez modifier les entrées DNS associées à ce nom de domaine ;
sachiez ce que sont des certificats X.509 (improprement appelés certificats SSL) ;
sachiez utiliser votre OS (en particulier, savoir gérer les démons, paquets, ports, …) ;
compreniez qu’en fonction de votre distribution l’emplacement exact des fichiers peut changer ;
soyez en mesure de faire des recherches par vous même ;
ne recopiez pas bêtement ce que vous voyez.

S’agissant de la connexion à internet, il est pré-supposé que celle-ci est directe et que la machine dispose d’une adresse IPv4 publique ainsi qu’une adresse IPv6 publique. Au besoin, il faudra adapter la configuration.

Recevoir des emails
#

Le MTA (Mail Transfer Agent) est le logiciel qui va vous permettre d’envoyer et recevoir des emails. Il en existe beaucoup (qmail, exim, postfix, sendmail, …), ici nous nous focaliserons sur un MTA qui a l’avantage d’être fiable, complet et surtout extrêmement simple à configurer : OpenSMTPD.

Une fois installé, la configuration s’effectue dans /etc/smtpd/smtpd.conf. Un simple man 5 smtpd.conf est là pour nous aider. Pour avoir un serveur email capable de recevoir des emails pour le domaine example.org, nous n’avons besoin que de ceci :

# SMTP port 25 from localhost
listen on 127.0.0.1
listen on ::1

# SMTP port 25 from external sources
listen on 203.0.113.42
listen on 2001:db8::42

action local_deliver maildir

match from local for local action local_deliver
match from any for domain "example.org" action local_deliver

Notez qu’ici l’action local_deliver permet de stocker les emails reçus au format Maildir, c’est à dire dans le dossier ~/Maildir de l’utilisateur.

Nous allons maintenant la rendre un peu plus robuste en utilisant TLS.

pki example.org cert "/var/lib/acmed/certs/example.org_ecdsa-p256.crt.pem"
pki example.org key  "/var/lib/acmed/certs/example.org_ecdsa-p256.pk.pem"
smtp ciphers "HIGH:!eNULL:!LOW:!MEDIUM:!EXP:!RC4:!3DES:!MD5:!SHA1:!PSK:!kRSA:!SRP:-DH:+ECDH"

# SMTP port 25 from localhost, with STARTTLS support
listen on 127.0.0.1    tls pki example.org hostname mx1.example.org
listen on ::1          tls pki example.org hostname mx1.example.org

# SMTP port 25 from external sources, with STARTTLS support
listen on 203.0.113.42 tls pki example.org hostname mx1.example.org
listen on 2001:db8::42 tls pki example.org hostname mx1.example.org

action local_deliver maildir

match from local for local action local_deliver
match from any for domain "example.org" action local_deliver

La clé privée ne doit pas être accessible (lecture, écriture, exécution), sauf pour le propriétaire. Le mieux est de lui mettre un chmod 600 ou chmod 400.

Ports
#

Pensez à accepter les nouvelles connexions TCP entrantes sur le port 25 (SMTP).

DNS
#

Afin d’avoir un serveur email accessible, il est important d’ajouter un champ MX à notre nom de domaine. On va le faire pointer sur un sous domaine qui, lui, disposera des entrées A et AAAA.

example.org.      IN  MX 10 mx1.example.org.
mx1.example.org.  IN  A     203.0.113.42
mx1.example.org.  IN  AAAA  2001:db8::42

Avant d’aller plus loin, vous devez vérifier si votre nom de domaine dispose d’un FCrDNS valide. Pour faire court, il faut que les requêtes de recherche inverse du DNS retournent le nom de domaine associé.

$ dig +short -x "203.0.113.42"
mx1.example.org.
$ dig +short -x "2001:db8::42"
mx1.example.org.

Si ce n’est pas le cas, corrigez votre configuration DNS.

Les alias
#

Pour l’instant, il n’est possible de recevoir que des emails pour les utilisateurs ayant un compte système, ces emails devant obligatoirement etre sous la forme login@example.org. Parfois, cette forme d’adresse email n’est pas désirable et l’on souhaite qu’un utilisateur reçoive des emails sur une adresse dont la partie avant l’arobase n’est pas son nom d’utilisateur. Pour cela, on peut créer des alias. Ainsi, si l’utilisatrice marie a comme alias root, alors elle pourra recevoir des emails à la fois sur marie@example.org et root@example.org, ces deux adresses désignant la même boite email.

Pour définir des alias, éditons le fichier /etc/smtpd/aliases. Notez qu’il est possible qu’un alias désigne un autre alias. C’est ainsi qu’ici plusieurs alias bien connus redirigent vers root, qui est lui-même un alias vers l’utilisatrice marie.

#
# Please run `smtpctl update table <table_name>` after any change to this file.
#

# Person who should get root's mail. Don't receive mail as root!
root:           marie

# Basic system aliases
MAILER-DAEMON:  postmaster
postmaster:     root

# General redirections for pseudo accounts
bin:            root
daemon:         root
nobody:         root
decode:         root

# Well-known aliases
manager:        root
dumper:         root
operator:       root
abuse:          root
admin:          root
webmaster:      root
hostmaster:     root
spam:           root

# Personal aliases
marie.lambda:      marie
lambda.marie:      marie
ernest.tartempion: ernest

Avec cette construction, si Marie souhaite abandonner son rôle d’administratrice au profit d’Ernest, il suffira de modifier l’alias root afin de le faire pointer sur ernest.

On ajoute ensuite à la configuration d’OpenSMTPD la table aliases et nous l’utilisons lors de la délivrances des emails.

table aliases "file:/etc/smtpd/aliases"

action local_deliver maildir alias <aliases>

Après chaque modification du fichier des alias il faut exécuter la commande smtpctl update table aliases.

Utilisateurs virtuels
#

Pour l’instant, notre MTA fait usage des utilisateurs du système. Si dans certaines situations c’est une bonne chose, dans d’autres ça ne l’est pas forcément. À titre personnel, je préfère utiliser un utilisateur virtuel afin d’avoir des mots de passe différents entre mon compte email et mon compte sur mon serveur dédié.

Créons donc le fichier /etc/smtpd/vusers qui contiendra, sur chaque ligne, nos utilisateurs au format <nom d'utilisateur>:<mot de passe haché> :

marie:$y$jCT$JnBTCfMf6qDY0YAyr.Wyz1$gFFF/qWkcclRfahZOcPa7Q2vTwYmX1omW34AL/kR9U1
ernest:$y$jCT$2JqWUNiukyr5XRvieZQS4.$RF7fRV9fCEqRw7k65A0iWFz1vp/MCpORif3p.aqvQj6
celestine:$y$jCT$bRvBpoQV2LtjoNC.ooKbe1$aIy2AMzL0Ip1ejE1AjV/A1kG.uyx51innV9ok/R5mO0

Les mots de passes sont hachés à l’aide de la fonction crypt(3) qui peut, par exemple, être appelée à l’aide de la commande smtpctl encrypt. Après chaque modification de ce fichier, on doit exécuter la commande smtpctl update table vusers.

Notez que pour l’instant nous ne faisons pas usage de ces utilisateurs virtuels. Nous les utiliseront dans les parties suivantes consacrées à la récupération puis l’envoi des emails.

Récupérer ses emails
#

Avoir les emails stockés dans le répertoire ~/Maildir des utilisateurs système c’est bien, mais il faudrait, d’une part, faire usage de nos utilisateurs virtuels à la place et, d’autre part, récupérer ces emails depuis un client de messagerie (également appelé MUA pour Mail User Agent) tel que Thunderbird ou mutt. Bien que ces deux parties soient théoriquement indépendantes l’une de l’autre, elles sont tout de même très liées dans la mesure où toutes les deux doivent connaître les utilisateurs ainsi que lire et modifier leurs emails.

Commençons avec la récupération des emails depuis un MUA. Pour cela, il nous faut mettre en place un serveur POP, IMAP ou JMAP. POP est un protocole ancien et peu pratique, nous éviterons donc de l’utiliser. JMAP est très récent mais malheureusement très peu implémenté, nous ne l’utiliseront donc pas non plus. Nous utiliseront ici Dovecot en tant que serveur IMAP.

Configuration générale
#

Le fichier /etc/dovecot/dovecot.conf contient la configuration générale de Dovecot. Nous allons y modifier les deux paramètres suivants :

protocols = imap sieve lmtp afin d’avoir un serveur IMAP, mais aussi utiliser Sieve et permettre la distribution de courriers depuis OpenSMTPD à l’aide de LMTP ;
listen = 203.0.113.42 2001:db8::42 afin que notre serveur IMAP écoute sur les IP publiques.

Distribution du courrier
#

Afin de stocker le courrier de nos utilisateurs virtuels, nous créons un nouvel utilisateur système vmail qui regroupera les dossiers de chaque utilisateur virtuel dans /var/vmail :

useradd --system --user-group --shell /usr/bin/nologin --home-dir /var/vmail --create-home vmail

Il nous faut maintenant indiquer à Dovecot comment utiliser notre base d’utilisateurs virtuels. Pour ceci, éditons le fichier /etc/dovecot/conf.d/10-auth.conf. Par défaut, ce fichier inclue un autre fichier décrivant la méthode à utiliser pour authentifier les utilisateurs. Nous commentons donc la méthode par défaut et ajoutons à la fin notre propre méthode :

#!include auth-system.conf.ext

!include auth-passwdfile-static.conf.ext

Et créons le fichier /etc/dovecot/conf.d/auth-passwdfile-static.conf.ext :

passdb {
  driver = passwd-file
  args = scheme=CRYPT username_format=%n /etc/smtpd/vusers
}

userdb {
  driver = static
  args = uid=vmail gid=vmail home=/var/vmail/%n
}

Assurons nous que, dans le fichier /etc/dovecot/conf.d/10-mail.conf, le chemin vers le dossier email des utilisateurs soit bien indiqué :

mail_location = maildir:~/Maildir

Comme mentionné plus haut, LMTP sera utilisé pour que Dovecot puisse distribuer aux utilisateurs les emails reçus par OpenSMTPD. Sa configuration se fait dans le fichier /etc/dovecot/conf.d/20-lmtp.conf. Assurons nous d’avoir activé le plugin Sieve.

protocol lmtp {
  mail_plugins = $mail_plugins sieve
}

Nous pouvons a présent ajuster la configuration d’OpenSMTPD afin de remplacer notre action qui délivrait le courrier dans le ~/Maildir des utilisateurs système afin de lui dire, à la place, de transmettre ces emails à Dovecot via LMTP afin que ce soit Dovecot qui effectue la délivrance du courrier.

action local_deliver lmtp "/run/dovecot/lmtp" alias <aliases>

L’adresse du socket peut varier suivant les systèmes.

Vous remarquerez qu’avec cette configuration, OpenSMTPD gère les alias et Dovecot gère les utilisateurs. Laisser Dovecot gérer la délivrance des emails permet de n’avoir à gérer l’emplacement du répertoire de stockage qu’avec Dovecot, mais également d’utiliser sieve afin de permettre aux utilisateurs de filtrer leurs emails.

Sieve
#

Sieve étant activé, nous pouvons le configurer dans le fichier /etc/dovecot/conf.d/20-managesieve.conf :

plugin {
  sieve = ~/.dovecot.sieve
  sieve_dir = ~/sieve
  sieve_extensions = +notify +imap4flags +imapflags +editheader
}

TLS
#

Afin d’utiliser TLS pour protéger les échanges entre le client et le serveur, nous éditons le fichier /etc/dovecot/conf.d/10-ssl.conf :

ssl = required

ssl_cert = </var/lib/acmed/certs/example.org_ecdsa-p256.crt.pem
ssl_key = </var/lib/acmed/certs/example.org_ecdsa-p256.pk.pem

ssl_min_protocol = TLSv1.2

ssl_cipher_list = HIGH:!aNULL:!eNULL:!LOW:!MEDIUM:!EXP:!RC4:!3DES:!MD5:!SHA1:!PSK:!kRSA:!SRP:-AES128:-DH:+ECDH
ssl_prefer_server_ciphers = yes

Sauf configuration particulière, toutes les autres lignes doivent être vides ou commentées.

Attention au certificat, pensez à utiliser quelque chose de mieux que ceux qui sont auto-générés. Remarquez que nous n’accepterons qu’au minimum TLSv1.2, les versions antérieures étant dépréciées. Si vous le pouvez, vous pouvez n’activer que la toute dernière version de TLS disponible en précisant LATEST.

Ports
#

Pensez à accepter les nouvelles connexions TCP entrantes sur le port 993 (IMAPS).

Anti-spam
#

Comme anti-spam, le plus simple est d’utiliser rspamd, ce dernier s’intégrant parfaitement à OpenSMTPD grâce à filter-rspamd. Une fois le filtre déclaré à l’aide de filter, il suffit de l’ajouter à la fin des listen d’où proviennent les emails de sources non-sûres.

filter "rspamd" proc-exec "/usr/lib/smtpd/opensmtpd/filter-rspamd"

listen on 203.0.113.42 tls pki example.org hostname mx1.example.org filter "rspamd"
listen on 2001:db8::42 tls pki example.org hostname mx1.example.org filter "rspamd"

Notez que le chemin vers l’exécutable filter-rspamd peut varier suivant votre distribution.

Filtrer ses emails
#

Nous pouvons maintenant utiliser sieve pour filtrer nos emails. La configuration se fait dans le fichier ~/.dovecot.sieve de chaque utilisateur (exemple: /var/vmail/marie/.dovecot.sieve). Un exemple de configuration :

require ["fileinto", "imapflags"];

if header :contains "X-Spam" "yes" {
  setflag "\\Seen";
  fileinto "Junk";
}
elsif address :is ["From", "To", "Cc", "Reply-to"] "nantes@lists.afpy.org" {
  fileinto "INBOX.Python.Nantes";
}
elsif address :is ["From", "To", "Cc", "Reply-to"] "python@example.org" {
  fileinto "INBOX.Python";
}

Cet exemple permet de marquer le spam comme lu et de le placer dans le dossier qui leur est dédié. Il y a ensuite des filtres pour placer automatiquement des emails dans certains dossiers.

Envoyer des emails
#

Afin d’envoyer des email en utilisant OpenSMTPD, il nous faut tout d’abord définir une table vusers correspondant à nos utilisateurs virtuels et écouter sur un nouveau port sur lequel on force l’authentification des utilisateurs.

table vusers  "file:/etc/smtpd/vusers"

# SMTPS port 465 from authenticated users
listen on 203.0.113.42 smtps pki example.org auth <vusers> hostname mx1.example.org mask-src
listen on 2001:db8::42 smtps pki example.org auth <vusers> hostname mx1.example.org mask-src

On indique ensuite que les emails envoyés par les utilisateurs locaux ou authentifiés à des utilisateurs externes doivent être relayés au destinataire.

action relay_out     relay helo example.org

# Relay outgoing emails
match from local for any action relay_out
match from any auth for any action relay_out

Ports
#

Pensez à accepter les nouvelles connexions TCP entrantes sur le port 465 (SMTPS) ainsi que les connexions TCP sortantes sur les ports 25 (SMTP) et 587 (submission).

DKIM
#

DomainKeys Identified Mail (DKIM) est une technique pour luter contre l’usurpation d’identité. Le principe est de signer (au niveau du serveur) les emails envoyés et de mettre la clé publique associée dans une entrée DNS. Par exemple, à la réception d’un email provenant de whatever@example.org, une requête DNS sur un sous domaine de example.org permet de récupérer la clé publique permettant de vérifier la signature de l’email. Si tout concorde, l’email à bien été envoyé par un serveur possédant la clé privée associée.

OpenSMTPD peut être étendu avec le principe des filtres qui sont des sortes d’extensions ou de plugins. Nous utiliserons donc filter-dkimsign afin de signer les emails que nous envoyons.

Comme son nom l’indique, filter-dkimsign est un filtre. Il s’agit donc d’un programme en ligne de commande capable de s’interfacer avec OpenSMTPD. Nous pouvons donc regarder la page de man correspondante (man 8 filter-dkimsign) pour consulter les arguments permettant de le configurer.

mkdir -p "/etc/smtpd/dkim"
chown smtpd:root "/etc/smtpd/dkim"
chmod 700 "/etc/smtpd/dkim"
cd "/etc/smtpd/dkim"
openssl genrsa -out "private.key" 2048
openssl rsa -in "private.key" -pubout -out "public.key"
chown smtpd:root "private.key" "public.key"
chmod 600 "private.key"

Et dans notre /etc/smtpd/smtpd.conf on déclare le filtre puis on l’utilise dans chaque source fiable :

filter "dkimsign" proc-exec "/usr/lib/smtpd/opensmtpd/filter-dkimsign -k '/etc/smtpd/dkim/private.key' -s 'pubkey' -d 'example.org'"

# SMTP port 25 from localhost, with STARTTLS support
listen on 127.0.0.1 tls pki example.org hostname mx1.example.org filter "dkimsign"
listen on ::1       tls pki example.org hostname mx1.example.org filter "dkimsign"

# SMTPS port 465 from authenticated users
listen on 203.0.113.42 smtps pki example.org auth hostname mx1.example.org mask-src filter "dkimsign"
listen on 2001:db8::42 smtps pki example.org auth hostname mx1.example.org mask-src filter "dkimsign"

Ajoutez ensuite une entrée TXT pour pubkey._domainkey.example.org dont la valeur est v=DKIM1; k=rsa; t=s; p=contenu_de_la_clef_publique (la liste des options est définie dans la RFC 6376.

Attention, pour les clés RSA de 2048 bits ou plus la clé publique dépassera la longueur maximale d’une une chaîne de caractères (255 bytes) dans les entrées TXT. Comme indiqué dans la RFC 7208, il faut alors utiliser plusieurs chaînes de caractères qui seront concaténées.

pubkey._domainkey.example.org.  IN  TXT  "v=DKIM1; k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEjPmxQHTJeBoHSJPuPMl0ry0q31TqoC2OuqUiVHSk3hM6x6oDat4pIischVYi/3ODsjBC6wg1BPgtfdVfzboAF/bQK+Kh0rBaQlv2vloP96mu6dmUGMJSo5BrtoAMdx6DbMe7s7TP58uAUknQNEL6s9w7iNF9gD/+yBiEB+yDYwIDAQAB"

SPF
#

Afin de luter contre l’usurpation d’identité on utilise également SPF, un système basé sur le DNS.

On ajoute donc une entrée TXT directement au domaine dont vont émaner les emails. On commence par v=spf1 puis on ajoute, séparées par des espaces, les adresses IP autorisées ou interdites à envoyer des emails pour ce domaine. Ainsi, on ajoutera a afin d’autoriser toute adresse visée par l’entrée A du domaine, MX pour la même chose mais avec l’entrée MX. On peut également ajouter des plages d’adresses IP à l’aide de ip4: et ip6: suivi de la notation CIDR. Si vous avez plusieurs addresses IP, n’oubliez pas de toutes les inclure car vous ne maîtrisez pas celle qui sera utilisée en sortie. Enfin, on termine avec -all afin d’interdire toutes les adresses que nous n’avons pas précédemment autorisé.

example.org.             IN  TXT  "v=spf1 a mx ip6:2001:db8::/32 -all"

Ne soyez pas laxiste dans cette configuration sinon certains anti-spam ne vont pas aimer les emails provenant de votre domaine.

DMARC
#

Enfin, le dernier système anti-spam que nous utiliserons est DMARC. Il permet notamment de définir s’il faut être strict ou laxiste dans le traitement de SPF et DKIM ainsi que la conduite à tenir en cas d’échec. Là encore, je recommande d’être très strict afin de passer les anti-spam de vos destinataires.

Afin de configurer DMARC, on ajoute une entrée TXT au sous-domaine _dmarc.

_dmarc.example.org.      IN  TXT  "v=DMARC1;adkim=s;aspf=s;p=reject;sp=reject;ruf=mailto:postmaster@example.org;fo=1"

Configurer un client de messagerie
#

La configuration de votre client de messagerie s’effectue comme tel :

Serveur entrant
#

Nom/adresse: votre nom de domaine
Protocole: IMAP
Sécurité: SSL/TLS
Port: 993
Méthode d’authentification: mot de passe
Nom d’utilisateur: votre nom d’utilisateur (pas d’alias ni email complet)
Mot de passe: celui de votre compte utilisateur

Serveur sortant
#

Nom/adresse: votre nom de domaine
Sécurité: SSL/TLS
Port 465
Méthode d’authentification: mot de passe
Nom d’utilisateur: votre nom d’utilisateur (pas d’alias ni email complet)
Mot de passe: celui de votre compte utilisateur

Récapitulatif
#

Réception d’un email
#

OpenSMTPD accepte l’email venant d’Ernest ;
OpenSMTPD passe l’email au filtre rspamd afin de détecter un éventuel email frauduleux ;
OpenSMTPD donne l’email à Dovecot via LMTP ;
Dovecot dépose l’email dans le dossier ~/Maildir de Marie (non illustré : il utilise sieve) ;
Marie consulte ses emails ;
Dovecot va chercher le nouvel email en provenance d’Ernest ;
Dovecot passe son email à Marie.

Émission d’un email
#

Marie envoie son email à OpenSMTPD ;
OpenSMTPD passe l’email à filter-dkimsign ;
filter-dkimsign renvoie l’email à OpenSMTPD après l’avoir signé ;
OpenSMTPD envoie l’email signé au destinataire.

Configuration d’OpenSMTPD
#

#
# Encryption
#

pki example.org cert "/var/lib/acmed/certs/example.org_ecdsa-p256.crt.pem"
pki example.org key  "/var/lib/acmed/certs/example.org_ecdsa-p256.pk.pem"
smtp ciphers "HIGH:!eNULL:!LOW:!MEDIUM:!EXP:!RC4:!3DES:!MD5:!SHA1:!PSK:!kRSA:!SRP:-DH:+ECDH"


#
# Tables
# If you edit a file, you have to run "smtpctl update table <table_name>"
#

table vusers  "file:/etc/smtpd/vusers"
table aliases "file:/etc/smtpd/aliases"


#
# Filters
#

filter "dkimsign" proc-exec "/usr/lib/smtpd/opensmtpd/filter-dkimsign -k '/etc/smtpd/dkim/private.key' -s 'pubkey' -d 'example.org'"
filter "rspamd" proc-exec "/usr/lib/smtpd/opensmtpd/filter-rspamd"


#
# Listening
#

# SMTP port 25 from localhost, with STARTTLS support
listen on 127.0.0.1 tls pki example.org hostname mx1.example.org filter "dkimsign"
listen on ::1       tls pki example.org hostname mx1.example.org filter "dkimsign"

# SMTP port 25 from external sources, with STARTTLS support
listen on 203.0.113.42 tls pki example.org hostname mx1.example.org filter "rspamd"
listen on 2001:db8::42 tls pki example.org hostname mx1.example.org filter "rspamd"

# SMTPS port 465 from authenticated users
listen on 203.0.113.42 smtps pki example.org auth <vusers> hostname mx1.example.org mask-src filter "dkimsign"
listen on 2001:db8::42 smtps pki example.org auth <vusers> hostname mx1.example.org mask-src filter "dkimsign"


#
# Actions
#

action local_deliver lmtp "/run/dovecot/lmtp" alias <aliases>
action relay_out     relay helo example.org


#
# Matches
#

# Deliver emails
match from local for local action local_deliver
match from any for domain "example.org" action local_deliver

# Relay outgoing emails
match from local for any action relay_out
match from any auth for any action relay_out

Tests
#

Certains outils sont là pour vérifier certaines parties de votre configuration :

Autres emails avec des auto-réponses pour tester DKIM et SPF
#

Pour vérifier que les emails que vous envoyez soient bien signés et que vous avez correctement défini votre SPF, il suffit d’envoyer un email à check-auth@verifier.port25.com (IPv6 + IPv4).

Support de l’IPv6
#

Pour vérifier si votre serveur supporte bien l’IPv6, envoyez un email à test@doesnotwork.eu et attendez la réponse automatique.

TLS
#

La configuration TLS peut être testée à l’aide de testssl.sh ou nmap :

testssl -t smtp 203.0.113.42:25
testssl -6 -t smtp "[2001:db8::42]:25"
testssl "203.0.113.42:465"
testssl -6 "[2001:db8::42]:465"
testssl "203.0.113.42:993"
testssl -6 "[2001:db8::42]:993"
nmap --script ssl-cert,ssl-enum-ciphers -p 465 "203.0.113.42"
nmap --script ssl-cert,ssl-enum-ciphers -p 465 -6 "2001:db8::42"
nmap --script ssl-cert,ssl-enum-ciphers -p 993 "203.0.113.42"
nmap --script ssl-cert,ssl-enum-ciphers -p 993 -6 "2001:db8::42"

Les pré-requis #

Recevoir des emails #

Ports #

DNS #

Les alias #

Utilisateurs virtuels #

Récupérer ses emails #

Configuration générale #

Distribution du courrier #

Sieve #

TLS #

Ports #

Anti-spam #

Filtrer ses emails #

Envoyer des emails #

Ports #

DKIM #

SPF #

DMARC #

Configurer un client de messagerie #

Serveur entrant #

Serveur sortant #

Récapitulatif #

Réception d’un email #

Émission d’un email #

Configuration d’OpenSMTPD #

Tests #

Autres emails avec des auto-réponses pour tester DKIM et SPF #

Support de l’IPv6 #

TLS #

Liens utiles #

Les pré-requis
#

Recevoir des emails
#

Ports
#

DNS
#

Les alias
#

Utilisateurs virtuels
#

Récupérer ses emails
#

Configuration générale
#

Distribution du courrier
#

Sieve
#

TLS
#

Ports
#

Anti-spam
#

Filtrer ses emails
#

Envoyer des emails
#

Ports
#

DKIM
#

SPF
#

DMARC
#

Configurer un client de messagerie
#

Serveur entrant
#

Serveur sortant
#

Récapitulatif
#

Réception d’un email
#

Émission d’un email
#

Configuration d’OpenSMTPD
#

Tests
#

Autres emails avec des auto-réponses pour tester DKIM et SPF
#

Support de l’IPv6
#

TLS
#

Liens utiles
#