Jusqu'ici il était particulièrement difficile d'installer un serveur mail personnel, sans devoir y passer des journées entières. Cela demandait des compétences d'administration extraordinaires, et une maintenance permanente du fait de l'adjonction continuelle de protocoles de sécurités qu'il fallait mettre en place, au risque sinon de se faire "blacklister" (un problème de réputation et de refus des mails).

Mais mailinabox est un serveur mail "tout en un", que l'on héberge sans que l'on doivent être un expert unix. Non seulement il en simplifie énormément la gestion mais il offre une interface pratique et une sécurité considérable, des sauvegardes incrémentales, des filtres anti-spam modernes et efficaces, et même des services additionnels. Oui, c'est assez incroyable!

• Héberger vos emails et/ou ceux de vos clients
• Pas de limitation sur le nombre d'adresses mails, ou de volume de stockage (disque dur)
• Pouvoir créer des adresses en 30 secondes pour des usages temporaires (et limiter le spam): il existe meme une API pour créer ou supprimmer des comptes à distance!
• Bénéficier d'une gestion des calendriers et contacts, etc.

Ce système vient avec un nombre non négligeable de services:

• bien entendu, un serveur mail (IMAP et SMTP)
• un "webmail" (roundcube)
• pas de mailing list directe, mais cf mlmmj par exemple
• serveur web statique
• munin (moniteur de charge serveur)
• owncloud ou nextcloud (stockage de fichiers partagé)
• la gestion de contacts (CardDAV) et de calendrier (CalDAV), lié à owncloud

A noter pour les deux derniers points, on préfère utiliser une instance de nextcloud sur un serveur à part, dédié au stockage, plutôt que de dépendre de celui sous-jacent à la gestion de emails, mais c'est un choix discutable.

(document officiel ici)

On recommande fortement l'utilisation d'un serveur "dédié" à ce service, afin de réduire les risques d'interférerence de service et d'erreurs de manipulation. Par exemple, mailinabox en version standard vient avec des serveurs "nginx" et DNS préconfigurés, une certification letsencrypt, et qu'il faudrait modifier pour l'adjonction d'un service supplémentaire "maison".

Mail-in-a-Box peut gérer les mails de plusieurs domaines, mais il doit lui-même résider sur un nom propre et unique (ex. mx.monserveur.com).

Il dispose de son propre serveur DNS (solution idéale pour une auto-configuration), mais on peut aussi utiliser un DNS existant chez son "registrar" habituel. Il alors faudra faire des manipulations dans son DNS existant, pour les enregistrements de type "MX" et les envoyer sur l'IP du serveur mailinabox (ex. mx.tecrd.com qui pointe vers l'IP du serveur mailinabox). D'autres éléments sécurisants seront à ajouter, mais ils seront clairement indiqué par mailinabox lui-même (principalement de simples couper/coller dans la zone DNS)!

Un bon endroit pour souscrire et gérer ses noms de domaine est gandi.net car il gère bien DNSSEC avec mail-in-a-box. Cela reste cependant optionnel, mais utile pour augmenter le sécurité de l'ensemble.

Pensez aussi à ajouter l'IP v6 chez votre registrar (ex. OVH) dans le DNS. L'IPv6 est indiquée dans l'interface de mailinabox:

mx  86400 IN AAAA   2001:bc8:4444:2cab::f:621

A noter, surtout pour des serveurs virtuels, il est essentiel de vérifier que l'adresse IP se son (futur) serveur mail n'est pas marquée comme "spammer", par exemple avec l'outil en ligne mxtoolbox (saisir son IP ou nom de domaine).

Attention, il m'est arrivé avec des vieux gestionnaires d'emails archaiques comme @hotmail ne me faire refuser du courriel en envoi, car Microsoft "blackliste" toute une plage d'IP de serveurs chez l'hébergeur, arbitrairement. Ils partent du principe que si l'une des IP a pu faire du spam alors tout le monde est condamné ("si ton voisin avait volé alors tu es un voleur aussi"). Cette pratique est abusive, d'autant qu'il est difficile d'aller se "whitelister", et qu'il faut même parfois payer pour cela. En ce qui me concerne, je dis au destinataire que sont adresse mail n'est pas aux normes (c'est le cas, et on me répond souvent que ces adresses posent en effet des problèmes…) Mail in a box est incroyablement solide et bien configuré, souvent mieux que des systèmes connus tels que @free par exemple (vérifiez avec les outils en ligne !).

Pour l'installation proprement dite, c'est aussi simple que de se logguer sur le serveur et de lancer:

curl -s https://mailinabox.email/setup.sh | sudo -E bash

la mise a jour de mailinabox se fait exactement de la même manière (le système conserve les mails et paramétrage existants). Cette commande fait aussi la mise à jour du système linux sous-jacent (pas besoin de apt upgrade donc).

Si jamais l'on veut stocker ses mail dans un emplacement particulier (ex. sur un volume externe ou réseau monté), on peut indiquer en amont de la commande ci-dessus son emplacement: export STORAGE_ROOT=/chemin/vers/ses/donnees.

La suite se fait en pas-à-pas directement dans l'interface web qui aura été montée par l'installeur: https://mx.mondomaine.com/admin

Bug: si l'installation s'arrête sur la ligne d'installation relative à "Spamassassin" sans vous donner d'URL, il faut corriger un problème lié à Scaleway (due au mode "minimised" de leurs images):

apt-get remove --purge sudo
### rm -rf /etc/sudoder.d   (essayez sans le faire dans un premier temps)
apt-get install sudo
# Et on réinstalle:
mailinabox

Suivire ensuite les indications de l'interface web dont l'URL est donnée à la fin de l'installation.

Chez Scaleway, allez dans l'onglet "Flexible IPs", puis dans le petit menu

• Edit Reverse
• mx.tecrd.com: nom DNS du serveur email
• Selected Flexible IP: celui du serveur mailinabox)

La console web d'administration de mailinabox vous donnera des champs supplémentaires à ajouter dans votre zone DNS, chargés de blinder votre service mail, dont les champs suivants ( utilisez les valeurs donnés par votre serveur mail):

                 86400 IN TXT    "v=spf1 mx -all"
_dmarc           86400 IN TXT    "v=DMARC1; p=quarantine"
mail._domainkey  86400 IN TXT    ( "v=DKIM1; k=rsa; s=email; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEF...x1hWYwBtbz+j34qpt" "Rs7Zdv...fcQ4wIDAQAB" )

Additionnellement (probablement zélé):

_dmarc.www       86400 IN TXT    "v=DMARC1; p=reject"
www              86400 IN TXT    "v=spf1 -all"
_dmarc.ns1.mx    86400 IN TXT    "v=DMARC1; p=reject"
ns1.mx           86400 IN TXT    "v=spf1 -all"
_dmarc.ns2       86400 IN TXT    "v=DMARC1; p=reject"
ns2.mx           86400 IN TXT    "v=spf1 -all"

Par défaut et par sécurité, mailinabox refusera l'envoi de mails depuis un domaine tiers.

Pour permettre au serveur "autre.com" (d'adresse IP 51.158.77.80) d'envoyer des mails, il faut ajouter une règle pare-feu sur le serveur mailinabox (dont l'IP interne est 10.16.108.33, comme l'indique ifconfig sur le serveur mail lui-même):

iptables -t nat -I PREROUTING --src 51.158.77.80 --dst 10.16.108.33/8 -p tcp --dport 58793 -j REDIRECT --to-ports 587

• Si l'on crée un compte noreply@mondomaine.com, on pourra envoyer un mail, en s'identifiant complètement sous ce compte et en utilisant le port non standard 58793 à la place du 587 (pratique pour contourner des restrictions SMTP sortant par exemple). C'est typiquement utile pour envoyer des notifications automatiques, par exemple depuis dokuwiki.

attention aussi aux limitations d'usage, par exemple pour un forum un peu actif ! Il faudra "whitelister" les IP sources dans les entrées ignoreip de /etc/fail2ban (plusieurs endroits possibles: qui s'écrasent mutuellement).

• Si l'on veut pouvoir re-router divers adresses à travers mailinabox, c'est plus compliqué: il faut configurer mailinabox pour se comporter comme relai pour le site distant (par défaut, c'est refusé). Voir alors la procédure Relaying For Other Machines (en anglais)

Parfois le système "postgrey" de filtrage de spam fait du zèle et empêche la redirection (réception) d'emails depuis un autre serveur. C'est un système amont de filtrage de spam qui repose sur le bon comportement des serveur d'envoi de mail (qui doivent ré-essayer si jamais le serveur leur répond qu'il est occuppé, ce que ne font pas les spammeurs).

Vous pouvez ajouter des noms de domaines toujours accpetés dans cette liste, en en mettant un par ligne. Il s'agit bien du serveur d'envoi, et non du domaine de l'adresse From de l'email:

/etc/postgrey/whitelist_clients.local

Vous pouvez aussi réduire le délai de renvoi dans /etc/default/postgrey pour réduire les rejets (source):

POSTGREY_OPTS="--inet=127.0.0.1:10023 --delay=1"

Puis redémarrer le service

service postgrey restart

Si /var/log/mail.log indique des lignes de ce type:

''Feb 16 18:18:16 mx postfix/anvil[9562]: statistics: max connection (...)''

En pratique ce n'est pas grave (c'est juste informatif, tant qu'il n'y a pas un reject explicite!). Mais vous pouvez tenter d'ajouter le nom de domaine à laisser passer en créant un fichier /etc/postfix/rbl_override (un domaine suivi de OK par ligne). Lancez ensuite la commande postmap /etc/postfix/rbl_override, par exemple

root@mx:~# cat /etc/postfix/rbl_override
tecrd.com OK
yaknou.com OK
kideba.com OK

Enfin, ajoutez check_client_access hash:/etc/postfix/rbl_override à l'entrée smtpd_recipient_restrictions de /etc/postfix/main.cf si elle n'y est pas déjà, et relancez service postfix restart.

(source)

Vérifiez aussi les limites de fail2ban et de postfix qui peuvent limiter la fréquence d'utilisation du serveur mail. Vous pouvez ajouter les IP de vos serveur tiers dans:

• les entrées ipallow de /etc/fail2ban (plusieurs occurrences)
• le mynetworks = de /etc/postfix (anvil est le système limiteur)

Les deux fichiers principaux à observer sont:

• /var/log/mail.log
• /var/log/mail.err

C'est utile notamment lorsqu'un client est refusé ou une redirection perdue, afin de voir si le serveur les a vu passer et en connaître la raison (ex. relai interdit).

Voyez aussi les outils en ligne de diagnostics, tels que https://mxtoolbox.com/

Le système crée des sauvegardes incrémentales automatiquement, mais il est possible d'en faire manuellement (c'est recommandé pour récupérer une version complète de temps en temps). A noter le fichier backup/secret_key.txt qui contient la clé de cryptage nécessaire (que l'on pourrait à juste titre ne pas vouloir stocker dans l'archive!):

cd mailinabox
sudo management/backup.py
cd /home/user-data
tar czf backup-manuel-$(date +'%Y%m%d-%H%M%S').tar.gz backup/encrypted backup/secret_key.txt

Ce fichier tgz peut être ensuite copié sur un autre serveur pour archivage. Pour le restaurer sur mailinabox, il faudra retransmettre l'archive vers le serveur, puis:

tar xzf backup.tar.gz
export PASSPHRASE=$(cat /root/backup/secret_key.txt)
sudo -E duplicity restore --force file:///root/backup/encrypted /home/user-data/

A ce stade, vérifier la page d'accueil et reprovisionner le certificat SSL si besoin, puis:

mailinabox

L'administration se trouve sur https://mx.mondomaine.com/admin

Le webmail se trouve sur https://mx.mondomaine.com/mail

Pour avoir un log vivant et filtré des principaux problèmes (hors rejet de spam):

stdbuf -i0 -o0 -e0 tail -F /var/log/mail.log | grep --line-buffered  -v 'RCPT.*blocked using zen.spamhaus.org' | egrep --line-buffered  -i 'action=[^,]*,|reject[$ ,:]|max connection rate'

On peut renforcer et augmenter sa note (sur ns.tools par exemple) avec ces modifications avancées. elles sont non seulement optionelles mais se feront en partie écraser lors des mises à jour, donc à surveiller et remettre en place:

Configuration et réduction de la verbosité du serveur mail:

sed -i 's/^\s*smtpd_banner=.*Mail-in-a-Box.*/smtpd_banner=$myhostname ESMTP Hi/' /etc/postfix/main.cf
grep -q disable_vrfy_command /etc/postfix/main.cf || echo 'disable_vrfy_command=yes' > /etc/postfix/main.cf