Authentification SMTP

Transcription

1 Alix Mascret SARL Keepin ( Éric De La Musse SARL Keepin ( Historique des versions Version janvier Présentation Nous allons décrire comment mettre en place un serveur SMTP authentifiant. La question qui vient tout de suite à l esprit est "Pourquoi mettre en place ce type de service?". Il peut y avoir plusieurs raisons. Dans notre cas, il fallait autoriser une application à recevoir et traiter des courriels, ces courriels déclanchant des opérations. Seul problème, elle ne doit pouvoir recevoir des courriels que de personnes identifiées. Comment faire? La solution retenue a été de rejeter tout courrier par défaut et de n autoriser que ceux ayant été identifiés. Nous allons donc voir comment mettre en place ce dispositif. Afin de rendre le processus d authentification plus sécurisé, la phase d authentification se fera dans une communication chiffrée via la couche de transport TLS. 2. Environnement Nous n allons pas avoir besoin de grand chose. Le scénario de configuration décrit ci-dessous s appuie sur Debian ( Postfix ( et l implémentation de SASL par la Carnegie Mellon University ( Nous considérons que le service SMTP est opérationnel et fonctionne. 1

2 Nous allons suivre le processus suivant 1. tout d abord créer et installer un certificat auto-signé pour la couche transport TLS ; 2. ensuite mettre en place l authentification SASL (Simple Authentification and Security Layer) pour Postfix ; 3. enfin utiliser l authentification SMTP avec un client de messagerie ; 3. Mise en place d un certificat auto-signé Au préalable indiquons qu il est inutile de s offrir les services d une autorité de certification reconnue (et payante!) dans la mesure où les certificats à signer ne seront utilisés que de manière privée (contrairement à une utilisation web où les certificats sont présentés au public) Le certificat racine C est celui de l autorité de certification. Il permet de signer d autres certificats. Nous allons utiliser openssl ( $ sudo aptitude install openssl $ openssl version OpenSSL 0.9.8g 19 Oct 2007 On va au préalable créer une arborescence pour y mettre tout ce dont on a besoin. cd && mkdir -p CA/newcerts CA/private && cd CA Le répertoire CA contiendra le certificat de l autorité de certification, la base de données des certificats signés, les clés... On va créer un certificat pour l autorité de certification. Ici nous sommes notre propre CA. Notez que vous allez avoir besoin de saisir une passphrase. Ne la perdez pas car c est elle qui vous servira à signer les certificats. Les options de la commande req d openssl : "-new -x509", créer un certificat auto-signé "-extensions v3_ca ", certificat pour une autorité de certification "-days 3650 ", durée de la validité du certificat, soit ici 10 ans 2

3 Création du certificat : ~/CA$ openssl req -new -x509 -extensions v3_ca \ -keyout private/cakey.pem -out cacert.pem -days 3650 Generating a 1024 bit RSA private key writing new private key to private/cakey.pem Enter PEM pass phrase: Verifying - Enter PEM pass phrase: Viennent ensuite les informations à renseigner Country Name (2 letter code) [AU]:FR State or Province Name (full name) [Some-State]:Limousin Locality Name (eg, city) []:Limoges Organization Name (eg, company) [Internet Widgits Pty Ltd]:keepin Organizational Unit Name (eg, section) []:staff Common Name (eg, YOUR name) []:keepin Address []:contact@keepin.eu La commande produit deux fichiers. La clé privée dans CA/private/cakey.pem et le certificat racine dans CA/cacert.pem. Vous pouvez consulter les informations du certificat : $ openssl x509 -in cacert.pem -noout - $ openssl x509 -in cacert.pem -noout -text $ openssl x509 -in cacert.pem -noout -dates $ openssl x509 -in cacert.pem -noout -purpose La commande : openssl x509 --help vous indiquera les requêtes possibles (ou man x509) Création d un CSR - Certificate Signing Request Nous avons le certificat racine (CA). La procédure va maintenant consister à créer les différents certificats signés par la CA pour nos applications. Il va falloir créer une clé privée et une CSR (Requête de demande de Certificat Signé) auprès de la CA, qui en retour nous produira un certificat signé par elle. Le CSR est une message chiffré qui va permettre la demande et la production du certificat signé. Vous pouvez créer un certificat pour tous vos services pops, impas, https... il faut juste savoir pour quel nom vous allez faire une demande de certificat. pop.foo.bar est différent de pop3.foo.bar, ou sinon il faut faire une demande avec un wilcard comme par exemple *.foo.bar. Pour ce qui nous concerne nous allons le créer pour smtp.keepin.eu. 3

4 ~/CA$ openssl req -new -nodes -out req.pem Generating a 1024 bit RSA private key writing new private key to privkey.pem Country Name (2 letter code) [AU]:FR State or Province Name (full name) [Some-State]:Limousin Locality Name (eg, city) []:Limoges Organization Name (eg, company) []:keepin Organizational Unit Name (eg, section) []:staff Common Name (eg, YOUR name) []:smtp.keepin.eu Address []:contact@keepin.eu A challenge password []: An optional company name []: Nous utilisons l option -nodes car elle nous permet de ne pas attacher de passphrase au certificat. En effet celui ci devra pouvoir être utilisé par Postfix sans intervention humaine (l entrée de la passphrase), notamment dans le cadre du lancement des services au démarrage de la machine. La commande produit 2 fichiers. privkey.pem la clé privée et req.pem le CSR. La clé privée va servir pour le chiffrement SSL. Le fichier req.pem pourra servir à de nouvelles requêtes lorsque votre certificat arrivera à échéance. Vous pouvez vérifier le contenu du CSR : $ openssl req -in req.pem -subject -noout $ req -in req.pem -text -verify -noout 3.3. Signature du CSR et création du certificat On va tout d abord créer une base de données pour les certificats que nous allons générer. ~/CA$ echo 01 > serial ~/CA$ touch index.txt Vérifier la variable dir dans le fichier de configuration par défaut de openssl afin qu elle pointe vers le répertoire courant (CA) : ~/CA$ grep dir /etc/ssl/openssl.cnf /etc/ssl/openssl.cnf:dir =. # par défaut c est : /etc/ssl/openssl.cnf~:dir =./democa 4

5 Modifier le fichier ou alors créez vous votre propre fichier de configuration dans ~/CA par exemple. Cette modification est nécessaire pour que openssl puisse mettre à jour le fichier de base de données index.txt. Signons le certificat : openssl ca -outdir. -out newcerts/cert.pem \ -cert cacert.pem -keyfile private/cakey.pem \ -days in req.pem Vous aurez besoin de saisir la passphrase du certificat racine. N hésitez pas à vous référer à la page du manuel man ca 1. Le nouveau certificat qui doit servir pour notre application et signé par la CA est dans newcerts/cert.pem, vous pouvez vérifier les informations. openssl x509 -noout -subject -in newcerts/cert.pem openssl x509 -noout -text -in newcerts/cert.pem 3.4. Installation du certificat pour Postfix On a tout, il suffit de copier ce dont on a besoin dans un répertoire où les certificats seront utilisables par l application. Pour nous il s agit de Postfix, vous pouvez les mettre dans /etc/postfix ~/CA$ sudo cp newcerts/cert.pem cacert.pem /etc/postfix ~/CA$ sudo mv privkey.pem /etc/postfix La clef privée est déplacée (et non copiée) car elle n a rien à faire dans le répertoire de l autorité de certification (dans un processus classique le certificat à signer provient d une tierce personne qui conserve bien entendu sa clef privée - surtout si elle est sans passphrase!). Notez que vous pouvez mettre ces fichiers (certificat signée, clef privée correspondante et certificat public de l autorité de certification) n importe où, il faudra juste adapter la suite en fonction de vos options Fin du travail sur les certificats Cette partie est terminée, il reste à configurer le service serveur qui utilisera le certificat, pour nous Postfix, chose que nous allons voir tout de suite. 5

6 Pensez juste à sauvegarder dans un endroit sûr tout ce que vous avez créé et pensez à nommer correctement les fichiers si vous souhaitez les conserver et les réutiliser. Par exemple, si on reste sur Keepin, cela pourrait donner : ~/CA$ mv newcerts/cert.pem newcerts/smtp.keepin.eu.cert.pem ~/CA$ mv req.pem smtp.keepin.eu.req.pem ~/CA$ mv privkey.pem smtp.keepin.eu.privkey.pem (...) 4. Configuration pour Postfix Nous allons voir ici comment activer la couche chiffrement et l authentification côté serveur, puis tester un peu cela avant un déploiement et une utilisation plus courante avec un client de messagerie Activation de la couche TLS dans Postfix Dans le main.cf de Postfix, vous rajoutez : # TLS parameters # Les certificats smtpd_tls_cert_file=/etc/postfix/cert.pem smtpd_tls_key_file=/etc/postfix/privkey.pem smtpd_tls_cafile = /etc/postfix/cacert.pem # supporte mais n impose pas le dialogue TLS smtpd_tls_security_level = may smtpd_tls_received_header = yes smtpd_tls_session_cache_database = btree:/etc/postfix/smtpd_tls_session_cache smtp_tls_session_cache_database = btree:/etc/postfix/smtp_scache tls_random_source = dev:/dev/urandom il faut relancer Postfix et vérifier surtout que le protocole est bien pris en charge. La configuration de Postfix peut être vérifiée :sudo postconf -d grep tls. Test du support TLS par Postfix. $ nc smtp.keepin.eu plibre.keepin.eu ESMTP Postfix (Debian/GNU) ehlo smtp.keepin.eu 250-plibre.keepin.eu 250-PIPELINING 250-SIZE VRFY 250-ETRN 6

7 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN quit Bye On peut quitter avant la fin de l échange car ce qui nous intéressait, c est la ligne 250-STARTTLS qui indique que Postfix propose bien maintenant une couche transport TLS Installation de SASL pour Postfix Nous allons mettre en place maintenant le protocole d identification SASL. Installation des librairies SASL : $ sudo apt-get install libsasl2 libsasl2-modules sasl2-bin Sans rentrer dans les détails du protocole SASL (cf RFC 4422 ( il existe plusieurs mécanismes d authentification (PLAIN, CRAM-MD5, CRAM-DIGEST, etc) et surtout, ce qui nous intéresse plus ici, plusieurs backend à partir desquels l authentification peut se faire : à partir de la base d utilisateurs du système (/etc/passwd ou /etc/shadow...) ou à partir d une source externe (base de données notamment). Dans un 1er temps nous allons mettre en place une identification à partir de la base des utilisateurs du système. Pour ce faire l implémentation SASL retenue utilise le programme serveur /usr/sbin/saslauthd). Commençons par modifier/etc/default/saslauthd START=yes et ajouter à la fin du fichier : OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" ceci pour tenir compte de l environnement chroot de Postfix sur Debian. Ajoutez également le compte Postfix au groupe sasl pour que Postfix puisse utiliser le service sasl : $ sudo adduser postfix sasl On va maintenant configurer SASL pour Postfix et l activer. 7

8 $ sudo mkdir -p /var/spool/postfix/var/run/saslauthd # ça c est pour Postfix $ sudo chmod a+x /var/spool/postfix/var/run/saslauthd/ $ sudo /etc/init.d/saslauthd start $ sudo ps -ef grep saslauthd $ sudo ls -al /var/spool/postfix/var/run/saslauthd/ La socket est créée dans /var/spool/postfix/var/run/saslauthd/mux. Passons à la déclaration de SASL pour Postfix. Il faut indiquer comment Postfix utilisera SASL. Ces paramètres seront mis dans /etc/postfix/sasl/smtpd.conf. La directive pwcheck_method nous permettra de préciser la méthode à utiliser (saslauthd ici). pwcheck crée une socket unix (nous avons vu cela plus haut). Postfix doit pouvoir lire dans ce répertoire. $ sudo mkdir /etc/postfix/sasl $ sudo touch /etc/postfix/sasl/smtpd.conf $ sudo vi /etc/postfix/sasl/smtpd.conf Ajouter : pwcheck_method: saslauthd Enregistrer. Modifier maintenant le main.cf tout en tenant compte de la configuration existante pour la directive smtpd_recipient_restrictions. smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous smtpd_sasl_local_domain = $myhostname smtpd_sasl_application_name = smtpd broken_sasl_auth_clients = yes smtpd_recipient_restrictions = permit_sasl_authenticated, (...) Relancer Postfix. Il nous reste à tester le support de l authentification par Postfix. Des lignes AUTH PLAIN... doivent apparaître. $ nc smtp.keepin.eu plibre.keepin.eu ESMTP Postfix (Debian/GNU) ehlo smtp.keepin.eu 250-plibre.keepin.eu 250-PIPELINING 250-SIZE VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN NTLM LOGIN DIGEST-MD5 CRAM-MD5 8

9 250-AUTH=PLAIN NTLM LOGIN DIGEST-MD5 CRAM-MD5 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN quit Bye Notez les lignes 250-AUTH PLAIN NTLM... Si tout va bien jusque là, nous allons pouvoir continuer. Si vous rencontrez des difficultés consulter le journal de Postfix qui, en général, donne de bonnes traces sur les erreurs. Il nous faut aller plus loin car nous n avons pas testé l authentification. Nous avons juste vérifié que cette authentification était bien prise en charge par Postfix. Pour ce faire nous allons tenter de nous authentifier en utilisant les identifiants d un compte système (rappelez vous que c est la méthode retenue ici - nous verrons plus loin une alternative). La chaîne passée pour l identification et l authentification doit être encodée. Voici comment procéder. On considère ici que le compte est user et le mot de passe est password. Pour encoder la chaîne, utilisez une des commandes suivantes : $ perl -MMIME::Base64 -e \ print encode_base64("user\0user\0password"); ou $ printf user\0user\0password openssl base64 Vous utilisez la chaîne produite qui représente l utilisateur et son mot de passe en base64. nc smtp.keepin.eu 25 Trying Connected to smtp.keepin.eu. Escape character is ^]. 220 plibre.keepin.eu ESMTP Postfix (Debian/GNU) ehlo smtp.keepin.eu 250-plibre.keepin.eu 250-PIPELINING 250-SIZE VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN NTLM LOGIN DIGEST-MD5 CRAM-MD5 250-AUTH=PLAIN NTLM LOGIN DIGEST-MD5 CRAM-MD5 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN AUTH PLAIN bwklp3fzy3jldabtyxnjcors5hrlc3q7cdfzcw== Authentication successful quit 9

10 Si vous obtenez une erreur comme : Error: authentication failed: authentication failure regardez dans le journal de Postfix. Cela peut provenir d un problème de configuration de Postfix, de SASL ou alors de la chaîne d authentification que vous passez en paramètre. Si vous avez une erreur comme : postfix/smtpd[2286]: warning: SASL authentication failure:\ cannot connect to saslauthd server: Permission denied vérifiez que Postfix peut accéder à /var/spool/postfix/var/run/saslauthd Parenthèse sur la sécurité Attention Pour l instant tout transite en clair (base64 n est qu un encodage et non pas un chiffrement) sur le réseau car le dialogue TLS n est initialisé que si le client le demande. N utilisez donc pas de vrais comptes/motdepasse pour vos tests! Une simple analyse de trame suffirait à récupérer l identification et le mot de passe de l utilisateur! Vous pouvez demander un échange chiffré manuellement avec la commande STARTTLS. (...) 250-8BITMIME 250 DSN starttls Ready to start TLS Le serveur répond bien qu il est prêt pour entamer un dialogue TLS. Le problème est que telnet ou nc ne savent pas faire cela. On va utiliser le client s_client de openssl. s_client permet d initialiser une session TLS avec un serveur qui supporte le protocole. Les options de s_client : -connect host:port # pas de commentaires -starttls proto # initialiser une session TLS # proto pouvant être smtp, pop3, imap, ftp Une fois le dialogue TLS établit par openssl, on peut reprendre un dialogue selon le protocole applicatif choisit. On y va : $ openssl s_client -connect keepin.eu:25 -starttls smtp (...) New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA 10

11 Server public key is 1024 bit (...) ehlo keepin.eu 250-plibre.keepin.eu 250-PIPELINING 250-SIZE VRFY 250-ETRN 250-AUTH PLAIN NTLM LOGIN DIGEST-MD5 CRAM-MD5 250-AUTH=PLAIN NTLM LOGIN DIGEST-MD5 CRAM-MD5 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN quit Un tunnel TLS est bien créé (là encore une analyse de trame vous le montrera), vous pouvez continuer le dialogue en utilisant les commandes SMTP. Tout devient maintenant chiffrable. On y voit plus clair! :-) Interdire l identification SASL si TLS n est pas utilisé : Pour éviter cet inconvénient majeur (passage en clair des identifiants et mots de passe) vous pouvez forcer Postfix à ne pas proposer l authentification non chiffrée si le dialogue n est pas en TLS. Pour ce faire dans /etc/postfix/main.cf remplacez la directive suivante : smtpd_sasl_security_options = noanonymous par les 2 directives suivantes : smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous qui dans un premier temps interdit l authentification non chiffrée noplaintext mais la rétablit si TLS est utilisé. si nous nous connectons sans TLS voyons ce qui se passe : $ nc keepin.eu plibre.keepin.eu ESMTP Postfix (Debian/GNU) EHLO plibre.keepin.eu 250-plibre.keepin.eu 250-PIPELINING 250-SIZE VRFY 250-ETRN 250-STARTTLS 250-AUTH DIGEST-MD5 CRAM-MD5 250-AUTH=DIGEST-MD5 CRAM-MD5 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN... Regardez les lignes 250-AUTH... : elles ne proposent plus PLAIN ou LOGIN. Refaites la même chose en utilisant openssl s_client : 11

12 $ openssl s_client -connect smtp.keepin.eu:25 -starttls smtp... New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit DSN EHLO plibre.keepin.eu 250-plibre.keepin.eu 250-PIPELINING 250-SIZE VRFY 250-ETRN 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN... où l on voit que PLAIN et LOGIN sont à nouveau proposés. PLAIN et LOGIN c est le mal! : Indiquons également que rien (sauf éventuellement les limitations du client utilisé) ne vous oblige à utiliser des mécanismes d identification qui font circuler les données en clair (PLAIN et LOGIN notamment). Dans la mesure où Postfix supporte des mécanismes chiffrés (CRAM-MD5 et CRAM-DIGEST notamment) utilisez les de préférence! Nous n avons utilisé ici le mécanisme PLAIN que pour des raisons pratiques facilitant l explication. Mais dans la vrai vie ne faites pas ça! ;-) 4.4. Fin sur la partie SASL Voilà, nous avons mis en place l authentification. Le seul point sur lequel nous reviendrons concerne les comptes. Nous verrons comment utiliser une authentification sans avoir besoin d utiliser les comptes systèmes, mais nous allons d abord tester l architecture avec un client de messagerie. 5. Configuration du client de messagerie Vous n aurez pas le détail pour chaque client. Il y en a trop, mais voici quelques pistes. Créez vous un autre compte SMTP. En général c est dans le menu configuration. Dans la configuration du serveur SMTP vous mettez le nom de votre serveur, par exemple dans le scénario développé ici ce serait smtp.keepin.eu et vous cochez (ou activez) l option qui doit être du style :Authentification SMTP. Et là vous renseignez le compte et éventuellement le mot de passe. 12

13 Dans les options de sécurité, activez le chiffrement TLS et la méthode d identification (PLAIN ici mais voir ci-dessus pour savoir pourquoi en fait il ne faut pas retenir PLAIN). Enregistrez. Il ne reste plus qu à tester. Envoyez vous un courriel en utilisant le service SMTP que vous venez de configurer. Il est possible qu entre temps, vous ayez eu des warnings ou avertissements concernant le certificat. C est normal car il est auto-signé, d où, les messages attirant votre attention sur la sécurité. Pour éviter cela il faut passer par une vraie CA. Allez, on fait un test. On poste et on collecte. Que nous indique l enveloppe du mail : Received: from...) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) by smtp.keepin.eu (Postfix) with ESMTP id 466CE82323 for <sctroumph@keepin.eu>; Sun, 11 Jan :34: (CET) et une petite analyse de trame montrera comment tout cela est chiffré. On a pas trop mal travaillé. 6. Utiliser une base de comptes indépendante Dans la procédure ci-dessus on utilisait les comptes systèmes comme backend. On peut souhaiter utiliser une base de comptes utilisateurs indépendante de celle du système (ce qui permet en cas de vol des identifiants smtp de ne pas faire "tomber" également les comptes utilisateurs). C est ce que nous allons développer. Il n y a pas grand chose à faire Modification pour Postfix Modifiez le fichier /etc/postfix/sasl/smtpd.conf afin d indiquer l utilisation d une base de données sasldb (on pourrait très bien envisager d utiliser ici une base SQL - ceci est laissé à titre d exercice au lecteur) : log_level: 3 pwcheck_method: auxprop mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 auxprop_plugin: sasldb Vous pouvez relancer Postfix. 13

14 6.2. Création de la base et ajout de comptes Il vous faut connaître le nom de votre machine SMTP. Ce que retourne la variable$myhostname de Postfix. echo postconf -h myhostname Admettons que la commande retourne la valeur smtp.keepin.eu. Ajoutons le compte foo : DB=/var/spool/postfix/etc/sasldb2 HOST= postconf -h myhostname sudo saslpasswd2 -c -u $HOST -f $DB foo -c sert à créer, -u concerne le domaine, -f la base. Si la base n existait pas elle sera créée. Si c est la première fois, vérifiez les droits : $ sudo chown root:postfix /var/spool/postfix/etc/sasldb2 $ sudo ln -s /var/spool/postfix/etc/sasldb2 /etc/sasldb2 La commande sasldblistusers2 permet d obtenir la liste des comptes utilisateurs. $ sudo sasldblistusers2 -f /var/spool/postfix/etc/sasldb2 C est à peu près terminé, il ne reste plus qu à tester la configuration Test de la configuration SASL Le principe est identique à celui utilisé avec les comptes système, mais là vous utiliserez les comptes créés avec la commande saslpasswd2. Si vous avez des erreurs dans le genre : Error: authentication failed: authentication failure consultez les journaux de Postfix. Vérifiez que : vous ne faites pas d erreur sur le codage du compte et du mot de passe en Base 64 14

15 la base est accessible (lisible) par Postfix (emplacement sur le disque et droits d accès ) le compte est bien créé Authentification SMTP Le meilleur des 2 mondes! : Notons également que rien ne vous empêche de disposer des 2 sources d authentification : la base de données des utilisateurs du système et la base de données externe. Pour ce faire adaptez le fichier /etc/postfix/sasl/smptd.conf de la façon suivante : pwcheck_method: saslauthd auxprop mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 auxprop_plugin: sasldb et le tour est joué C est terminé avec SASL et SMTP Si vous êtes arrivés ici, vous n avez plus qu à créer les comptes et documenter la procédure de configuration des clients de messagerie que vous utilisez. Votre serveur SMTP avec authentification vous est désormais accessible et ouvert (en théorie) de n importe où sur la planète. Je dis en théorie car de plus en plus de sites ferment l accès au port 25 extérieurs à leur domaine, ce qui peut poser problème si votre activité vous amène à vous déplacer souvent. Les seules solutions qui restent sont le webmail ou l utilisation du smtp du domaine dans lequel vous vous trouvez ce qui n est parfois pas simple. Mentionnons également le tunnel ssh ou un vpn sur ppp. La première option est la plus simple à réaliser : ssh -L 2525:localhost:25 VotreCompte@VotreServeurSSHetSMTP Là pour le coup vous serez plus libre. Le message sera vu comme un courrier parti de la machine locale (pas la vôtre, le serveur SMTP) : Received: from ip6-localhost (plibre [ ]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.keepin.eu (Postfix) with ESMTP id 4B3B Si en désespoir de cause vous n avez ni sortie SMTP, ni sortie SSH, il existe encore d autres options mais là on s écarte trop du sujet. 15

16 7. Références et liens Authentification SMTP Postfix ( Configuration TLS de Postfix ( Postfix et SASL ( Debian ( 16