Configurer l’authentification SMTP avec exim4

C’est bien beau d’avoir son serveur SMTP de base sur son système Linux, par exemple sur Debian, avec un minima de configuration il est possible d’envoyer des mails et d’en recevoir. Ceci étant, ce courrier sera distribué aux clients localement présents mais… ça s’arrête là. Il serra nécessaire d’avoir, au choix, le serveur mail directement sur votre pc de bureau OU ALORS d’être connecté en ssh sur votre serveur dédié et envoyer les mails depuis la machine distante. Par la commande mail, par mutt, peu importe. Bref, j’ai donné et ce n’est pas pratique. Surtout pour gérer plusieurs boites mail. Il existe la solution d’avoir un webmail bien évidemment, ce qui donnera certainement lieu à un article dédié.

La solution est simple, faire en sorte que les clients puissent s’authentifier sur votre serveur SMTP. Une fois authentifié, et seulement à partir de là, le serveur sera enclin à travailler pour le client et envoyer son courrier. J’aborderai dans cet article :

  • dans un premier temps quelques astuces / outils utiles,
  • la configuration à proprement parler pour l’authentification,
  • puis quelques tests pour vérifier la configuration de notre daemon smtp.

Je consacrerai un article sur la mise en place d’une connexion SMTP chiffrée avec exim4. De même pour avoir le daemon imap dovecot, et sa configuration pour une connexion chiffrée.

 

Quelques astuces concernant exim4

Je vais vous présenter quelques outils et quelques astuces pour faciliter la mise en place de notre authentification cliente.

Le port par défaut durant la configuration du serveur smtp

En effet, lors de la configuration d’un service peu de monde pense à changer le port d’écoute du service en question afin de se prémunir un maximum de potentielles attaques / visites de bots / hackers. Des milliers de robots et/ou de hackers s’amusent à tester des tas de serveurs en permanence afin de trouver leur victime (peu importe ce qu’ils veulent en faire). Et changer le port par défaut durant le temps de la configuration est déjà en soit une bonne protection. Pour exim4 ce changement est très simple, il suffit d’ajouter ou de modifier la directive suivante dans le fichier de configuration du deamon, à savoir /etc/exim4/exim4.conf.template ou exim4.conf :

daemon_smtp_ports = 15000

Ce qui demandera au daemon d’écouter sur le port 15000 à la place du port 25 par défaut. Il ne faudra pas l’oublier durant les tests !

Surveiller le fichier de log de exim4

Les fichiers de logs ne sont pas là que pour garder une trace de ceux qui viennent toquer aux ports de votre serveur. Ce sont également de puissants outils pour débug. Avec tail il sera très simple de surveiller tout ça :

tail -f /var/log/exim4/mainlog

tail -f va afficher le contenu du fichier en direct, au fur et à mesure qu’il va s’incrémenter. Le top à mon sens étant de coupler ça avec l’outil GNU Screen.

Purger la queue de mail de exim4

Alors que vos tests vont se multiplier, exim4 va garder les échecs d’envois en mémoire et retenter de temps à autre de renvoyer les mails non acheminés. L’outil eximqgrep va permettre de les annuler, avec xargs :

exiqgrep -i | xargs -n1 sudo exim -Mrm

Je ne précise jamais sudo, je pars du principe que tout le monde sait ajouter sudo en début de ligne si ça ne fonctionne pas. Ici étant donné que c’est en milieu de ligne, ça me semble moins évident. Bien, exiqgrep -i va permettre d’avoir une liste des mails, plus précisément leurs ids. Xargs -n1 va faire en sorte de découper la ligne précédente mot par mot et les passer à la commande suivante. Exim -Mrm va annuler chaque mail. Si des mails restent en queue, il suffira de restart exim4 et de relancer cette commande.

Installer swaks ou sasl2-bin afin de tester l’authentification du serveur smtp

Ou même les deux. Le paquet sasl2-bin permet d’avoir l’outil gen-auth, qui donne la possibilité de générer les hash de login / password selon les mécanismes d’authentification. L’outil swaks, développé par le même auteur, va quant à lui être spécialisé sur les tests de serveur smtp. Il gère l’authentification sécurisée avec TLS. Les deux outils sont en Perl.
Un exemple de commande avec swaks :

swaks -a -tls -s logd.fr -au $USER -ap

-a signifie que l’on veut s’authentifier, -tls indique que l’on va initier une connexion avec STARTTLS, -s est suivi du domaine que l’on veut tester, -au est suivi du nom de compte de l’utilisateur, -ap peut être suivi du mot de pass. Si on ne le précise pas, il sera demandé durant la connexion.

 

Mise en place de l’authentification smtp avec exim4

Selon la version de exim4 (selon votre version de Debian, sur Debian 7 exim4 version 4.80 sera disponible, alors que sur Debian 8 exim4 version 4.84 sera présent), quelques paramètres qui posaient problème sur Debian 7 ont été corrigés.

Je vais présenter la configuration pour exim4 version 4.84, et préciser comment faire pour l’ancienne version. Même si elle devrait tendre à disparaître vu que Debian wheezy ne sera plus maintenue.
Le fichier de configuration se trouve ici : /etc/exim4/exim4.conf.template

Nous allons donc commencer par changer le port d’écoute afin de configurer le daemon tranquillement. Mettons le port 15000 comme dit plus haut :
(A noter que l’on peut définir plusieurs ports via cette variable.)

daemon_smtp_ports = 15000

Ceci fait, il nous ajouter juste avant « domainlist local_domains = MAIN_LOCAL_DOMAINS » et initialiser la variable comme ceci :

MAIN_LOCAL_DOMAINS = logd.fr autre-domaine.ext autre-domaine.txt

Ceci indique à exim4 quels domaines sont locaux, et donc que le courrier doit atterrir sur le serveur que l’on configure.

Prochaine étape, déclarer le domaine qui va servir à compléter les adresses locales, comme par exemple root@localhost, feo@localhost… Sur exim4 version 4.80 il existait un petit bug, en effet une variable n’était pas prise en compte sur Debian : ETC_MAILNAME qui est censée retourner ce qui se trouve dans /etc/mailname (le domaine par défaut pour compléter les adresses locales, donc). Alors que sur exim4 version 4.84 le daemon prend bien en compte cette variable.

Voici ce que moi j’ai trouvé comme parade sur exim4 version 4.80, commenter tout ce bloque de conditions, et déclarer moi même la var qualify_domain :

### POUR EXIM4 VERSION 4.80 ###

qualify_domain = logd.fr
#.ifndef MAIN_PRIMARY_HOSTNAME_AS_QUALIFY_DOMAIN
#.ifndef MAIN_QUALIFY_DOMAIN
#qualify_domain = ETC_MAILNAME
#.else
#qualify_domain = MAIN_QUALIFY_DOMAIN
#.endif
#.endif

Ce qui devrait permettre d’avoir, pour cette version, de jolies adresses root@logd.fr

Bien, maintenant il nous faut faire un tour du côté de la façon dont sont délivré les mails : mail_spool ; maildir_home … La varaible LOCAL_DELIVERY va nous permettre de faire ce choix. Ceci étant, sur la version 4.80, dans mon cas il y avait encore un possible problème avec une condition qui n’était pas vérifiée, ou une variable mal déclarée. En effet il m’a fallu retirer la condition que voici :

.ifndef LOCAL_DELIVERY
LOCAL_DELIVERY=maildir_home
.endif

Ceci fait je n’avais plus que LOCAL_DELIVERY=maildir_home
Ce n’est pas grand chose en soi, la condition n’apporte qu’un choix par défaut. Bref pas bien importante. Normalement cela ne pose plus de souci avec la version 4.84. J’ai choisi le mode maildir_home car il est semble t-il plus simple par la suite pour les configurations en multiples virtuals domains avec Dovecot.

Vient ensuite le choix du mode de fonctionnement du premier router, qui va s’occuper de rediriger les mails non locaux. (donc ceux dont vous ne possédez pas le domaine).

DCconfig_internet = true

.ifdef DCconfig_internet
#configtype=internet
[...]

Ici j’ai donc initialisé la variable DCconfig_internet sur true, sans quoi le router n’était pas pris en compte ni sur la version 4.80, ni sur la 4.84. J’aurais pensé que de base ce serait configuré via l’utilitaire dpkg-reconfigure exim4-config, mais pas du tout.

Il ne reste plus qu’à choisir / configurer la méthode d’authentification, adaptée à vos besoins. A noter que je vais présenter ici la méthode cram_md5. L’intérêt de cette méthode est de ne pas laisser le mot de passe transiter en clair sur le réseau. Il faut donc trouver le bloque contenant « cram_md5 » :

cram_md5_server:
   driver = cram_md5
   public_name = CRAM-MD5
   server_secret = ${extract{2}{:}{${lookup{$auth1}lsearch{CONFDIR/passwd}{$value}fail}}}
   server_set_id = $auth1

On le dé-commente pour permettre la méthode. Il est possible de laisser plusieurs méthodes actives, mais à mon sens cela n’a aucun intérêt, mis à par pour faire des tests.

Dernière étape et ce n’est pas la moins importante, il faut générer le fichier de mot de passes. J’ai choisi, en toute logique, d’avoir des utilisateurs « semi-virtuels » : l’utilisateur existe sur le système mais a un mot de passe spécifique à exim4. Ainsi ce n’est pas le mot de passe du compte utilisateur sur le système qui est envoyé sur le réseau. Un coup d’oeil dans le manuel de exim4_passwd nous indique comment alimenter notre fichier de comptes. Voici comment comment générer un utilisateur :

The file should contain lines of the form

username:crypted-password:clear-password

crypted-password is the crypt(3)-created hash of your password. You can, for example, use the mkpasswd program from the whois package to
 create a crypted password. It is recommended to use md5 hashing, with mkpasswd -H md5.

clear-password is only necessary if you want to offer CRAM-MD5 authentication. If you don't plan on doing so, the third column can be
 omitted completely.

This file must be readable for the Debian-exim user and should not be readable for others. Recommended file mode is root:Debian-exim
 640.

Ce qui ne nous laisse, hélas, pas beaucoup de choix possibles quand il s’agit d’un fichier qui sert de database pour les comptes : soit nous avons les mots de passes qui circulent en clair sur le réseau et il sont en md5 dans le fichier, soit c’est hashé via cram-md5 donc plus discret sur le réseau mais le mot de passe doit être en clair dans le fichier cette fois.

Toujours est-il que voici deux commandes qui permettent de générer ces hash md5 qui seront utilisés quelque soit la méthode (si vous n’avez pas mkpasswd, installez le paquet « whois ») :

mkpasswd -m md5
openssl passwd -1

Ce qui nous permet d’avoir quelque chose comme :

feo@localhost:/etc/exim4$ mkpasswd -m md5
Mot de passe : 
$1$riT8HS3O$TTHC3K1PNm2XVHjQzuuw6.

Une fois mis en forme pour notre fichier de comptes / passwd, pour notre méthode d’authentification,  nous avons :

feo:$1$Vs/OfpC0$d1S4u5W2FtNJPilNgF0w01:tralalacoucou

Ne pas oublier de mettre les permissions de ce fichier ainsi : 640 avec root:Debian-exim

Il ne reste plus qu’a relancer le serveur afin de prendre tout ça en compte :

service exim4 restart
ou :
invoke-rc.d exim4 restart
ou :
/etc/init.d/exim4 restart

 

Test de connexion avec le compte fraîchement créé

Le plus simple étant de tester avec le logiciel swaks, cela nous donne :

feo@localhost:~$ swaks -a CRAM-MD5 -s logd.fr:15000 -au feo -ap
To: monAdressePerso@gmail.com
Password: $92COPlolfu
=== Trying logd.fr:15000...
=== Connected to logd.fr.
<- 220 {reverse_dns_serv_mail} ESMTP Exim 4.84_2 Fri, 23 Jun 2017 15:45:52 +0200
 -> EHLO ziggy.local
<- 250-{reverse_dns_serv_mail} Hello {reverse_ip_locale} [mon_ip_locale]
<- 250-SIZE 52428800
<- 250-8BITMIME
<- 250-PIPELINING
<- 250-AUTH CRAM-MD5
<- 250 HELP
 -> AUTH CRAM-MD5
<- 334 PDE0MzM2LjE0OTgyMjU1NTJAc2QtMTE2NjA5LmRlZGlib3guZnI+
 -> ZmVvIGVlMWU0YzU5YWU2MGZkNjA2YjhmMjY4ZmFjN2NlMDBi
<- 235 Authentication succeeded
 -> MAIL FROM:<feo@localhost.local>
<- 250 OK
 -> RCPT TO:<monAdressePerso@gmail.com>
<- 250 Accepted
 -> DATA
<- 354 Enter message, ending with "." on a line by itself
 -> Date: Fri, 23 Jun 2017 15:45:49 +0200
 -> To: monAdressePerso@gmail.com
 -> From: feo@localhost.local
 -> Subject: test Fri, 23 Jun 2017 15:45:49 +0200
 -> X-Mailer: swaks v20130209.0 jetmore.org/john/code/swaks/
 -> 
 -> This is a test mailing
 -> 
 -> .
<- 250 OK id=1dOOuG-0003jE-TN
 -> QUIT
<- 221 {reverse_dns_serv_mail} closing connection
=== Connection closed with remote host.

 

Et voilà ! C’est dans la poche ! Ne pas oublier de purger la queue de mails si jamais vous avez effectué d’avantage de tests en local sur le serveur par exemple. Dans le doute il suffit de lancer « exiqgrep -i » ou directement :

exiqgrep -i | xargs -n1 sudo exim -Mrm

@ Bientôt dans le futur !

 

Lu 376 fois

2 réflexions au sujet de « Configurer l’authentification SMTP avec exim4 »

    • Bonjour Nicolas.
      Pourquoi ne serait-il pas possible de restreindre l’accès au serveur? Est-ce que tu ne confondrais pas deux choses, à savoir l’authentification des clients (via un compte SMTP fonctionnant sur le principe de login / password) et le fait de relayer les mails venant de certains noms de domaines (permettant donc pour ces domaines de ne pas avoir à s’authentifier).
      Chose qu’il est possible de faire en filtrant sur le domaine, ou l’ip comme tu le fais. Pour ma part je ne relaie aucun domaine.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *