Déléguer l'envoi des mails depuis un serveur (Msmtp)
Msmtp
Paramétrer un serveur mail complet, c'est compliqué et un peu overkill sur chaque machine qu'on gère. Par contre, j'aimerais recevoir les mails systèmes de mes serveurs sur mon adresse mail.
J'ai réussi à m'envoyer un mail directement en utilisant la solution suivante. On peut utiliser autre chose que bsd-mailx mais il fonctionne et a peu de dépendances.
sudo apt install msmtp msmtp-mta bsd-mailx
Ensuite on configure un fichier appelé msmtprc (/etc/msmtprc
pour tout le système, suivi d'un “chmod o-r”, sinon un ~/.msmtprc
sur lequel on fait un chmod 600
).
nano /etc/msmtprc
Ici je met deux config “pour mémoire”, Gandi (que je ne vais plus utiliser) et Nordcantal (qui est mon propre domaine). À adapter à vos propres serveur sortants smtp.
- /etc/msmtprc
# Compte Gandi account gandi host mail.gandi.net tls on tls_certcheck off tls_starttls off auth on port 465 from user@nomdomaine.com user user@nomdomaine.com password (mettezlevotre) logfile /var/log/.msmtp.log aliases /etc/aliases # Compte Nordcantal account lievre host poste.nordcantal.fr tls on tls_certcheck on tls_starttls on auth on port 587 from user@nomdomaine.com user user@nomdomaine.com password (mettezlevotre) syslog LOG_MAIL aliases /etc/aliases # Définir le compte par défaut account default : lievre
Il est possible que Apparmor fasse des siennes et empêche d'écrire dans le fichier de log (cf ici).
Solution simple et efficace : enlever la ligne logfile /var/log/.msmtp.log
et mettre syslog LOG_MAIL
dans /etc/msmtprc
.
Les logs seront gérés par syslog, et nous aurons dans /var/log un “mail.log” qui bénéficiera de la logique de logrotate.
Tester l'envoi d'un mail :
echo 'Subject:Yo' | msmtp user@nomdomaine.com
Vérifier que ça logue même envoyé depuis un user de base.
Éditer les aliases afin que root renvoie au mail :
sudo nano /etc/aliases
Ajouter à la fin de ce fichier root: user@nomdomaine.com
1) et ajouter aussi à chaque fin de redirection un @
2), ce qui devrait donner :
# /etc/aliases mailer-daemon: postmaster@ postmaster: root@ nobody: root@ hostmaster: root@ usenet: root@ news: root@ webmaster: root@ www: root@ ftp: root@ abuse: root@ noc: root@ security: root@ default: user@nomdomaine.com root: user@nomdomaine.com
default
est nécessaire pour recevoir les messages adressés aux utilisateurs linux. Vous pouvez aussi les déclarer un par un, avec des adresses mails différentes :
user1: user1@nomdomaine.com user2: user2@chezmoi.com
Laissez tout de même une variable default
pour ne rien louper.
Éditer aussi /etc/mail.rc
pour indiquer d'utiliser msmtp comme MTA.
sudo nano /etc/mail.rc
Ajoutez à la fin :
set mta=/usr/bin/msmtp
Pour tester si tout marche en envoi à root :
echo "Test" | mail -s "Test " root
Vérifier la sécurité
Pour éviter que le mot de passe du mail soit visible par toute personne connectée au serveur, on peut améliorer un peu les choses.
Il y a des méthodes diverses pour stocker le mot de passe mais la plupart me semblent compliquées à concilier avec un usage serveur : on ne peux pas entrer le mot de passe manuellement quand un courrier veut être envoyé. Si vous voyez comment faire mieux, je prends.
On peut stocker le mot de passe dans un fichier séparé en ayant cette ligne à la place de password
:
passwordeval "cat /etc/secret/msmtp"
(ou tout autre chemin). Cependant je ne suis pas sûre de voir l'intérêt d'un autre fichier, si son accès dépend des mêmes contraintes que /etc/msmtprc
.
On va créer un group qui aura le droit d'envoyer les mails (mais pas de modifier la configuration, réservée à root), y mettre des utilisateurs systèmes, et renforcer les droits sur le fichier de msmtp : la lecture sera interdite à tout le monde sauf le nouveau groupe, et la modification réservée à root.
sudo groupadd smtpusers sudo usermod -aG smtpusers backup sudo usermod -aG smtpusers mail sudo usermod -aG smtpusers www-data sudo chown root:smtpusers /etc/msmtprc sudo chmod 640 /etc/msmtprc
⇒ J'ai par défaut ajouté les users systèmes “backup, mail, www-data” au groupe, car ils ont parfois besoin d'envoyer des mails. On peut aussi ajouter son/ses utilisateurs personnels, mais ça n'a pas grand intérêt sur un serveur. Suivant ce qu'on installe comme logiciel, il faut veiller à ce qu'ils puissent envoyer des mails si besoin en faisant partie de ce groupe.
Avec Scaleway
Scaleway propose des emails transctionnels pour pas cher. Un peu technique pour paramétrer ça chez eux (faudra que je note aussi), et côté msmtp ça donne ça :
# Compte Scaleway account scaleway host smtp.tem.scw.cloud tls_certcheck off tls_starttls off tls on tls_trust_file /etc/ssl/certs/ca-certificates.crt logfile ~/.msmtp.log port 465 auth on from [le nom à afficher]@[domaine.perso.net] user [le nom d'utilisateur] password [clé API secrète] aliases /etc/aliases
Ensuite Scaleway a quelques exigences sur le formatage des mails. Pour tester :
From: [le nom à afficher]@[domaine.perso.net] To: [votre@mail] subject: Test encore Le corps du texte commence à cette ligne (laisser une ligne blanche)
Et enfin pour tester :
cat mail.txt | msmtp -a scaleway [votre@mail]
Permettre à php d'envoyer
Je ne comprends pas trop pourquoi “parfois ça va, parfois non”.
On commence par donner le droit à www-data de se servir de msmtp :
sudo chgrp www-data /etc/msmtprc
On vérifie aussi que dans php.ini, la ligne suivante existe. À refaire à chaque changement de version de php…
- /etc/php/X.Y/apache2/php.ini
[mail function] sendmail_path = "/usr/bin/msmtp -t"
Et on recharge apache/ce qui utilise php :
service apache2 restart
Problème de port ?
Vérifiez que les règles “output” sur le pare-feu permettent à msmtp d'envoyer un mail ! Les ports 465 et 587 sont concernés, uniquement en output.
Sources
Paramétrage des DNS
Pour améliorer la délivrabilité des mails, il faut configurer les DNS afin que tout soit propre. Au programme, SPF, DKIM, DMARC.
SPF
Sur OVH, par défaut :
"v=spf1 include:mx.ovh.com ~all"
Sur Gandi :
"v=spf1 include:_mailcust.gandi.net ?all"
Cela va autoriser tout ce qui passera par la gestion mail de ovh.
C'est suffisant pour tout les mails envoyé par le premier niveau (mondomain.com). Par contre il faut ajouter des options si on utilise un sous-domaine d'un serveur spécifique (moi.mondomain.com) ou des services tiers (autremail.com) :
"v=spf1 include:_mailcust.gandi.net a:moi.mondomain.com include:autremail.com ?all"
Si usage de https://sg-autorepondeur.com/ il faut probablement accepter leur domaine ? À vérifier…
Voir aussi Doc Google : Définir votre enregistrement SPF (configuration de base) qui détaille bien les options.
DKIM
Chez Gandi c'est tout automatique, suffit de cliquer sur le bon bouton : Protégez la réputation de votre nom de domaine avec DKIM.
Chez OVH, ils conseillent de génerer le DKIM via http://dkimcore.org/tools/keys.html et débrouille-toi ma poule. Demande de plus de détails sur https://community.ovh.com/t/parametrage-de-dkim-quels-options-renseigner/48740
DMARC
Attention ! DMARC doit être activé uniquement si DKIM et SPF sont fonctionnels, sinon ça ne marchera pas !
Gandi (modifier mail@mondomain.com) :
"v=DMARC1; p=reject; rua=mailto:mail@mondomain.com"
Sources
- Empêcher le blocage ou le placement dans le dossier "Spam" des messages envoyés aux utilisateurs Gmail : la doc de google est étonnamment bien.
- Google :
- https://toolbox.googleapps.com/apps/checkmx/ : test du nom de domaine par Google
- https://transparencyreport.google.com/safe-browsing/overview : État des soucis sur le nom de domaine répertorié par Google (la réputation de notre nom de domaine chez eux)
- https://www.mail-tester.com/ : envoyer un email à une adresse qui va vérifier sa conformité face à plein de paramètres
- https://mxtoolbox.com : divers outils de vérification de la qualité du mail
Spécificités GAFAM
Google utilise un outil (https://postmaster.google.com) qui va offrir des rapports sur la façon dont nos mails sont géré par eux. Au passage, les petits sagouins en profitent pour ajouter une validation, ils donnent un champ TXT à ajouter dans le DNS pour valider que le domaine est à nous.
Nul doute que ce genre de détail aide aussi à la délivrance des mails.