Sur les clients de messagerie modernes (Thunderbird, Evolution, Claws Mail), toute la configuration est centralisée dans un seul et même logiciel. Le fonctionnement primaire de la messagerie électronique est pourtant différent.
Nous verrons dans ce tutoriel comment revenir au mode traditionnel qui suit la philosophie d'Unix : « Un programme pour chaque tâche, et qui la fait bien. »
N'espérez pas apprendre à configurer un serveur de messagerie dans ce tutoriel (bien que certains éléments présentés ici puissent vous servir pour tester votre serveur sans sortir l'artillerie lourde). Vous verrez simplement comment gérer votre messagerie sur votre (vos) poste(s) de bureau, d'une manière plus efficace et plus pratique que celle que vous utilisez habituellement.
Comprenez tout d'abord qu'historiquement, chaque machine Unix servait à plusieurs utilisateurs. Ils s'y connectaient à l'aide de simples terminaux. Si l'on compare la messagerie électronique à la messagerie papier traditionnelle, il nous faut voir à une échelle différente : une machine correspond à un village avec son propre relais postal.
Le MTA (Mail Transfer Agent) : le bureau de poste
Le premier rôle du MTA est de transmettre les messages (les lettres) à une autre machine du réseau (un autre bureau de poste). Son second rôle est d'accepter les messages à destination de ses utilisateurs (les lettres à destination de son village ou arrondissement).
Sur une machine de bureau (un petit village), le MTA se limitera au premier rôle, et ne contactera que le MTA de son sous-réseau (le centre de tri dont il dépend) − typiquement, le serveur de mail du FAI − qui se chargera d'envoyer le courrier aux MTA des destinataires. Il ne s'occupera du second rôle que pour le courrier local, d'un utilisateur à un autre de la même machine (d'un habitant à un autre du même village). Le courrier de provenance extérieure sera, encore une fois, à la charge du serveur dont il dépend.
La plupart des distributions installent par défaut un MTA qui est configuré uniquement en local, et qui permet simplement d'envoyer des messages entre plusieurs utilisateurs. Il sert à recevoir les messages d'erreur système et de certaines applications (cron, par exemple).
Exemples de MTA : Sendmail, Postfix, Exim.
Le MDA (Mail Delivery Agent) : le facteur
Le MDA est chargé de placer les messages acceptés par le MTA dans les boîtes aux lettres des destinataires.
Là où l'analogie de la poste trouve ses limites, c'est que le MDA est capable de faire ce qu'aucun facteur ne fera jamais pour vous : trier votre courrier ! Théoriquement, le MTA est capable de placer lui-même le message dans la bonne boîte aux lettres, mais généralement, il fait appel à un MDA qui trie les messages avant de les poser dans la boîte aux lettres du destinataire. Le MDA peut trier les messages en fonction de règles prédéfinies selon plusieurs critères (provenance, destinataire, objet, pièce jointe) pour les placer dans des boîtes aux lettres différentes ou dans des fichiers spécifiques d'une même boîte aux lettres. Il peut aussi faire appel à des programmes extérieurs qui se chargeront d'une tâche plus spécifique de tri, comme un anti-spam ou un antivirus.
Exemples de MDA : Procmail, Cyrus, maildrop.
Le MRA (Mail Retrievial Agent)
Dans le cas d'une machine de bureau, votre boîte aux lettres est stockée sur le serveur qui en dépend. Pour que vous puissiez lire vos messages, il vous faut aller les chercher sur le serveur. C'est le rôle du MRA.
Le MRA peut soit copier la boîte aux lettres telle qu'elle est sur le serveur, soit faire appel à un MDA situé sur la machine de bureau qui fera du tri localement.
Exemples de MRA : fetchmail, fdm, getmail.
Le MUA (Mail User Agent) : bureau, papier, stylo
C'est le client de messagerie, le programme avec lequel vous lisez et écrivez vos messages. Il formate les messages en partance afin de les donner au MTA, et les messages de la boîte aux lettres afin de les afficher à l'écran.
Exemples de MUA : mutt, Pine, Gnus (Emacs).
Les MUA que vous connaissez (Thunderbird, Evolution, Claws Mail) intègrent tout dans un seul logiciel. Ici, nous chercherons à revenir aux sources :
Pour que tout ce petit monde puisse communiquer, il faut qu'il parle le même langage. On appelle ces langages « protocoles » : c'est une norme définie qui permet à deux serveurs ou à un serveur et un client de communiquer entre eux.
Les MTA communiquent avec le protocole SMTP (Simple Mail Transfer Protocol). Ce protocole permet d'envoyer un message d'un MTA à un autre. Dans le cas typique, le message sera envoyé de votre MTA local à celui de votre FAI, qui le transmettra à celui du FAI du destinataire, qui le déposera dans la boîte aux lettres.
Pour qu'un MRA puisse récupérer le message dans une boîte aux lettres distante, cette boîte doit être exposée. Il existe deux protocoles pour exposer et récupérer les messages : le protocole POP3 (Post Office Protocol version 3) ou l'IMAP (Instant Message Access Protocol). Le programme chargé d'exposer les boîtes aux lettres sera simplement appelé « serveur POP » ou « serveur IMAP ». Le protocole POP3 est le protocole historique. Il permet à un MRA de récupérer les messages sur le serveur, puis de les supprimer du serveur. L'IMAP est apparu par la suite, ajoutant de nouvelles fonctionnalités. Il permet notamment de créer des dossiers sur le serveur, d'y déplacer des messages, d'en ajouter ou d'en modifier directement sur le serveur. Ainsi, on peut se reconnecter avec un autre client et retrouver ses messages tels qu'on les avait laissés.
Nous reverrons un peu plus en détail le fonctionnement de ces protocoles dans le prochain chapitre.
Mbox / Maildir
Mbox est le format de boîte aux lettres Unix standard. Il stocke tous les messages d'une boîte aux lettres dans un seul fichier. Habituellement, la boîte de réception se trouve dans /var/mail/nom_de_l'utilisateur.
Maildir utilise un dossier pour stocker les messages d'une boîte aux lettres, habituellement dans ~/Maildir. Le dossier contient trois sous-dossiers : new, cur et tmp (les nouveaux messages arrivent dans /tmp avant d'être traités puis déplacés dans new ; une fois marqués comme lus, ils sont déplacés dans cur). Plusieurs clients peuvent écrire simultanément dans une boîte Maildir, alors que Mbox utilise un système de verrou. C'est pourquoi Maildir est préféré sur les serveurs IMAP.
Sur votre machine, si vous ne souhaitez pas exposer votre courrier via IMAP, vous pourrez choisir celui que vous voulez.
MSA : Mail Submission Agent
Le MSA est le programme interne du MTA qui fait le lien entre le MUA et le MTA lui-même. Il lit le mail sur l'entrée standard et l'envoie en local au MTA. Le MUA invoque donc le MSA en lui donnant simplement le message à transmettre.
Le MSA historique est le programme /usr/sbin/sendmail, fourni par le MTA Sendmail. Les autres MTA installent généralement leur programme Sendmail en lieu et place du précédent, qui prend en compte les mêmes paramètres. Les MUA classiques connaissent les paramètres à envoyer à Sendmail.
On peut aussi installer d'autres MSA qui sont capables de contacter un MTA extérieur, et permettent donc d'envoyer un message à l'extérieur en ligne de commande sans utiliser le MTA de sa machine. Exemples : sSMTP, msmtp.
Les alias
Le courrier d'un utilisateur peut être redirigé vers un autre utilisateur. Vous pouvez voir ces modifications dans le fichier /etc/aliases.
Généralement, par défaut, les utilisateurs système sont ainsi redirigés vers root, ce qui permet de retrouver les messages système dans la boîte aux lettres de root. Sur certaines distributions, root est redirigé vers le premier utilisateur créé.
Ceci peut être utile par exemple lorsque plusieurs personnes administrent la machine, chacun s'occupant d'une tâche spécifique. Vous pouvez ainsi rediriger vos messages comme bon vous semble (n'allez tout de même pas rediriger vers un utilisateur système au final). Pour prendre en compte les modifications, lancez :
# newaliases
Vous voyez maintenant comment ce système est agencé. La seule chose qui vous manque, c'est de voir comment tous ces élements communiquent.
Ici, nous allons voir comment les différentes transactions s'opèrent, et comment fonctionnent les différents protocoles dans les grandes lignes.
Nous utiliserons telnet, le terminal à tout faire, pour contacter les serveurs et ainsi voir les différentes commandes envoyées aux serveurs pour l'envoi et la réception des messages.
Les serveurs SMTP écoutent habituellement sur le port 25. Ceci peut changer en fonction des serveurs. Je prends ici comme exemple le serveur SMTP de Free, avec en rouge les commandes entrées par l'utilisateur.
Citation : telnet
$ telnet smtp.free.fr 25 Trying 212.27.48.4... Connected to smtp.free.fr. Escape character is '^]'. 220 smtp4-g21.free.fr ESMTP Postfix HELO client.local 250 smtp4-g21.free.fr MAIL FROM: expé[email protected] 250 2.1.0 Ok RCPT TO: [email protected] 250 2.1.5 Ok DATA 354 End data with <CR><LF>.<CR><LF> From: expé[email protected] To: [email protected] Subject: Test
Je peux envoyer un message avec telnet. . 250 2.0.0 Ok: queued as 2EBE14C81B8 QUIT 221 2.0.0 Bye Connection closed by foreign host.
Quelques explications : les serveurs sont polis et se présentent (« 220 smtp4-g21.free.fr ESMTP Postfix »). Ils attendent généralement qu'on leur rende la pareille (même si dans le cas de Free, j'aurais pu m'en passer). On emploie alors HELO suivi normalement du nom de domaine de la machine cliente. On peut théoriquement mettre ce que l'on veut à la place du nom de domaine, mais certains serveurs obligent à mettre un nom de domaine (du moins deux chaînes de caractères séparées par un point). Je donne l'adresse de l'expéditeur et celle du destinataire à l'aide des commandes MAIL FROM et RCPT TO, puis le corps du message avec DATA (avec un point seul à la fin pour signaler la fin du message). Je me déconnecte ensuite simplement avec QUIT.
À partir de là, le serveur de Free contactera celui du destinataire et aura le même dialogue avec lui pour lui retransmettre le message.
Et là, vous remarquerez deux choses : la première est que les champs indiquant l'expéditeur, le destinataire et le sujet, qui seront affichés dans des champs spécifiques par son MUA, font partie du corps du message. Je reviendrai sur ce point. La deuxième chose est que je n'ai pas eu à m'identifier sur le serveur. En effet, la configuration de base d'un serveur SMTP autorise toute machine de son réseau (ici le réseau Free) à envoyer un message dont la source est sur son domaine, et accepte tous les messages à destination de son domaine.
Ça fait tout de même pas mal de choses à réunir pour refuser un mail. Ce qu'il faut comprendre, c'est qu'historiquement le protocole SMTP n'a pas été pensé pour la sécurité, mais pour la fiabilité : le message doit arriver à destination, point.
On a tout de même ajouté par la suite des extensions à SMTP permettant d'affiner tout ceci. Ce qui est utile pour permettre les mails nomades, comme Gmail ou Yahoo!, où chacun peut utiliser son adresse de n'importe où (chez Free, il faut utiliser le webmail). On parle alors d'ESMTP (Extented SMTP).
ESMTP
EHLO, l'« Extented HELO »
Au lieu d'utiliser HELO, on va maintenant utiliser EHLO. Le serveur va alors renvoyer les extensions qu'il prend en charge. Exemple avec Free :
Nous sommes donc en ESMTP (aujourd'hui, tous les serveurs le sont) et nous pouvons utiliser les extensions indiquées.
Je ne citerai que deux extensions ici (qui ne sont pas prises en charge par Free, c'était seulement pour l'exemple), car ce sont celles qui nous sont généralement imposées quand elles se trouvent sur le serveur.
AUTH
Certains serveurs obligent leurs utilisateurs à s'authentifier. On peut trouver plusieurs types d'authentification, les plus connues sont LOGIN et PLAIN. Les deux sont codées en base64. On peut encoder en base64 avec OpenSSL (d'autres programmes permettent d'encoder en base64, par exemple Emacs avec la commande base64-encode-region).
Exemple d'un AUTH LOGIN avec le login « kna » et le password « Kn4 » :
Les serveurs utilisant AUTH imposent en général STARTTLS pour empêcher de transmettre les mots de passe en clair.
Citation : telnet
AUTH LOGIN 504 5.5.4 Encryption required for requested authentication mechanism STARTTLS 220 2.0.0 Ready to start TLS
À partir de là, la suite est chiffrée. Et comme vous n'avez pas choisi SSL en première langue au collège, vous ne pouvez pas aller plus loin avec telnet.
Les serveurs POP3 écoutent par défaut sur le port 110.
Citation : telnet
$ telnet pop.free.fr 110 Trying 212.27.48.3... Connected to pop.free.fr. Escape character is '^]'. +OK POP3 ready <1675082144.1240247083@pop6-g25> USER moncompte +OK PASS monpass +OK LIST +OK 1 816 . RETR 1 +OK 756 octets Return-Path: <expé[email protected]> Delivered-To: [email protected] Received: (qmail 19584 invoked from network); 20 Apr 2009 17:04:17 -0000 Received: from XXX.XXX.XXX.XXX (HELO machine.domaine.tld) (XXX.XXX.XXX.XXX) by mrelay2-g25.free.fr with SMTP; 20 Apr 2009 17:04:17 -0000 Received: from client.local (machine.domaine.tld [XXX.XXX.XXX.XXX]) by machine.domaine.tld (Postfix) with ESMTP id 68C8F2972 for <[email protected]>; Mon, 20 Apr 2009 19:02:41 +0200 (CEST) From: [email protected] To: [email protected] Subject: Un mail juste pour le tuto Message-Id: <[email protected]> Date: Mon, 20 Apr 2009 19:02:41 +0200 (CEST)
J'avais envoyé ce mail avant ! Forcément.
. DELE 1 +OK QUIT +OK Connection closed by foreign host.
Là encore, rien de bien compliqué : j'utilise donc USER et PASS pour m'authentifier, LIST pour afficher la liste des messages. Ici, j'ai un seul message. Je récupère chaque message avec RETR suivi du numéro du message. Une fois le message récupéré, je le supprime du serveur avec DELE, là encore suivi du numéro du message. Enfin, je clos la connexion avec QUIT.
J'aurais aussi pu utiliser TOP qui affiche seulement l'en-tête du message avec les premières lignes du corps du message (ici, vu la longueur du message, ça n'aurait pas changé grand-chose).
Certains serveurs supportent APOP, qui permet de chiffrer son mot de passe. On utilise alors APOP suivi du login et du digest, le digest étant la somme md5 du tag renvoyé par le serveur lors de la connexion et du mot de passe. Par exemple, toujours avec le login « kna » et le password « Kn4 ».
Citation : telnet
$ telnet localhost 110 Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK Dovecot ready. <2feb.2.49ecc456.HiJ1D7sFI46If8vArork8A==@debian> APOP kna 4aaf1b8e5b2e5cd68e73aaf339235a00 +OK Logged in.
Ici aussi, certains serveurs POP3 peuvent également utiliser STARTTLS pour chiffrer le dialogue. Et de même qu'avec SMTP, on peut aussi trouver des serveurs qui font le dialogue POP3 dans un flux SSL ; on parle alors de POP3S et on utilise par défaut le port 995.
IMAP
Je ne parlerai pas de l'IMAP avec telnet ici. Bien qu'on puisse « causer IMAP » avec un serveur, le protocole étant beaucoup plus complexe que POP3, il mériterait un chapitre entier. Or, le but est seulement de vous présenter le fonctionnement de la messagerie électronique, pas de vous apprendre à coder un MRA. Si vous souhaitez tout de même avoir un aperçu, vous pouvez jeter un œil à http://irp.nain-t.net/doku.php/190imap:030_commandes.
Retenez simplement qu'IMAP utilise par défaut le port 143, et encore une fois on peut chiffrer le dialogue IMAP soit avec STARTTLS, soit en IMAPS (port 993).
TLS (Transport Layer Security) est en fait le nouveau nom de SSL (Secure Socket Layer). SSL s'arrêtant à la version 3, la version 1 de TLS correspond à la version 3.1 de SSL. Par abus de langage, il est courant de parler de SSL pour désigner à la fois TLS et SSL. Pour que l'on se comprenne, j'emploierai toujours « TLS/SSL » pour parler du protocole sans distinction de version ou d'utilisation, « STARTTLS » pour désigner un dialogue chiffré en cours de connexion (STARTTLS), et « SSL » pour parler d'un dialogue en clair dans un flux chiffré (SMTPS, POP3S, IMAPS). Lorsque je voudrai préciser la version, je l'indiquerai tout simplement (« SSLv2 », « SSLv3 », « TLSv1 »).
Sachez tout de même que TLS/SSL n'est pas propre à la messagerie électronique. Certains serveurs FTP utilisent aussi STARTTLS, et on peut faire passer n'importe quel protocole dans un flux SSL, c'est utilisé couramment avec du HTTP pour le commerce en ligne par exemple.
Et si on reparlait SMTP ou POP3 ?
Comme je vous disais précédemment, on ne peut pas utiliser telnet avec un serveur qui utilise STARTTLS. Mais on peut tout de même dialoguer avec ces serveurs en utilisant OpenSSL :
Remplacez [protocole] par le protocole du serveur que vous contactez (smtp, pop3, ou imap) et [serveur:port] par le nom ou l'IP du serveur, suivi du numéro de port (séparés par « : »). L'option -crlf est seulement là par sécurité, elle convertit un saut de ligne en CRLF. Ceci est requis sur certains serveurs.
À partir de là, vous pouvez dialoguer avec le serveur comme si vous utilisiez telnet. Dans le cas d'un serveur SMTP, OpenSSL enverra EHLO avant de lancer STARTTLS. Vous pouvez cependant renvoyer vous-mêmes un autre EHLO pour voir les options disponibles sur le serveur.
Pour SSL, tout est encapsulé dans le flux, c'est donc plus simple (on peut aussi utiliser stunnel) :
$ openssl s_client -crlf -connect [serveur:port]
Certificats
Lors d'une négociation en « TLS/SSL », le serveur vous envoie un certificat qui vous permet de vous assurer de son authenticité (autrement dit, que vous ne vous adressiez pas à un serveur tiers qui se ferait passer pour celui auquel vous voulez accéder). Pour assurer la validité du certificat, il est signé par une autorité de certification (CA) qui se charge de valider et révoquer les différents certificats. Vous avez déjà les certificats de plusieurs CA sur votre système, installés par OpenSSL ou par votre navigateur. Typiquement, on les trouve dans /etc/ssl/certs, mais ceci peut varier en fonction des distributions (généralement, ils sont installés via le paquet ca-certificates). Ainsi, vos clients peuvent vérifier l'authenticité des serveurs signés par ces CA. De cette façon, lorsque vous vous connectez à des serveurs connus via TLS/SSL, votre client reconnaît et accepte le certificat (ceci est fait en général de façon transparente).
Cependant, il se peut que vous n'ayez pas le certificat de la CA, soit parce que votre distribution n'en installe pas, soit parce que le serveur n'est pas signé par une CA connue (serveur d'une université, d'une petite entreprise ou serveur personnel, ayant fait appel à une CA moins connue ou ayant créé leur petite CA personnelle réservée à leur serveur pour économiser les coûts et les démarches). Vous avez probablement dû être confrontés à cette situation avec votre navigateur. En général, le navigateur vous propose soit d'accepter le certificat temporairement, soit de l'accepter définitivement, soit de le refuser.
Comment je fais pour savoir quel certificat je dois utiliser ?
Eh bien... c'est la grande question. Car c'est un peu au cas par cas : certains serveurs ont un certificat signé par une autorité qui a elle-même un certificat signé par une autre autorité ! Je ne pourrai raisonnablement pas parler de tous les cas ici. Mais ne vous inquiétez pas, je ne vais pas vous laisser tomber comme ça non plus.
Si vous avez des certificats pré-installés
Les clients que nous verrons demanderont soit un dossier contenant les certificats, soit un fichier. Dans le cas du dossier, c'est simple, il suffit d'indiquer /etc/ssl/certs. Dans le cas d'un fichier, votre distribution a probablement rassemblé tous les certificats dans un seul fichier (typiquement, /etc/ssl/certs/ca-certificates.crt). Sinon, vous pouvez aisément le faire :
for i in /etc/ssl/certs/*.pem ; do cat $i >> /etc/ssl/certs/ca-certificates.crt ; done
c_rehash /etc/ssl/certs
Vous pouvez tout de même vous inspirer de la suite pour trouver le bon fichier.
Si vous n'avez pas de certificat, ou pas le bon
Dans l'utilisation de s_client (OpenSSL) ici, je prendrai toujours le cas de SSL. Pour adapter à STARTTLS, ajoutez simplement --starttls [protocole] devant --connect [serveur:port].
Lorsque vous vous connectez viaOpenSSL, le serveur affiche son certificat. Cependant, il a peut-être d'autres certificats à nous montrer ; pour nous en assurer, nous allons utiliser l'option -showcerts :
Ici, le serveur nous affiche un ou plusieurs certificats. La partie qui nous intéresse commence par « Certificate chain ». Prenons comme exemple le serveur IMAP de Gmail :
Nous voyons ici deux certificats, numérotés 0 et 1. Leurs en-têtes comprennent deux lignes. La première contient le numéro et commence par « s: » (subject) : elle donne des informations sur le propriétaire du certificat. La seconde ligne commence par « i: » (issuer) : elle donne des informations sur l'autorité qui signe le certificat. Nous voyons donc que le premier certificat est celui du serveur imap.gmail.com et qu'il est signé par Google Internet Authority. Le deuxième certificat est celui de Google Internet Authority (qui signe donc le premier) qui est signé par Equifax Secure Certificate Authority. Il nous faudra donc récupérer le certificat de Equifax Secure Certificate Authority.
Une petite recherche nous permet de trouver le certificat sur http://www.geotrust.com/resources/root-certificates/. Il suffit donc de télécharger le fichier au format base64 et de l'enregistrer au format .pem dans un dossier, par exemple /etc/ssl/certs/mycerts.
Parfois, vous pouvez trouver un lien de téléchargement du certificat de la CA dans le certificat du serveur. En copiant le certificat (de la ligne « -----BEGIN CERTIFICATE----- » à la ligne « -----END CERTIFICATE----- ») dans un fichier au format .pem, vous pouvez extraire des informations du certificat en utilisant :
$ openssl x509 -in [certificat] -noout -text
Vous trouverez alors peut-être un lien pour télécharger le certificat de la CA (généralement un fichier .crt ou .pem) !
Faites ainsi pour tous les serveurs que vous devez contacter. Une fois tous vos certificats récupérés, donnez-les à root et limitez les autres utilisateurs à la lecture uniquement. Pour les clients auxquels il faut indiquer le chemin du dossier, il vous faut faire des liens symboliques pointant vers le certificat et ayant comme nom son hash. Ceci est faisable avec la commande c_rehash [nom_du_dossier] :
Il y a certains cas plus exotiques que je n'évoquerai pas dans ce tutoriel (certificat auto-signé, serveur qui nécessite une authentification du client, certificat fourni au format .exe). N'hésitez pas à regarder les pages de manuel des différents programmes qui seront abordés dans ce tutoriel, ainsi que la documentation d'OpenSSL.
On est en sécurité, finalement ?
Eh bien non ! Bien que le protocole TLS/SSL puisse être considéré comme fiable, il y a quelques imperfections dans notre démarche.
Tout d'abord, la façon dont nous avons obtenu les certificats est loin d'être sûre. D'une part, nous nous somme basés sur le certificat du serveur pour déterminer quelle CA lui fait autorité sans vérification : nous aurions très bien pu tomber sur un faux serveur se faisant passer pour le nôtre (ici Gmail). D'autre part, nous avons téléchargé le certificat de la CA par le web, sans nous assurer de l'authenticité du site.
Ensuite, comme nous l'avons vu, lorsque vous envoyez un message, il passe par plusieurs serveurs. Le schéma montré dans le chapitre précédent est simplifié : il est courant qu'un message passe par plusieurs relais avant d'arriver à destination. Si nous pouvons garantir la sécurité de notre machine au serveur que l'on contacte, on ne peut pas garantir qu'elle ne soit pas rompue à un moment dans la chaîne. Les serveurs n'utilisent pas ou peu SSL entre eux, pour la simple et bonne raison que peu de serveurs le supportent. STARTTLS est plus répandu sur les serveurs SMTP, cependant rien ne garantit que le serveur auquel vous avez envoyé le message en utilisant STARTTLS l'utilisera à son tour pour le transmettre, tout simplement parce que le serveur suivant auquel il s'adresse ne supporte pas STARTTLS ou refuse son certificat.
De plus, nous avons vu tout à l'heure qu'il était très facile de changer l'adresse du destinataire dans le champ « From: », voire d'envoyer un message à partir d'une adresse qui n'est pas la nôtre.
Si vous voulez préserver la confidentialité de vos messages, il faudra chiffrer directement dans le corps du message. Pour cela, le meilleur moyen est d'utiliser GnuPG ou S/MIME, qui vous permettront d'assurer à la fois la confidentialité mais aussi l'authenticité de vos correspondances.
Vous voyez maintenant toutes les étapes entre l'envoi et la réception d'un message. Vous êtes à présent en mesure de mieux aborder la suite.
Vous comprenez maintenant mieux quels sont les différents éléments qui participent à la messagerie électronique, et comment ils communiquent entre eux. Nous pouvons donc passer à ce qui nous intéresse : la pratique !
Pour rapatrier nos messages, nous allons utiliser fetchmail. Pour l'installation, il suffit d'installer le paquet fetchmail.
Configuration de base
La configuration de fetchmail se trouve dans le fichier ~/.fetchmailrc. Il vous suffit de l'éditer de la sorte :
poll [adresse_du_serveur]
port [port]
protocol [protocole]
username [login]
password [password]
En remplaçant :
[adresse_du_serveur] par l'adresse de votre serveur (pop.domaine.tld) ;
[port] par le numéro du port (non nécessaire si c'est le port par défaut) ;
[protocole] par le protocole de votre serveur (POP3, APOP ou IMAP) ;
[login] et [password] par le nom et le mot de passe de votre compte.
TLS/SSL
Fetchmail se connectera en STARTTLS s'il le peut.
Si vous utilisez SSL, ajoutez :
ssl
Si la connexion ne se fait pas, rajoutez :
sslproto [version]
En remplaçant [version] par la version du protocole utilisée par votre serveur : SSL2, SSL3, SSL23 ou TLS1.
Par défaut, fetchmail vérifie l'authenticité du certificat avec les certificats du répertoire par défaut (/etc/ssl/certs). Mais si l'authenticité du certificat n'est pas vérifiée, il rapatriera tout de même les messages et affichera simplement un message d'erreur.
Si vous souhaitez qu'il ne rapatrie pas les messages en cas d'échec de la vérification, il faut rajouter :
sslcertck
Pour spécifier un autre dossier contenant les certificats des CA, rajoutez :
sslcertpath /chemin/vers/le/dossier
MDA
Si on ne précise pas de MDA, fetchmail enverra le message au MTA local en SMTP, qui placera tous les messages sans distinction dans la même boîte aux lettres (par défaut /var/mail/utilisateur au format mbox).
Si vous voulez faire un peu de tri, ou utiliser une autre boîte aux lettres, il vous faudra utiliser un MDA. Nous allons prendre ici procmail. Pour utiliser procmail comme MDA, installez le paquet procmail et ajoutez cette ligne au fichier de configuration évoqué dans le paragraphe précédent :
mda /usr/bin/procmail
Rajoutez ensuite tous vos comptes de la même façon. Limitez la lecture du fichier contenant des informations sensibles (mots de passe) au seul utilisateur. Assurez-vous aussi que votre éditeur de texte n'en a pas fait de sauvegarde (.fetchmailrc~), et supprimez-la le cas échéant.
$ chmod 400 ~/.fetchmailrc
$ rm ~/.fetchmailrc~
Nous allons maintenant voir comment configurer procmail pour trier nos messages.
Procmail est un MDA puissant qui vous permet de faire un tri efficace de votre courrier. Sa configuration se fait dans le fichier ~/.procmailrc. S'il n'est pas déjà installé, installez le paquet procmail.
Configuration
Avant de nous intéresser aux règles de tri, il nous faut définir quelques variables dans ~/.procmailrc.
En premier lieu, nous avons deux variables à définir comme telles :
# Mettez « yes » si vous voulez avoir plus d'infos.
VERBOSE=no
# Indiquez /bin/sh comme shell.
SHELL=/bin/sh
Ensuite, il nous faut indiquer le chemin de certains fichiers et dossiers.
MAILDIR indique le dossier où se trouveront les boîtes aux lettres. Par exemple :
MAILDIR=/home/moi/Mail
DEFAULT indique le chemin de la boîte aux lettres où un message sera placé si aucune règle de tri ne lui est appliquée. ORGMAIL indique la boîte aux lettres où seront placés les messages si procmail rencontre un problème pour les déposer. Vous pouvez indiquer un dossier en le précisant à l'aide d'un slash (/) à la fin du chemin. Dans ce cas, procmail utilisera le format Maildir. Dans le cas contraire, il utilisera le format mbox. Par exemple, au format mbox :
Il ne vous reste plus qu'à définir un fichier pour les logs. On utilise la variable LOGFILE :
LOGFILE=$MAILDIR/procmail.log
Les règles
Stucture
Les règles de procmail sont faites en trois parties : le drapeau (flag), la condition et l'action.
Le drapeau débute toujours par « :0 », après quoi on met des indications sur les motifs que l'on recherche :
H : pour rechercher dans l'en-tête du message (header) ;
B : pour rechercher dans le corps du message (body) ;
c : pour garder une copie du message (copy), qui sera soumise aux règles suivantes.
Si vous êtes en mbox, il faudra ajouter un « : » pour indiquer à procmail d'utiliser un fichier verrou. Ainsi, le fichier de votre boîte aux lettres ne sera pas corrompu à cause de deux écritures simultanées (vous pouvez, si vous le souhaitez, indiquer derrière le nom du fichier verrou).
La condition débute toujours par une étoile (*) et une espace. Elle doit être sous la forme d'une expression rationnelle qui montre le motif à rechercher.
L'action peut être :
le chemin d'une boîte aux lettres : le message sera déplacé dans cette boîte. Il faut indiquer le chemin relatif par rapport à $MAILDIR. Là encore, indiquez un fichier pour une boîte mbox, ou un dossier pour une boîte Maildir ;
un point d'exclamation (!) suivi d'une adresse : le message sera envoyé à l'adresse indiquée ;
/dev/null : pour supprimer le message. Néanmoins, vous préférerez sans doute utiliser une boîte aux lettres « corbeille » pour éviter d'avoir un message important supprimé automatiquement.
Exemples
Les exemples suivants sont au format mbox :
:0H:
* ^From: boss@domaine\.com
professionnel
Les messages de [email protected] seront déposés dans la boîte aux lettres « professionnel ».
Mais si le message est envoyé par Michel Dupont <[email protected]>, il ne sera pas traité ?
Bien vu, il aurait donc fallu mettre comme condition * ^From:.*boss@domaine\.com .
Dans ce cas, on peut simplement mettre comme drapeau :0: .
Les messages du boss contenant « urgent » dans le sujet seront envoyés automatiquement à [email protected] On en garde tout de même une copie (drapeau « c ») qui ira dans la boîte par défaut si aucune règle ne suit.
Ici, le message devait remplir les deux conditions pour être traité. Mais on peut imposer une seule condition avec un tube (|) :
Pour tous les courriers adressés à mon adresse professionnelle, une copie sera faite pour le boss avant de les envoyer dans la boîte aux lettres prévue.
Mais si le message m'est envoyé en copie conforme (Cc) ou en copie conforme invisible (Bcc) ?
Effectivement, trier en fonction du destinataire est plus compliqué. Pour cela, procmail nous offre deux raccourcis pour rechercher dans tous les champs de destination en même temps :
On peut aussi utiliser le drapeau « A », qui permet d'évaluer une règle uniquement si la règle précédente est vérifiée. On peut donc aussi écrire la règle précédente de cette façon :
Si vous utilisez Maildir pour vos boîtes aux lettres, vous n'avez pas besoin de verrou. Et ici encore, il suffit de mettre un slash pour dire à procmail que c'est un dossier. Si je reprends l'exemple avec les règles imbriquées, ça donnerait :
Il y a une action de procmail dont je ne vous ai pas parlé : on peut envoyer le message à un programme externe, qui lui appliquera un traitement avant de le redonner à procmail.
Pour cela, il faut définir un PATH dans .procmailrc :
PATH=/usr/local/bin:/usr/bin:/bin
À adapter : limitez-vous simplement aux chemins des programmes que vous utilisez.
On utilisera « f » (filter) et « w » (wait) pour le drapeau, et le tube (|) pour l'action :
:0fw
| programme
On peut aussi se passer de définir le PATH en précisant le chemin complet :
:0fw
| /chemin/vers/programme
C'est l'exemple que je prendrai ici (simplement par souci de concision).
Voyons quelques exemples.
SpamAssassin
Utilisation basique
SpamAssassin est un programme permettant de filtrer les spams. Il fait une série de tests sur le message, puis lui donne un score. Si le message obtient un mauvais score, il est considéré comme du spam. Il ajoute des en-têtes « X-Spam-Status » et « X-Spam-Level » aux messages qu'il considère comme du spam.
Installez SpamAssassin, puis éditez /etc/mail/spamassassin/local.cf :
# Définit le score au-dessus duquel un message est considéré comme du spam. Plus le score sera faible, plus SpamAssassin sera intraitable :
required_score 5.0
# Définit les langues dans lesquelles on reçoit des messages (les messages dans une autre langue auront un score plus élevé) :
ok_locales fr en
# Adresses à ne pas considérer comme du spam (whitelist) et adresses à considérer comme du spam :
whitelist_from [email protected] *@domaine2.tld
blacklist_from [email protected] *@domaine2.tld
Il vous reste à ajouter dans votre .procmailrc (avant les autres règles, pour traiter tous les messages) :
Vous n'avez probablement pas envie de vous taper une longue liste blacklist_from à la main. Pyzor est un programme qui compare les messages avec une base de données de spams. Pour l'utiliser avec SpamAssassin, rien de plus simple, il vous suffit d'installer le paquet pyzor, puis de lancer :
$ pyzor discover
Cette commande créera un fichier ~/.pyzor/servers indiquant le serveur contenant la base de données des spams. Et il n'y a rien à faire de plus : SpamAssassin détectera Pyzor et l'utilisera lorsqu'on lui donnera un message à vérifier !
Spamd
Vous pouvez économiser des ressources pour votre système en utilisant le daemon de SpamAssassin : spamd. Selon votre distribution, un service a peut-être déjà été créé à l'installation de SpamAssassin. C'est le cas sous Debian, où il vous suffit d'éditer /etc/default/spamassassin et de remplacer
ENABLED=0
par
ENABLED=1
puis de relancer le service :
/etc/init.d/spamassassin
Pour les autres distributions, si le service n'existe pas, il vous faudra créer un service qui lance le programme spamd.
Une fois spamd lancé, vous pouvez utiliser /usr/bin/spamc au lieu de /usr/bin/spamassassin.
Fin ?
Vous pouvez ajouter d'autres règles, utiliser d'autres bases de données de spam (DCC, Razor...), bref, vous construire une solution anti-spam aux petits oignons. Pour aller plus loin, consultez les nombreuses pages de manuel (man -k spamassassin) et le wiki SpamAssassin : (en) http://wiki.apache.org/spamassassin/FrontPage.
Petites modifications
Formail
Formail (fourni avec procmail) est capable d'extraire, supprimer ou modifier les en-têtes d'un message.
Dans certains cas, il vaut mieux préférer le bon vieux sed. L'exemple précédent peut être remplacé par :
:0
*^Content-type: (multipart/mixed)
{
:0 B
*^Content-Disposition: (attachment|inline)
*filename=".*\.(ocx|vbs|wsf|shs|exe|com|bat|chm|pif|vbe|hta|scr)"
{
:0fw
| sed 's/^Subject:\(.*\)/Subject: [DANGER]\1/'
}
}
Autres
On peut ainsi traiter ses messages avec d'autres programmes, par exemple un antivirus ou un programme de sauvegarde. Il faut simplement que le programme « sous-traitant » puisse lire le message sur l'entrée standard et réécrire le message, modifié ou non, sur la sortie standard, ou bien modifier le drapeau.
Une fois toute votre configuration terminée, il vous suffira de lancer fetchmail pour rapatrier vos messages et les trier. On peut le lancer en daemon :
fetchmail -d 900
Ainsi, fetchmail rapatriera les messages toutes les 15 minutes (900 secondes).
Si vous souhaitez pouvoir lire vos messages à partir de plusieurs machines, ou bien même à partir de plusieurs clients de la même machine, par exemple un client console et un client GUI (certains clients n'aiment pas partager leur dossier de messages, ou ne permettent tout simplement pas de lire des messages récupérés par un autre programme comme fetchmail), l'installation d'un petit serveur IMAP peut se révéler utile. Nous allons voir comment faire ici.
Pour l'installation, rien de plus simple : la plupart des distributions fournissent un paquet dovecot. Il vous suffit de l'installer.
Maildir++
Pour pouvoir utiliser un serveur IMAP, il vous faut changer quelques paramètres dans procmail. Dovecot utilise le format Maildir++, il ne gère le format Maildir qu'à partir de la version 1.1. Donc si vous avez une version inférieure, il faudra utiliser le format Maildir++. Pour cela, renommez les dossiers tels que :
~/Mail/dossier devient ~/Mail/.dossier ;
~/Mail/dossier/sous_dossier devient ~/Mail/.dossier.sous_dossier ;
la boîte de réception (INBOX) se trouvera à la racine (~/Mail).
Si vous avez une version de Dovecot 1.1 ou supérieure, vous pouvez utiliser le format Maildir classique.
Configuration de Dovecot
Base
La configuration de Dovecot se fait dans /etc/dovecot.conf.
Dovecot gère tous les protocoles de réception. Ici, nous allons utiliser l'IMAP dans un tunnel SSL (imaps). Pour cela, il faut indiquer :
procotols = imap imaps
Ensuite, vous devez indiquer l'interface où Dovecot écoutera. Par exemple, pour un réseau local (toute adresse du type 192.168.0.x) :
listen = 192.168.0.0/24
Pour écouter sur n'importe quelle interface, il faut mettre :
listen = *
SSL
Pour pouvoir communiquer en SSL, il vous faut un certificat. Sur certaines distributions (Debian, par exemple), il est automatiquement créé dans /etc/ssl/certs/dovecot.pem (la clé est intégrée dans le fichier) lors de l'installation de Dovecot. Dans ce cas, il n'y a rien à faire de plus, il sera automatiquement utilisé.
Si votre distribution ne crée pas de certificats, ou si votre certificat a expiré, il vous faudra le générer vous-mêmes. La commande suivante crée un certificat auto-signé, non chiffré, valable un an :
OpenSSL vous pose alors une série de questions pour renseigner l'identité du certificat :
Country Name : mettez « FR » ;
State or Province Name : mettez « France » ;
Locality Name : mettez le nom de votre ville ;
Organisation Name : mettez ce que vous voulez, par exemple « monserveur », ou quelque chose d'un meilleur goût ;
Organisation Unit Name : mettez ce que vous voulez, ou laissez vide ;
Common Name : c'est le plus important, il faut indiquer l'URL qui sera utilisée par les clients pour contacter le serveur (hostname ou nom de domaine) ;
Email Address : il y a besoin de vous faire un dessin ?
Deux fichiers seront alors générés : dovecot.pem (le certificat) et dovecot.key (la clé). Donnez-les à root, placez-les où vous voulez, puis indiquez leur chemin dans dovecot.conf :
Il nous faut aussi indiquer l'emplacement des boîtes aux lettres à exposer. maildir indique le dossier contenant les boîtes :
mail_location = maildir:~/Maildir
Si vous utilisez le format Maildir et non Maildir++ (version 1.1 et supérieure), il faut ajouter LAYOUT=fs pour l'indiquer, et rajouter INBOX pour désigner la boîte de réception :
SSL chiffrant toute la communication, on peut se contenter d'un mécanisme d'authentification en clair. Et ça tombe bien, car ça nous permet d'utiliser les noms et mots de passe des utilisateurs du système :
Si votre distibution utilise PAM, vous pouvez l'utiliser pour l'authentification en remplaçant shadow par pam.
Et voilà, Dovecot est prêt à être utilisé ! Pour le lancer, il vous suffit de relancer le service si votre distribution en a créé un (par exemple, sous Debian : /etc/init.d/dovecot restart). Sinon, il vous faudra le créer vous-mêmes, ou simplement lancer dovecot (en root). Il ne vous reste plus qu'à configurer vos clients pour utiliser votre serveur. Vous pouvez alors consulter vos mails indifféremment à partir de votre machine de bureau, de votre portable, ou même de votre smartphone.
S'il est très pratique de pouvoir centraliser vos messages sur un serveur pour les consulter de n'importe où, il y a un inconvénient à tout garder sur la même machine : si vous faites une mauvaise manipulation ou si le serveur tombe en panne, tous vos précieux messages seront perdus. Vous pouvez aussi simplement vouloir consulter vos messages lorsque vous n'êtes pas connecté.
Fetchmail vous permet de relever facilement vos messages tout en les laissant sur le serveur (option -k). Mais il ne récupérera que la boîte de réception et non les autres dossiers (autres boîtes aux lettres, brouillons, messages envoyés). La solution est donc d'utiliser un programme conçu spécialement pour ça. J'ai nommé : mbsync ! Commençons tout d'abord par l'installer. Sur la plupart des distributions, le paquet s'appelle isync. Installez-le...
Configuration et utilisation
La configuration se fait dans le fichier ~/.mbsyncrc. Il faut lui indiquer deux boîtes aux lettres à synchroniser. La première est simplement un dossier sur la machine locale, au format Maildir, qui sera notre dossier de sauvegarde. Ici, nous allons simplement l'appeler « local » et la placer dans ~/backup_mail :
MaildirStore local
Path ~/backup_mail/
La seconde est donc celle que nous voulons sauvegarder, sur le serveur IMAP. Nous allons l'appeler « serveur ».
IMAPStore serveur
Host [adresse_du_serveur]
User [nom_du_compte]
Pass [mot_de_passe]
En remplaçant [adresse_du_serveur], [nom_du_compte] et [mot_de_passe] par ce qui correspond chez vous.
mbsync tente automatiquement STARTTLS ; pour utiliser SSL, il vous faut ajouter :
UseIMAPS yes
Dans les deux cas, il faut lui indiquer quel certificat utiliser :
CertificateFile /chemin/vers/le/certificat
Si vous ne vous connectez pas à un port standard (143 ou 993), il faut l'indiquer :
Port [numéro_du_port]
Notre deuxième adresse étant configurée, il ne nous reste plus qu'à définir des chaînes (Channel) pour chaque boîte aux lettres à sauvegarder. Il faut définir pour chaque chaîne une boîte maître (Master) et une esclave (Slave). On définit alors le sens de synchronisation (Sync) : du maître vers l'esclave (Pull) ou de l'esclave vers le maître (Push). Concrètement, ça donne :
Ainsi, la chaîne « perso » sauvegardera la boîte aux lettre « personnel » du serveur dans ~/backup_mail/perso. Pour lancer la sauvegarde, il vous suffit de lancer :
mbsync -Cs perso
Vous pouvez procéder ainsi pour toutes vos boîtes. Si vous voulez sauvegarder plusieurs boîtes en même temps, vous pouvez créer un groupe :
Group all
Channel perso
Channel pro
Channel famille
Vous pourrez alors tout sauvegarder d'un coup en lançant :
mbsync -Cs all
Sauvegardes automatiques
Si vous souhaitez lancer automatiquement vos sauvegardes, vous ne pouvez pas vous contenter d'une simple commande mbsync lancée automatiquement. En effet, si vous supprimez des messages par mégarde et qu'une synchronisation a lieu juste après, vous perdrez alors tout le bénéfice de la sauvegarde... La solution est donc de faire un simple script qui archive chaque sauvegarde dans un fichier différent :
#!/bin/sh
# /usr/local/bin/mailbackup : sauvegarde et archive les messages
# Le script devant être lancé par cron, il est préférable d'indiquer le PATH
PATH=/usr/bin:/bin
# Sauvegarde des messages
mbsync all
# Archivage
tar -cf ~/mail_$(date +%Y-%m-%d).tar ~/backup_mail
Il ne reste plus qu'à définir une règle dans votre crontab :
* 17 * * * /usr/local/bin/mailbackup > /dev/null
Les messages seront sauvegardés tous les jours à 17h.
Vous avez maintenant un aperçu de ce que l'on peut faire avec IMAP.
Tous vos messages sont bien arrivés là où il faut. Il ne vous reste plus qu'à les lire confortablement et à y répondre. Je vous propose un bon MUA pour cela : mutt.
La configuration de mutt se fait dans le fichier ~/.muttrc (ah bon, vous vous en doutiez ?).
Éditeur de texte et visionneur
Pour définir l'éditeur de texte que l'on souhaite utiliser pour écrire les messages, il faut utiliser la variable editor. Par exemple :
set editor=/usr/bin/vim
Mutt lancera l'éditeur en question pour rédiger un message. Il suffit d'enregistrer en quittant l'éditeur pour retourner dans mutt et envoyer le message.
Si editor n'est pas renseigné dans .muttrc, vim utilisera la variable EDITOR du shell.
On définit de la même façon le visionneur pour lire les messages, avec pager :
set pager=/usr/bin/less
On peut également utiliser la variable PAGER du shell à la place.
Adresse d'envoi
Par défaut, mutt enverra un message avec « From: utilisateur@localhost ». Il vous faut donc définir votre adresse pour l'envoi. On utilisera use_envelope_from :
set use_envelope_from
Mutt indiquera alors l'adresse que vous mettrez dans le champ « From » (que vous pouvez éditer en utilisant les touches « Échap. » puis « f »). Si vous n'utilisez qu'une seule adresse pour l'envoi, vous pouvez directement l'indiquer dans votre .muttrc :
Mutt reconnaît automatiquement le format de la boîte aux lettres, on indiquera donc le chemin vers un fichier mbox ou vers un dossier Maildir de la même façon.
La boîte aux lettres à ouvrir au démarrage de mutt est définie par spoolfile. Par exemple (par défaut : /var/mail/utilisateur) :
set spoolfile=~/Mail/inbox
Pour les autres boîtes aux lettres, il faut renseigner leur dossier avec folder :
set folder=~/Mail
Vous pouvez changer de boîte dans mutt avec la touche « c », suivie de :
« ? » pour voir la liste des boîtes contenues dans folder ;
« = » puis le nom d'une boîte aux lettres pour y aller directement ;
« ! » pour revenir à la boîte aux lettres par défaut (spoolfile).
Vous pouvez définir certaines boîtes aux lettres avec mailboxes : seules ces boîtes seront affichées lorsque vous appuierez sur « Tab » à partir de la liste, ou au démarrage si vous lancez mutt avec l'option -y :
set mailboxes =personnel =professionnel =famille
Autres dossiers
Par défaut, les messages non envoyés (brouillons) sont stockés dans ~/postponed. Vous pouvez indiquer un autre chemin :
set postponed=~/Mail/brouillons
Par défaut, les messages envoyés sont stockés dans ~/sent. Vous pouvez indiquer un chemin pour les sauvegarder :
set record=~/Mail/envoyés
IMAP
Si vous préférez utiliser un serveur IMAP plutôt que d'utiliser fetchmail et procmail, mutt supporte l'IMAP. Il vous suffit d'indiquer l'adresse du dossier au lieu d'un chemin, en la faisant précéder par imap:// (ou imaps:// si vous utilisez SSL) :
# Boîte de réception (elle s'appelle généralement INBOX sur un serveur IMAP)
set spoolfile=imap://serveur:port/INBOX
# Dossier contenant les autres boîtes aux lettres
set folder=imap://serveur:port
# Messages non envoyés
set postponed=imap://serveur:port/Brouillons
# Messages envoyés
set record=imap://serveur:port/Messages Envoyés
Il vous faudra, en plus, indiquer votre compte et mot de passe sur le serveur :
# Type d'authentification
set imap_authentification="login"
# login et mot de passe
set imap_user="login"
set imap_pass="passwd"
On peut ajouter une foule d'éléments à .muttrc pour rendre mutt plus attractif. Je vais vous en présenter quelques-uns ici.
Les alias
Les alias sont simplement des raccourcis que vous pouvez indiquer dans les champs « d'adresses » (From, To, Cc...). Il vous suffit d'indiquer alias suivi de la commande, puis de l'adresse. Vous pouvez ainsi éviter de taper votre adresse complète dans le champ « From » :
Vous pouvez créer un fichier texte dont le contenu sera ajouté à la fin des messages que vous envoyez (défaut : ~/.signature) :
set signature=~/signature_mail
Les couleurs
Vous n'aimez pas les couleurs par défaut de mutt ? Il est possible de les changer. Les plus importantes sont :
normal : couleur des menus et des messages ;
indicator : couleur de la barre de sélection ;
status : couleur de la barre de statut ;
hdrdefault : couleur de l'en-tête des messages.
Il suffit d'indiquer « color » suivi de la couleur du texte et de la couleur du fond. Par exemple, pour avoir du noir sur fond blanc :
color normal black white
color indicator white black
color status white black
color hdrdefault black white
Les pièces jointes
Les programmes pour lire les pièces jointes sont définis dans /etc/mailcap. On peut en définir d'autres par utilisateur dans ~/.mailcap, qui sera prioritaire.
On définit une entrée pour chaque type MIME. Une entrée doit comporter au moins deux champs : le type MIME et la commande associée à exécuter. On utilise « %s » pour indiquer le nom du fichier dans la commande. Par exemple, pour les fichiers PDF :
application/x-pdf;xpdf %s
On peut aussi définir d'autres champs.
On peut renvoyer le résultat de la commande au visionneur par défaut en définissant un champ « copioustooutpout ». Il faut que la commande renvoie du texte. Il existe bon nombre d'applications pouvant extraire des données de formats différents au format texte (jetez un œil au script /usr/bin/lesspipe). Je reprends l'exemple du PDF :
application/x-pdf;pdftotext %s;copioustooutput
On peut aussi ajouter des tests :
en mettant « test= » suivi d'une commande, le test échouera si le résultat de la commande renvoie 0 ;
en mettant « needsterminal », le test échouera si vous utilisez un MUA graphique (donc pas avec mutt).
Vous pouvez ainsi définir deux entrées différentes pour un même type MIME. Si la première entrée comprend un test et qu'il n'est pas vérifié, la deuxième entrée sera utilisée :
Ici, si on se trouve dans une interface graphique, xpdf sera utilisé. Si on se trouve dans une console, le visionneur récupérera la sortie de pdftotext.
Ça y est, vous pouvez enfin lire vos messages avec mutt.
Eh si. Bien entendu, si vous voulez pouvoir rapatrier et lire vos messages, vous souhaitez aussi pouvoir en envoyer. Nous allons donc voir comment faire.
Méthode Debian : en deux minutes chrono avec debconf
Cette méthode a l'avantage d'être rapidement mise en place. Simplement, elle ne conviendra pas à tout le monde.
Cette méthode peut vous convenir uniquement si :
vous êtes sous Debian ou autre distribution utilisant APT (*ubuntu, knoppix, sidux...) ;
vous utilisez un seul serveur SMTP pour l'envoi ;
vous n'avez pas besoin d'utiliser SSL sur ce serveur.
Dans tous les autres cas, reportez-vous à la partie suivante.
Exim est le MTA par défaut sous Debian et consorts. À l'installation, il est configuré de base pour transmettre le courrier en local uniquement. Debconf nous permet de le transformer rapidement en relais. Nous allons donc simplement l'utiliser ici.
Il suffit de lancer debconf pour Exim (en root) :
# dpkg-reconfigure exim4-config
Le script lance une interface en ncurses nous posant quelques questions. Répondez-y ainsi :
Type de configuration : choisissez « Envoi via relais (« smarthost ») − réception SMTP ou fetchmail » ;
Nom de courriel du système : indiquez le domaine du courrier de votre adresse (à droite de « @ ») ;
Liste d'adresses IP où Exim sera en attente : laissez 127.0.0.1 ;
Autres destinations dont le courriel doit être accepté : laissez vide ;
Machines à relayer : laissez vide ;
Nom réseau ou adresse IP du système « smarthost » : indiquez l'adresse de votre serveur SMTP. Si le port est différent de 25, ajoutez « :: » suivi du numéro du port (smtp.domaine.tld::port) ;
Faut-il cacher le nom local de courriel dans les courriels sortants : répondez « Oui ». Les messages sembleront ainsi provenir de votre fournisseur ;
Nom de domaine visible pour les utilisateurs locaux : laissez le domaine de courrier ;
Faut-il minimiser les requêtes DNS (connexion à la demande) : répondez « Non », sauf si vous avez une connexion non permanente (par modem) ;
Méthode de distribution du courrier local : choisissez entre mbox et Maildir. Si vous changez d'avis, vous pourrez toujours relancer debconf ;
Faut-il séparer la configuration dans plusieurs fichiers : choisissez « Oui » si vous avez besoin de vous authentifier sur le serveur.
Si votre serveur ne demande pas d'authentification, il n'y a rien à ajouter. Exim utilisera STARTTLS si votre serveur le supporte. Si votre serveur demande une authentification, éditez /etc/exim4/passwd.client et ajoutez :
*:[login]:[password]
En remplaçant [login] par votre nom d'utilisateur et [password] par votre mot de passe. Ensuite, lancez :
# update-exim4.conf
# invoke-rc.d exim4 restart
Ça y est ! Votre machine est prête pour l'envoi. Vous pouvez aller directement à la conclusion.
Configurer un relais vers plusieurs serveurs SMTP peut s'avérer délicat avec les MTA classiques. En effet, il est rarement aisé de les configurer en utilisant plusieurs relais. Et vous n'avez pas forcément toutes les conditions nécessaires pour utiliser un MTA sans relais tout en s'assurant que tous vos messages arriveront à destination (IP blacklistée, serveur du destinataire vérifiant le champ MX et/ou le reverse-DNS, port 25 bloqué...).
Au lieu d'utiliser un MTA, nous allons utiliser un simple MSA : msmtp. Contrairement à un « vrai » MTA, msmtp ne peut pas relayer du courrier en provenance d'autres machines du réseau, et il ne peut pas non plus recevoir du courrier à destination de la machine. Il peut simplement envoyer le courrier à un relais ; et il se trouve que c'est juste ce dont on a besoin.
Configuration de msmtp
Cherchez le paquet msmtp pour votre distribution et installez-le. Pour le configurer, il vous faut éditer le fichier ~/.msmtprc. Ajoutez tout d'abord une ligne « account » avec un nom pour votre compte. Pour un compte classique (type FAI), vous devriez avoir une configuration de ce type :
account [nom]
host [adresse_du_serveur]
port [port]
auth off
from [adresse_email]
Où :
[nom] est le nom que vous donnez au compte (celui que vous voulez) ;
[adresse_du_serveur] est l'adresse de votre serveur SMTP (smtp.domaine.tld) ;
[port] est le port où vous contactez le serveur. Si vous utilisez le port par défaut (25 ou 465), vous n'avez pas besoin de le préciser ;
[adresse_email] est l'adresse que vous utilisez sur ce compte ([email protected]).
Si vous devez vous authentifier sur le serveur, remplacez « auth off » par :
auth [type]
user [login]
password [password]
Où :
[type] est le type d'authentification (login ou plain, généralement) ;
[login] et [password] sont respectivement le nom du compte et le mot de passe que vous utilisez pour vous authentifier.
Si vous utilisez TLS/SSL, ajoutez :
tls on
tls_starttls off # si vous utilisez SSL (chiffrer tout, port 465)
tls_trust_file [certificat_de_la_CA]
En remplaçant [certificat_de_la_CA] par le chemin du fichier contenant le certificat (/etc/ssl/certs/ca-file.pem). Si vous n'avez pas le certificat de la CA, vous pouvez ignorer la vérification du certificat en mettant :
tls_certcheck off
Faites ainsi successivement pour tous vos comptes. Vous pouvez définir un compte par défaut qui sera utilisé si vous n'utilisez pas une adresse indiquée avec « From » et que vous ne précisez pas le compte (option -a) :
account default : [nom]
Ici encore, il est préférable de limiter la lecture à l'utilisateur du fichier .msmtprc contenant des mots de passe :
chmod 400 ~/.msmtprc
Vérifiez aussi que votre éditeur de texte n'en a pas fait une sauvegarde (.msmtprc~). Supprimez-la si c'est le cas.
Utilisation avec mutt
Msmtp offre une interface compatible avec Sendmail (il prend les mêmes arguments). Il peut donc être utilisé avec mutt de façon transparente. Et c'est là que réside toute l'astuce : il suffit simplement d'indiquer à mutt d'utiliser /usr/bin/msmtp au lieu de /usr/sbin/sendmail, et c'est tout ! Pour cela, vous avez deux solutions :
soit ajouter dans votre ~/.muttrc :
set sendmail=/usr/bin/msmtp
Mutt et lui seul utilisera msmtp.
soit remplacer Sendmail par un lien symbolique :
# ln -s /usr/sbin/sendmail /usr/bin/msmtp
Tous vos MUA (mutt, mailx, git, votre page PHP, etc.) utiliseront alors msmtp, sans rien changer à leur configuration (à moins qu'ils soient configurés pour utiliser autre chose, bien entendu).
Ça y est, vous pouvez envoyer vos messages avec mutt !
Vous pouvez aussi envoyer un message en ligne de commande avec mailx :
mailx -s "sujet du message" [email protected]
Ceci est mon message. Je peux écrire ce que je veux.
Pour finir, je fais Ctrl+D.
En une ligne :
echo "Ceci est mon message" | mailx -s "sujet du message" [email protected]
Si vous utilisez msmtp, c'est le compte par défaut qui sera utilisé.
Voilà, votre mutt est enfin prêt à l'emploi !
Mutt est assez simple à prendre en main : les touches les plus utiles sont affichées en haut. La touche « ? » vous donne accès à la liste (vous pouvez utiliser « / » pour faire une recherche). Au bout de quelque temps, il s'avère plus efficace que n'importe quel MUA graphique.
Vous êtes (enfin) arrivés au bout de ce tutoriel !
Parmi tous les programmes présentés, je ne vous ai montré qu'une partie de leurs possibilités. N'hésitez pas à consulter leur documentation pour en tirer un meilleur parti.
Il existe aussi d'autres programmes qui peuvent réaliser les mêmes tâches, avec leurs avantages et leurs qualités. Vous pourriez préférer, par exemple :
Postfix au lieu d'Exim, ou sSMTP au lieu de msmtp ;
fdm au lieu du couple fetchmail/procmail ;
Pine ou Gnus au lieu de mutt ;
etc.
Vous pouvez aussi vous faire votre propre serveur SMTP, gérer vos comptes ou votre carnet d'adresses sur un serveur LDAP... Bref, il existe de nombreuses méthodes pour vous construire une solution de messagerie adaptée à vos besoins et à vos envies. N'hésitez donc pas à chercher plus loin que ce tutoriel !
