Tuto Messagerie, partie II : Postfix

Tutoriel révisé en décembre 2022 / Debian 11

Seconde partie du tutoriel consacré à l’installation d’un serveur de messagerie. Préalablement, nous avons installé et configuré le serveur Ldap. Dans cette partie, nous allons mettre en place nos certificats et procéder à la configuration de base de Postfix.

I – Préparatifs

Avant de se lancer dans cette expérience qu’est de monter son serveur mail, il y a quelques points à régler.

A – Pointer Record

Dans le monde du SMTP, si vous voulez que votre serveur puisse envoyer des mails sans que les autres le jette comme un malpropre, il y a un premier point important :

Il est nécessaire que son reverse DNS (PTR, pointer record) soit correctement configuré : si on demande l’adresse de mail.debugo.fr à un DNS et qu’on obtient comme réponse 222.222.222.222, il faut qu’en demandant le PTR de 222.222.222.222 on obtienne mail.debugo.fr, sinon déjà la plupart des SMTP (dont le mien) vont rejeter.

On peut faire sans (pour la reception, pas de soucis), mais si on veut envoyer des mails, sans ca, c’est foutu. Bref, il faut une IP « dédié ».

Étant chez Online, j’ai donc pris une nouvelle IP Failover où j’ai configuré le reverse en mail.debugo.fr.
Ensuite, celle ci est branché sur ma VM routeur sur le bridge br0 (avec la mac bien renseignée !).

Pour information, voila comment cela est fait pour l’IP FO principale : Haute Disponibilité de routeurs sous Linux avec Keepalived

Pour configurer cette nouvelle IP FO sur le serveur, une fois OK côté Online, la démarche est la suivante :

On prépare les fichiers de conf sur l’hyperviseur :

Fichier net-extrout1-ipfo2.xml :

<interface type='network'>
    <mac address='xx:xx:xx:xx:xx:xx'/>
    <source network='ovs-front'/>
    <target dev='extrout1.3'/>
    <model type='virtio'/>
    <driver name='vhost'/>
</interface>

Fichier net-extrout2-ipfo2.xml :

<interface type='network'>
    <mac address='xx:xx:xx:xx:xx:xx'/>
    <source network='ovs-front'/>
    <target dev='extrout2.3'/>
    <model type='virtio'/>
    <driver name='vhost'/>
</interface>

On pense à remplacer la MAC par celle fournie par Online (ou tout autre prestataire)

On injecte :

hyperv# virsh attach-device extrout1 net-extrout1-ipfo2.xml --config --live
hyperv# virsh attach-device extrout2 net-extrout2-ipfo2.xml --config --live

Ensuite, sur les routeurs :

extroutX# ip addr add 222.222.222.222 dev eth3
extroutX# ip link set eth3 up

Un ping de l’extérieur vers cette IP doit fonctionner.

Ensuite, on va configurer les scripts de failover entre les routeurs.

Sur les deux, on édite le fichier/srv/keepup.sh et on ajoute ce qui est en gras :

#!/bin/bash
ip addr add 123.123.123.123 dev eth2
ip link set eth2 up
ip route add IP.GATEWAY dev eth2
ip route del default
ip route add 0.0.0.0/0 via IP.GATEWAY dev eth2
echo 1 > /proc/sys/net/ipv4/ip_forward
ip addr add 222.222.222.222 dev eth3
ip link set eth3 up
/srv/firewallup.sh
sleep 1
ping -c 1 IP.GATEWAY

Ça, c’est fait.

B – DNS

Passons maintenant à la partie DNS.
Sur notre serveur DNS on va renseigner les nouveaux enregistrements dans le fichier de zone correspondant :

      IN  MX  10 mail.debugo.fr
mail  IN  A   222.222.222.222

Le champ MX indique qu’il s’agit d’un serveur mail. Et ensuite, on définit simplement l’IP de mail.debugo.fr.

Si on gère son DNS (voir ici), on pense à incrémenter le serial et à recharger avec :

dns# rndc reload

Pour tester :

# dig debugo.fr MX +short

C – Routeur

On revient sur notre/nos routeur(s) (selon votre architecture…) pour y configurer le NAT.

Port en entrée :

• 25 -> SMTP
• 587 -> SUBMISSION
• 143 -> IMAP
• 993 -> IMAPS
• 4190 -> Managesieve
• 80 -> Pour la creation/ le renew du certificat SSL

Port en sortie :

• 25 -> SMTP
• 80 et 443 -> si besoin d’aller chercher un truc en http/https.

Version Iptables :

Pour ce qui vient :

iptables -t nat -A PREROUTING -d 222.222.222.222 -p tcp -m multiport --dports 25,80,143,587,993,4190 -j DNAT --to-destination ip.interne
iptables -t filter -A FORWARD -p tcp -d ip.interne -m multiport --dports 25,80,143,587,993,4190 -j ACCEPT

Pour ce qui nous quitte :

iptables -t filter -A FORWARD -p tcp -s 10.10.1.151 -m multiport --dports 25,80,443 -j ACCEPT
iptables -t nat -A POSTROUTING -s ip.interne -p tcp -m multiport --dports 25,80,443 -j SNAT --to 222.222.222.222

Juste le port SMTP et les ports Web. Ajoutez aussi le DNS (53) si vous n’avez pas de resolver interne (dans ce cas, corrigez moi ça en suivant ceci )

Version Nftables :

table ip filter {
  [...]
  chain forward {
    type filter hook forward priority 0; policy drop;
    [...]
    # Forward vers la VM Mail :
    ip daddr 10.10.1.151 tcp dport {25,80,587,993,4190} accept
    # Forward depuis la VM Mail :
    ip saddr 10.10.1.151  tcp dport {25,80,443} accept
    [...]
  }
  [...]
}

table ip nat {
  chain prerout {
    type nat hook prerouting priority -100; policy accept;
    [...]
    ip daddr 222.222.222.222 tcp dport {25,80,587,993,4190} dnat to 10.10.1.151
    [...]
  }
  chain postrout {
    type nat hook postrouting priority 100; policy accept;
    [...]
    ip saddr 10.10.1.151 tcp dport {25,80,443} snat 222.222.222.222 
    [...]
  }
}

Nftables, ca ne vous parle pas ? Alors, un peu de lecture : Nftables, la série de tutos.

II – Les ports dans le domaine du mail

On peut dire que la, c’est un peu le boxon… Et encore, le 465 dont je parlais encore il y a peu a officiellement tiré sa révérence.

Nous avons:

• Le port 25, SMTP, utilisé pour l’envoi de mail vers le serveur depuis d’autres serveurs.
• Le port 110, POP, désuet, utilisé pour rapatrier les mails sur un logiciel client.
• Le port 143, IMAP, permet de consulter sa messagerie, depuis un logiciel client, un webmail, un smartphone, etc…

A cela se rajoute leurs pendants sécurisés :

• Le port 587, SUBMISSION (chiffrement STARTLS), lui aussi utilisé par les logiciels clients pour envoyer des mails vers le serveur.
• Le port 995, POPS (chiffrement SSL/TLS)
• Le port 993, IMAPS (chiffrement SSL/TLS)

Les ports 25, 110 et 143 peuvent voir leurs connexions chiffrées avec STARTTLS, aussi appelé EXPLICIT SSL/TLS. Le client se connecte au serveur en non chiffrée et il négocie le chiffrement juste après. Cette phase se produisant au tout début, toutes les infos sont ensuite chiffrées.

Pour donner une image, en SSL/TLS, on a une conversion normal dans une canal chiffrée et en STARTTLS, on a une conversation chiffrée dans un canal en clair…

Alors pourquoi garder les deux ? Les RFC recommandent maintenant de tout faire en SSL/TLS (un potentiel Man-in-the-middle est possible en STARTTLS.)
Mais de vieux clients peuvent encore nécessiter la présence des ports avec TLS explicite… Du coup, bah, vous faites comment vous le sentez…

Pour le tuto, j’ai choisie de tout mettre dans la configuration pour vous montrer. Perso, en prod, je pars sur du SSL/TLS.

Pour le port 25, Le STARTTLS est proposé si le MX distant le supporte.

III – Installation

Sur une nouvelle VM :

# apt install postfix postfix-ldap ca-certificates

Lors de l’installation de Postfix, répondez :

Internet Site
mail.debugo.fr

Cela sera renseigné dans le fichier /etc/mailname.

Pour ca-certificates, il est toujours bon de l’avoir et il nous sera utile pour l’installation de Rspamd plus tard.

Et on installe dans la foulée Dovecot :

# apt install dovecot-core dovecot-imapd dovecot-ldap dovecot-managesieved dovecot-sieve dovecot-lmtpd

A vrai dire, je l’installe de suite car le script de mise à jour du certificat redémarre les services postfix et dovecot , donc autant éviter des erreurs dès le début…

IV – Certificat

On va de suite gérer le certificat avec acme.sh (client pour Let’s Encrypt, plus d’informations dans mon article) :

# apt install git socat

Installons maintenant acme.sh :

# cd
# mkdir sources
# cd sources/
# git clone https://github.com/Neilpang/acme.sh.git
# cd ./acme.sh
# ./acme.sh --install
# ./acme.sh --set-default-ca --server letsencrypt

On recharge le bash :

# source /root/.bashrc

Et on lance la création du certificat :

# acme.sh --issue -k 4096 --standalone -d mail.debugo.fr --log

On installe le certificat :

# mkdir /etc/ssl/private/debugo.fr
# acme.sh --installcert -d mail.debugo.fr --cert-file /etc/ssl/private/debugo.fr/cert.pem --key-file /etc/ssl/private/debugo.fr/key.pem --ca-file /etc/ssl/private/debugo.fr/ca.pem --fullchain-file /etc/ssl/private/debugo.fr/fullcert.pem --reloadCmd 'service postfix reload && service dovecot reload'

On génère nos clés DH :

# openssl dhparam -out /etc/ssl/private/debugo.fr/dh512.pem 512
# openssl dhparam -out /etc/ssl/private/debugo.fr/dh2048.pem 2048
# chmod 644 /etc/ssl/private/debugo.fr/dh{512,2048}.pem

La commande installcert met également en place une tache cron pour le renouvellement automatique de votre certificat qui du coup, renouvelle, copie ou il faut et relance, parfait !

V – Postfix

A – main.cf

On va éditer le fichier /etc/postfix/main.cf pour le mettre à notre sauce :

mynetworks = 10.0.0.0/8
inet_interfaces = all
inet_protocols = ipv4
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
append_dot_mydomain = yes
readme_directory = no
compatibility_level = 2

notify_classes = bounce, delay, policy, protocol, resource, software
myhostname = mail.debugo.fr
mydestination = $myhostname, mail, localhost.localdomain, localhost, mail1.debugo.fr
myorigin = $myhostname
disable_vrfy_command = yes
strict_rfc821_envelopes = yes
show_user_unknown_table_name = no
message_size_limit = 0
mailbox_size_limit = 0
allow_percent_hack = no
swap_bangpath = no
recipient_delimiter = +
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

broken_sasl_auth_clients=yes

smtp_tls_security_level = may
smtp_tls_session_cache_database  = btree:${data_directory}/smtp_tlscache

smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_key_file = /etc/ssl/private/debugo.fr/key.pem
smtpd_tls_cert_file = /etc/ssl/private/debugo.fr/fullcert.pem
smtpd_tls_protocols = !SSLv2 !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3
smtpd_tls_mandatory_ciphers = high
smtpd_tls_eecdh_grade = strong
smtpd_tls_dh512_param_file  = /etc/ssl/private/debugo.fr/dh512.pem
smtpd_tls_dh1024_param_file = /etc/ssl/private/debugo.fr/dh2048.pem
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_tlscache
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_received_header = yes

smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous

tls_preempt_cipherlist = yes
tls_high_cipherlist = ALL EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !MEDIUM !3DES !MD5 !EXP !PSK !SRP !DSS !RC4
tls_ssl_options = no_ticket, no_compression
smtpd_helo_required = yes

smtpd_client_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unknown_reverse_client_hostname,
    reject_unauth_pipelining

smtpd_helo_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unauth_pipelining

smtpd_sender_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    reject_unauth_pipelining

smtpd_relay_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    ### VITAL, empêche l'open relay :
    reject_unauth_destination

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain,
    reject_unauth_pipelining

smtpd_data_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_multi_recipient_bounce,
    reject_unauth_pipelining

virtual_transport = lmtp:unix:private/dovecot-lmtp
virtual_mailbox_domains = ldap:/etc/postfix/ldap/virtual_domains.cf
virtual_mailbox_maps = ldap:/etc/postfix/ldap/virtual_mailbox.cf
virtual_alias_maps = ldap:/etc/postfix/ldap/virtual_alias.cf

B – Explications

append_dot_mydomain = yes

notify_classes = bounce, delay, policy, protocol, resource, software

myhostname = mail.debugo.fr
mydestination = $myhostname, mail, localhost.localdomain, localhost

smtp_tls_security_level = may

smtpd_tls_security_level = may

smtpd_tls_auth_only = yes

J’ai hésité à commenter toutes les restrictions… mais la doc de Postfix à ce sujet vous aidera à ma place.
Ce sont de bonnes restrictions pour commencer: elles permettent déjà de rejeter quelques tentative de spams.

Dans la partie IV du tuto, nous verrons plus en détails comment améliorer cela.

Un point important à connaitre : les permit ou reject sont testés dans l’ordre et dès que l’un match, cela stop pour la restriction en cours. L’ordre à donc une importance.

Grosso modo, pour chaque restriction, à chaque fois, j’autorise mon réseau local, mes utilisateurs authentifiés (mails soumis) et rejette les trucs mal fagotés…

C – Master.cf

On va ensuite modifier le fichier /etc/postfix/master.cf au début  :

submission    inet    n    -    y    -    -    smtpd
  -o smtpd_tls_security_level=encrypt

On active submission, et on surcharge (-o le paramètre smtpd_tls_security_level à encrypt pour forcer le TLS.

Un peu plus bas, on va activer le smtps :

smtps    inet    n    -    y    -    -    smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_tls_wrappermode=yes

Le reste ne change pas.

Pourquoi Postfix utilise deux fichiers de configuration ?

Le fichier main.cf définit les options générales de Postfix. Le fichier master.cf, lui sert à gérer les sous process de Postfix et permet de modifier certains paramètres du fichier main.cf en les surchargeant (option -o).

D – Le Ldap

On va créer nos fichiers chargés de faire la liaison avec le serveur ldap et les ranger :

# mkdir /etc/postfix/ldap
# cd /etc/postfix/ldap

Fichier virtual_domains.cf :

server_host = ldap://ip.ldap
version = 3
bind = yes
bind_dn = cn=viewer,ou=system,dc=debugo,dc=fr
bind_pw = passview
search_base = ou=mail,dc=debugo,dc=fr
scope = sub
query_filter = (&(maildomain=%s)(objectClass=maildomaindebugo)(maildomainactif=YES))
result_attribute = maildomain

Fichier virtual_mailbox.cf :

server_host = ldap://ip.ldap
version = 3
bind = yes
bind_dn = cn=viewer,ou=system,dc=debugo,dc=fr
bind_pw = passview
search_base = ou=people,dc=debugo,dc=fr
scope = sub
query_filter = (&(mail=%s)(objectClass=mailaccountdebugo)(mailaccountactif=YES))
result_attribute = mail

Et le fichier virtual_alias.cf :

server_host = ldap://ip.ldap
version = 3
bind = yes
bind_dn = cn=viewer,ou=system,dc=debugo,dc=fr
bind_pw = passview
search_base = ou=mail,dc=debugo,dc=fr
scope = sub
query_filter = (&(mailaliasfrom=%s)(objectClass=mailaliasdebugo)(mailaliasactif=YES))
result_attribute = mailaliasto

Pour des explications sur les filtres, vous en aurez dans la partie suivante, consacrée à Dovecot.

On sécurise :

# chmod 640 /etc/postfix/ldap/
# chown :postfix /etc/postfix/ldap/*

Puis on recharge Postfix :

# postfix reload

E – Tests

On peut tester les liens avec le ldap :

# postmap -q debugo.fr ldap:/etc/postfix/ldap/virtual_domains.cf

nous retourne le domaine s’il existe.

# postmap -q postmaster@debugo.fr ldap:/etc/postfix/ldap/virtual_alias.cf

donne le compte vers le lequel est envoyé l’alias.

# postmap -q toto@debugo.fr ldap:/etc/postfix/ldap/virtual_mailbox.cf

nous retourne le mail s’il existe.

F – Alias locaux

Il reste un dernier petit point, les alias locaux de la machine.

Comme je l’ai dis avant, je veux qu’à terme, ce serveur mail gère également les mails de mes autres VMs pour tout centraliser.

Et je veux tout rapatrier sur mon adresse mail toto@debugo.fr.

On édite le fichier /etc/aliases pour y mettre :

postmaster: postmaster@debugo.fr
root: toto@debugo.fr

Pour mémoire, postmaster@debugo.fr est défini comme un alias de toto@domaine1.fr dans le ldap.

On exécute la commande :

# newaliases

pour convertir cela en fichier un fichier compréhensible de postfix et on le recharge :

# postfix reload

VI – Conclusion

Postfix est opérationnel. Vous voyez, ce n’est pas si terrible ! On ne fait qu’effleurer la configuration, la documentation de Postfix  est très complète et on peut configurer plein de scénarios…

Maintenant pour le tester, comme nous n’avons pas encore Dovecot derrière, on va se contenter de juste tester la communication d’un MX vers le nôtre :

Le site https://www.checktls.com/TestReceiver permet de faire cette vérification, et l’on voit de suite si le TLS est bon. On peut aussi classiquement en telnet, mais c’est… long…

Le site https://mxtoolbox.com/ est très pratique également.

Ha oui, au passage, le fichier clé pour debug, c’est bien évidement le fidèle :

/var/log/mail.log

Voila qui termine pour le moment le sujet Postfix. Dans la partir suivant, nous allons mettre en place Dovecot.