Wiki de sud-ouest2.org

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== ordi49.fr ======
Partage d'expérience sur la migration de l'hébergement des boîtes mail de mon domaine ordi49.fr.

La lecture de la présente page web suppose que vous avez pris connaissance et compris la page suivante du blog sud-ouest2.org :\\
[[https://sud-ouest2.org/configuration-de-votre-domaine-hebergement-dun-domaine-perso-sur-notre-infrastructure/|Configuration de votre domaine – hébergement d’un domaine perso sur notre infrastructure]]

 --- //Médéric 14/09/2017//


===== Présentation =====
Mes sites web sont hébergés chez [[https://www.inulogic.fr/|Inulogic]].\\
J'administre moi-même mon domaine ordi49.fr auprès du [[wpfr>Bureau d'enregistrement|registrar]] [[https://internetbs.net/fr/|Internet.bs]].

Inulogic est une petite société à bas coût, qui à l'instar de la société [[http://www.wdmedia-hebergement.fr/|WD-Media]], présente l'avantage d'avoir ses serveurs de stockage en France. Pour la gestion [[wpfr>Domain Name System|DNS]], Inulogic utilise le [[wpfr>Logiciel propriétaire|logiciel privateur]] [[wpfr>Plesk]]. Plesk est un panel web ou "[[wp>Web hosting control panel]]", c'est à dire une interface de gestion d'hébergement comme son grand concurrent logiciel privateur [[wpfr>cPanel]] et ses concurrents [[wpfr>Free/Libre Open Source Software|FLOSS]] comme [[wpfr>AlternC]], [[wpfr>GNUPanel]], [[wpfr>ISPConfig]], [[http://www.gplhost.com/software-dtc.html|DTC]], [[https://sourceforge.net/projects/openpanel/|OpenPanel]] et autres ([[wp>Comparison of web hosting control panels|liste comparative ici]]).

==== Contexte de migration chez Sud-Ouest.org ====
Après étude des différentes offres éthiques hébergées en France -- publiée sur ma page web [[https://wiki.ordi49.fr/doku.php/pratiquer:reprendre_le_controle_de_ses_emails|Reprendre le contrôle de ses emails]] --, j'ai décidé de migrer l'hébergement de mes boîtes mail chez sud-ouest2.org, à cause d'un blacklistage récurrent des plages IP de l'hébergement mutualisé Inulogic.

De mai à août 2017 ce problème avait pris tellement d'ampleur -- non réponse de mailer daemon ("mail dropping"), blacklistage des adresses IP mutualisées par [[wpfr>Malwarebytes Anti-Malware]]((forums.malwarebytes.com > [[https://forums.malwarebytes.com/topic/203469-false-positive-block-domain-for-ordi49fr-1858115653-1858115651-1858115654-1858115652/|False positive block domain for ordi49.fr, 185.81.156.53, 185.81.156.51, 185.81.156.54, 185.81.156.52]])) --, que j'avais perdu toute confiance dans le serveur SMTP mutualisé d'Inulogic. Très occupé par des tâches plus importantes, la petite équipe d'Inulogic m'a indiqué que je pouvais toujours migrer vers une offre [[wpfr>Serveur dédié virtuel|VPS]] à IP dédiée afin d'être épargné des inconvénients de la mutualisation. Mais cette possibilité n'était pas compatible avec mon budget.

===== Configuration DNS dans Plesk Onyx =====
**À savoir :**\\
La version [[wpfr>Plesk]] 12 tronque les champs très longs si bien qu'il est impossible de configurer correctement l'enregistrement ''dkim._domainkey'' tel qu'indiqué sur la page [[https://sud-ouest2.org/configuration-de-votre-domaine-hebergement-dun-domaine-perso-sur-notre-infrastructure/|Configuration de votre domaine – hébergement d’un domaine perso sur notre infrastructure]].

Si vous êtes clients chez Inulogic sous Plesk 12 (la version s'affiche lorsqu'on clique sur le bouton aide de Plesk), vous pouvez ouvrir un ticket auprès du [[https://www.inulogic.fr/support|support]] pour demander la migration sous Plesk Onyx en raison de cet enregistrement DNS ''dkim._domainkey''. Après migration sur le serveur pf4 d'Inulogic vous bénéficierez en outre du support [[wpfr>Let's Encrypt]].\\
Je ne sais pas si ce problème concerne également la version Plesk 12.5 qui est immédiatement antérieure à Plesk Onyx.

Chez Inulogic, les modification DNS sont très rapidement prises en compte (<30 minutes).

Voici une copie d'écran des paramètres DNS pour mon domaine ordi49.fr dans la dernière version du logiciel privateur [[wpfr>Plesk]] : Plesk Onyx.\\
J'ai supprimé dans l'image les informations DNS qui ne concernent pas le document de référence [[https://sud-ouest2.org/configuration-de-votre-domaine-hebergement-dun-domaine-perso-sur-notre-infrastructure/|Configuration de votre domaine – hébergement d’un domaine perso sur notre infrastructure]].

**Exemple de configuration DNS pour prise en charge boîte mail par sud-ouest2.org dans Plesk Onyx :**
{{ :domaine:ordi49.fr_-_plesk-onyx-dns-configuration.png?direct |Exemple de configuration DNS pour prise en charge boîte mail par sud-ouest2.org dans Plesk Onyx (Attention ! Certaines valeurs présentées dans cette image sont invalides ou obsolètes)}}

Attention : dans la copie d'écran ci-dessus, il manque un deuxième enregistrement MX pour le serveur de secours mx-backup.sud-ouest2.org. À cet égard, voir ce sous-chapitre plus bas dans la page :\\
Supervision et diagnostic > Outils en ligne > Utilisation de mxtoolbox.com > [[#Interpréter le dysfonctionnement diagnostiqué sur mx-backup.sud-ouest2.org]]

**Note importante concernant DMARC et DKIM :**\\
La valeur [[wpfr>DMARC]] a changé depuis la copie d'écran ci-dessus. D'après la [[https://sud-ouest2.org/configuration-de-votre-domaine-hebergement-dun-domaine-perso-sur-notre-infrastructure/|page du blog]] sud-ouest2.org, au 01/10/2017, elle doit être la suivante :
<code>
v=DMARC1;p=quarantine;sp=quarantine;pct=100;adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:postmaster@sud-ouest2.org;ruf=mailto:postmaster@sud-ouest2.org;rf=afrf
</code>

De même, sur la copie d'écran ci-dessus, la valeur de l'enregistrement [[wpfr>DomainKeys Identified Mail|DKIM]] est erronée et invalide.\\
Pour configurer DKIM dans Plesk, reportez-vous au paragraphe ci-dessous intitulé : [[#Problème de configuration DKIM dans Plesk]].

**Configurer DKIM dans Plesk :**
{{ :domaine:ordi49.fr_plesk_dns_dkim.png?nolink |Configurer DKIM dans Plesk : Pas de guillemet et clé publique p sans espace ! (voir ci-dessous au paragraphe "Problème de configuration DKIM dans Plesk")}}

Plus d'information sur DKIM au paragraphe [[#DNS > DKIM]].

===== Configuration DNS chez Internet.bs =====
[[https://internetbs.net/fr/|Internet.bs]] est un [[wpfr>Bureau d'enregistrement|registrar]] situé à [[wpfr>Nassau (Bahamas)|Nassau]], capitale des [[wpfr>Bahamas]]. Le support Internet.bs est en anglais bien qu'une adresse email française soit précisée sur la [[https://internetbs.net/fr/contact.html|page contact]].

==== Accéder directement à ses paramètres Internet.bs ====
**À savoir :**\\
On peut devenir un client direct de Internet.bs sans passer par un prestataire intermédiaire, comme j'ai dû le faire après la faillite d'Agsahosting en 2012. Pour cela, le support internet.bs vous demande la copie numérisée de votre carte d'identité et d'une facture récente justifiant votre domiciliation. Ce genre de documents officiels **ne doit jamais transiter par email sans être chiffré**. Le support d'Internet.bs est suffisamment qualifié pour déchiffrer une pièce jointe chiffrée à l'aide de la clé [[wpfr>GNU Privacy Guard|GPG]] publique Internet.bs. Celle-ci est disponible à l'URL suivante :\\
[[http://pgp.mit.edu/pks/lookup?search=internet.bs]]

==== Cas où hébergeur = serveur de noms primaire ====
Les clients Inulogic n'ont pas besoin de modifier les enregistrements DNS de leurs registrars puisque c'est le serveur DNS d'Inulogic qui est prioritaire((Je présume à cause du fait que le serveur DNS d'Inulogic soit par défaut un serveur de noms primaire pour la zone. Attention : Ne pas déclasser le serveur DNS Inulogic en serveur de nom secondaire sous peine de perdre l'accès aux sous-domaines.)). En d'autres termes, cela signifie qu'ils peuvent ajouter à la configuration de leur registrar les enregistrements DNS qui sont précisés sur la page [[https://sud-ouest2.org/configuration-de-votre-domaine-hebergement-dun-domaine-perso-sur-notre-infrastructure/|Configuration de votre domaine – hébergement d’un domaine perso sur notre infrastructure]], mais que ces enregistrements ne seront pas pris en compte quels que soient les réglages de priorités MX parce que c'est le serveur de noms primaire Inulogic qui fait autorité.
==== Priorité des enregistrement MX ====
Plus la valeur du champ priorité est basse, plus le serveur est prioritaire.

Exemple avant que je ne supprime définitivement l'ancienne référence MX à Inulogic :\\
mx-sud-ouest2.org (10) était prioritaire par rapport à pf4.inulogic.fr (20) :
<code>
mederic@devuan:~$ dig +nostat +nocomment ordi49.fr mx | grep MX
;ordi49.fr.                     IN      MX
ordi49.fr.              541     IN      MX      10 mx.sud-ouest2.org.
ordi49.fr.              541     IN      MX      20 pf4.inulogic.fr.
</code>

==== Gérer les enregistrements chez Internet.bs ====
Pour ajouter/supprimer/modifier des enregistrements DNS chez Internet.bs, une fois votre domaine sélectionné, il faut cliquer sur le bouton "Management de DNS" :
{{ :domaine:ordi49.fr_-_internetbs.net_-_administration_du_domaine_selectionne.png?direct |Une fois votre domaine sélectionné, il faut cliquer sur le bouton "Management de DNS"}}


===== Supervision et diagnostic =====
Les commandes ci-dessous concernent la famille de systèmes d'exploitation de type [[wpfr>Unix|UNIX]] comme les [[wpfr>Distribution GNU/Linux|distributions]] [[wpfr>GNU/Linux]].

D'autre part, je fais souvent référence aux sites web listés au paragraphe [[#Outils en ligne]] ci-dessous :

==== Outils en ligne ====
On trouve sur le web certains services très spécialisés qui rendent de grands services :
  * [[https://mxtoolbox.com/|mxtoolbox.com]] : propose un diagnostic et une supervision de n'importe quel site web avec des rapports détaillés relatifs aux services emails en rapport avec les enregistrements DNS, et aux listes noires éventuelles
  * [[http://dkimcore.org/c/keycheck]] : Vérifie la conformité [[https://www.ietf.org/rfc/rfc6376.txt|RFC 6376]] des informations DNS [[wpfr>DomainKeys Identified Mail|DKIM]] renvoyées pour un domaine
  * [[https://9vx.org/~dho/dkim_validate.php]] : "Online DKIM Verifier / DKIM Validation Tool" par Devon H. O'Dell\\ Sert -- grâce à la signature [[wpfr>DomainKeys Identified Mail|DKIM]] -- à valider l'authenticité du domaine de l'émetteur d'un message email.\\ Méthode : copié-collé du corps du message email dans le formulaire ou upload du fichier .eml\\ Attention ! Copier-coller le contenu d'un email comportant des caractères accentués provoque une rupture d'intégrité du message. La méthode par upload du fichier .eml ne pose pas ce problème

**Vérification de la conformité RFC 6376 du domaine ordi49.fr par dkimcore.org :**\\
{{ :domaine:ordi49.fr_-_dkimcore.org_tools_keycheck.html.png?nolink |Vérification de la conformité RFC 6376 du domaine ordi49.fr par dkimcore.org}}

=== Utilisation de mxtoolbox.com ===
Le formulaire de requête du site web [[https://mxtoolbox.com/|mxtoolbox.com]] est un peu singulier. On peut saisir une des commandes listées ci-dessous suivie de deux points verticaux ':' pour qualifier la requête. Lorsqu'on tape ':', le champ se vide pour laisser place à la saisie du nom de domaine et le bouton prends le nom de la requête. Voici la liste des commandes de requêtes disponibles :
  * blacklist: Check IP or host for reputation
  * smtp: Test mail server SMTP (port 25)
  * mx: DNS MX records for domain
  * a: DNS A record IP address for host name
  * spf: Check SPF records on a domain
  * txt: Check TXT records on a domain
  * ptr: DNS PTR record for host name
  * cname: DNS canonical host name to IP address
  * scan: Perform a port scan on the host
  * whois: Get domain registration information
  * arin: Get IP address block information
  * soa: Get Start of Authority record for a domain
  * tcp: Verify an IP Address allows tcp connections
  * http: Verify a URL allows http connections  
  * https: Verify a URL allows secure http connections  
  * ping: Perform a standard ICMP ping
  * trace: Perform a standard ICMP trace route
  * dns: Check your DNS Servers for possible problems

== Interpréter le dysfonctionnement diagnostiqué sur mx-backup.sud-ouest2.org ==
Le bouton "Find problems" du site [[https://mxtoolbox.com/|mxtoolbox.com]] signale en principe au-moins une erreur d'accès à mx-backup.sud-ouest2.org.\\
Par exemple "smtp    mx-backup.sud-ouest2.org    Failed To Connect" :
{{ :domaine:ordi49.fr_-_mxtoolbox.com_-_failed_to_connect_to_mx-backup.sud-ouest2.org.png?nolink |Résultat du test mxtoolbox "Find problems"}}

Ceci est normal parce que le service mail du serveur de secours ''mx-backup.sud-ouest2.org'' n'est activé qu'en cas de problème persistant sur le serveur principal ''mx.sud-ouest2.org''.

Si aucune alerte ne s'affiche concernant le serveur de secours, cela signifie :
  * soit qu'un problème persistant est actuellement en cours de résolution sur le serveur principal par les administrateurs de Sud-Ouest.org,
  * soit qu'il manque, dans la configuration DNS de votre domaine, une entrée MX vers le serveur de secours ''mx-backup.sud-ouest2.org'' qui est hébergé chez [[wpfr>Gandi (entreprise)|Gandi]] avec un rang supérieur à celui du premier serveur MX principal ''mx.sud-ouest2.org'' qui est hébergé chez [[wpfr>OVH]],
  * ou encore les deux points précédents à la fois.

Le but de cette entrée DNS avec un rang supérieur à l'enregistrement MX principal est l'acheminement automatique du courrier qui vous est destiné en cas d'indisponibilité du premier serveur. La page "[[https://sud-ouest2.org/configuration-de-votre-domaine-hebergement-dun-domaine-perso-sur-notre-infrastructure/|Configuration de votre domaine – hébergement d’un domaine perso sur notre infrastructure]]" préconise par exemple les valeurs suivantes :

> IN MX 10 mx.sud-ouest2.org.
> IN MX 100 mx-backup.sud-ouest2.org.

Une autre valeur que 100 pour ''mx-backup.sud-ouest2.org'' est possible, pourvu que celle-ci soit à la fois :
  * supérieure à la valeur assignée à ''mx.sud-ouest2.org''
  * inférieure aux autres valeurs d'enregistrement MX correspondant éventuellement au service email de votre hébergeur

== Bug de l'interface web mxtoolbox.com ==
La commande ''dkim:mon-domaine.tld'' ne fonctionne pas. Voici comment effectuer un test de l'enregistrement dkim.domainkey sur le site [[https://mxtoolbox.com/|mxtoolbox.com]] : 
  - Cliquer sur la flèche située à droite du bouton "MX Lookup" puis sélectionner "Dkim Lookup"\\ (Si cette flèche n'est pas affichée, effectuer une première requête afin qu'elle s'affiche)
  - Entrer ''mon-domaine.tld:dkim'' dans le champ de recherche puis cliquer sur le bouton "Dkim Lookup"

Exemple de requête mxtoolbox.com sur l'enregistrement DNS DKIM du domaine ordi49.fr :
{{ :domaine:ordi49.fr_-_mxtoolbox.com_-_dkim_lookup.png?nolink |Exemple de requête mxtoolbox.com sur l'enregistrement DNS DKIM du domaine ordi49.fr}}


==== DNS > Généralités ====
Interroger votre serveur de noms par défaut à propos de votre domaine :\\
''dig mon-domaine.tld any''

Interroger un serveur de noms particulier à propos de mon-domaine.tld pour surveiller la propagation des changements DNS :\\
''dig @serveurdns.tld mon-domaine.tld any''

Exemples :
  * Serveur DNS [[wpfr>French Data Network|FDN]] : ''dig @ns0.fdn.fr mon-domaine.tld any''
  * Serveur DNS Google : ''dig @google-public-dns-a.google.com ordi49.fr any''


==== DNS > DKIM ====
Les informations relatives à DKIM ci-dessous sont le fruit de plusieurs heures d'investigation sous forme de tests, diagnostics et recherches documentaires.

=== L'essentiel sur DKIM ===
L'enregistrement DNS DKIM ([[wpfr>DomainKeys Identified Mail]]) est une information facultative permettant aux serveurs d'email de type [[wpfr>Mail Transfer Agent]] (MTA) de vérifier d'une part, l'//authenticité du domaine// de l'expéditeur d'un courriel, d'autre part l'//intégrité du corps du courriel//.

Autrement dit, DKIM peut confirmer par exemple qu'un message reçu de ''bigbrother@world-company.com'' a bien été émis par une machine liée au domaine world-company.com et que son contenu n'a pas été modifié après que l'expéditeur l'ait envoyé, sans pour autant confirmer que bigbrother existe réellement chez world-company.com ou bien qu'une personne interne à la société n'a pas écrit en son nom.

Ajoutée à l'en-tête des messages emails, la signature DKIM apporte un sérieux complément au traditionnel enregistrement [[wpfr>Sender Policy Framework|SPF]] en améliorant la fiabilité des algorithmes de détection anti-spam. Les normes DKIM et SPF sont des technologies de type [[wpfr>DMARC]] (Domain-based Message Authentication, Reporting and Conformance).

L'enregistrement DNS DKIM de type TXT doit porter sur le sous-domaine virtuel ''dkim._domainkey'' du domaine principal :\\
|Nom|''dkim._domainkey.mon-domaine.tld.''|
|Type|TXT|
|Valeur|v=DKIM1; k=rsa; s=email; h=sha256; p=clé_publique_encodée_base64_//sans_espace//|

Dans [[wpfr>Plesk]], la valeur de l'enregistrement DKIM pour sud-ouest2.org doit être celle-ci //sans guillemet// :
<code>
v=DKIM1; k=rsa; s=email; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuCBXGUFoM59zVYu40BVQIlUi0k8N3+hOmdooG13W+Jjn/ngOQveeICOKBPNnHU3rf4lsQJ9Gx4lBbAzy2CecirSvzxFWY2y47cJ65lQsdxbTL3Ux5YL/0TYrgqVOsE5nxQMafiL6Osox7xkoeAVoWkiDw/M8OEcgWaVLXWhd/YgVGjQyo+2mPUELLqZTx/ZOHNvvHNom1AzI8hNENFxo77ruZpyNAccrQkcKRpWlsvHRDutGfKDF96mr/tbXENSbbawSxH3SHlmHsOaA3Kx0q7mq+uq0YLyV82dZq6u6o3WDQ9Otv+Hh18RHHAlYnaB+oNvS6nhvSQn6mRrOUllcnQIDAQAB
</code>

Pour vérifier que les informations DNS associées à mon-domaine.tld renvoient la configuration correspondant à sud-ouest2.org, on peut utiliser la commande suivante qui //supprime tout guillemet// et //concatène la clé publique que les serveurs DNS renvoient sous la forme de plusieurs chaînes de caractères//.\\
<code>
dig dkim._domainkey.mon-domaine.tld TXT | awk '/^dkim/{gsub(/^.*TXT\s*/,"");gsub(/\x22|\s/,"");gsub(/\\;/,"; ");print $0}'
</code>

Cette commande est utile au diagnostic car **elle doit renvoyer indifféremment le même résultat pour le domaine sud-ouest2.org que pour mon-domaine.tld :**\\
<code>
mederic@devuan:~$ dig dkim._domainkey.sud-ouest2.org TXT | awk '/^dkim/{gsub(/^.*TXT\s*/,"");gsub(/\x22|\s/,"");gsub(/\\;/,"; ");print $0}'
v=DKIM1; k=rsa; s=email; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuCBXGUFoM59zVYu40BVQIlUi0k8N3+hOmdooG13W+Jjn/ngOQveeICOKBPNnHU3rf4lsQJ9Gx4lBbAzy2CecirSvzxFWY2y47cJ65lQsdxbTL3Ux5YL/0TYrgqVOsE5nxQMafiL6Osox7xkoeAVoWkiDw/M8OEcgWaVLXWhd/YgVGjQyo+2mPUELLqZTx/ZOHNvvHNom1AzI8hNENFxo77ruZpyNAccrQkcKRpWlsvHRDutGfKDF96mr/tbXENSbbawSxH3SHlmHsOaA3Kx0q7mq+uq0YLyV82dZq6u6o3WDQ9Otv+Hh18RHHAlYnaB+oNvS6nhvSQn6mRrOUllcnQIDAQAB
</code>

On peut aussi l'écrire de façon plus explicite :\\
<code>
dig dkim._domainkey.mon-domaine.tld TXT | awk '/^dkim/{gsub(/^.*TXT\s*/,"");gsub(/\x22|\s/,"");gsub(/\\;/,"\n");print $0}'
</code>

Exemple pour le domaine ordi49.fr (ou sud-ouest2.org) :\\
<code>
mederic@devuan:~$ dig dkim._domainkey.ordi49.fr TXT | awk '/^dkim/{gsub(/^.*TXT\s*/,"");gsub(/\x22|\s/,"");gsub(/\\;/,"\n");print $0}'
v=DKIM1
k=rsa
s=email
h=sha256
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuCBXGUFoM59zVYu40BVQIlUi0k8N3+hOmdooG13W+Jjn/ngOQveeICOKBPNnHU3rf4lsQJ9Gx4lBbAzy2CecirSvzxFWY2y47cJ65lQsdxbTL3Ux5YL/0TYrgqVOsE5nxQMafiL6Osox7xkoeAVoWkiDw/M8OEcgWaVLXWhd/YgVGjQyo+2mPUELLqZTx/ZOHNvvHNom1AzI8hNENFxo77ruZpyNAccrQkcKRpWlsvHRDutGfKDF96mr/tbXENSbbawSxH3SHlmHsOaA3Kx0q7mq+uq0YLyV82dZq6u6o3WDQ9Otv+Hh18RHHAlYnaB+oNvS6nhvSQn6mRrOUllcnQIDAQAB
</code>

=== Problème de configuration DKIM dans Plesk ===
La valeur de la clé publique de l'enregistrement DKIM qui était indiquée au 01/10/2017 sur la [[https://sud-ouest2.org/configuration-de-votre-domaine-hebergement-dun-domaine-perso-sur-notre-infrastructure/|page du blog]] sud-ouest2.org est incompatible avec [[wpfr>Plesk]], y compris avec la dernière version Plesk Onyx. Plesk ne sait pas gérer correctement les caractères guillemets : pour chaque guillemet introduit, quelques minutes après la configuration, le logiciel ajoute un caractère d'échappement, si bien que l'[[#Outils en ligne|outil en ligne]] dkimcore.org cité plus haut dans cette page confirme systématiquement que l'enregistrement DKIM n'est pas conforme aux spécifications [[https://www.ietf.org/rfc/rfc6376.txt|RFC 6376]].

Pour configurer correctement DKIM dans Plesk, il faut :
  * Éradiquer tout guillemet
  * Concaténer les éventuelles chaînes de caractères multiples fournies pour la clé publique

=== DKIM policy record ===
Certaines documentations((Documentations évoquant le DKIM policy record :
  * emailarchitect.net > [[https://www.emailarchitect.net/domainkeys/doc/html/object_deploy.htm|Deploy DomainKeys/DKIM Public Key in DNS Server]]
  * support.simpledns.com > [[http://support.simpledns.com/kb/a62/configuring-dns-records-for-domainkeys-dkim.aspx|Configuring DNS records for DomainKeys / DKIM]]
))recommandent d'ajouter un enregistrement pour spécifier le "DKIM policy record" :
|Nom|''_domainkey.mon-domaine.tld.''|
|Type|TXT|
|Valeur|''o=-''\\ ''o=~''|

''o=-'' signifie : "tous les emails sont signés" tandis que ''o=~'' signifie "certains emails sont signés".

[[wpfr>Plesk]] avait spontanément ajouté ''_domainkey.ordi49.fr. TXT o=-'' lorsque j'hébergeais mes boîtes mails sur le même hébergement. Je l'avais retiré après ma migration chez sud-ouest2.org. Je viens de le reconfigurer par acquis de conscience.

=== Vérifier la validité DKIM de son domaine ===
J'invite tous les administrateurs de domaines qui externalisent comme-moi la gestion des emails chez Sud-Ouest à vérifier DKIM à l'aide des [[#Outils en ligne]] listés ci-dessus.

Typiquement :\\
Si DKIM est correctement configuré sur mon-domaine.tld, tout message email envoyé à une adresse externe aux domaines mon-domaine.tld, sud-ouest.org, sud-ouest2.org, aquitania.org, neutralite.org et mailz.org doit :
  - Comporter dans son en-tête les deux champs DKIM-Filter et DKIM-Signature comme dans l'exemple ci-dessous :<code>
DKIM-Filter: OpenDKIM Filter v2.11.0 mx-out-01.sud-ouest2.org 4ABA1809C379C
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mon-domaine.tld;
  s=dkim; t=1506661465;
  bh=+qlNhYuQiot52MMJ53YSV0rt4q35P6JeHyKLUgbd7Ek=;
  h=To:From:Subject:Date:From;
  b=YBwPMGyy8RkRx5O6ZCvMp+j2L8eDDnxDM5strwye1sEs8kU5JE0BfkyDylxy5Sq2I
  sUALnqhslEVcI/5BKCWSWqT10QsmIHxrtnPdBUdAUWv2AuqBzmwEhQ0018OOcDvJx1
  DgStaFJr6mvrlbvgu9/D3dsZvcov1EyzhLFHavUuQ20QUnVKqUxNM1O7ee7bW8L8ht
  zKpH6BFApvcmHk0r3aVdVkHiwoZioVAlrNnZeHfjhXMV3BTYseMtFa/CDjIVwdxefo
  Zv5YwLLvc+UynBEevugN+drTqZF6Yx5UsMWyXM7hmXKgtFHEH5mDE0M1F2kPOKT6nO
  TiLO4p7cbmiaw==
</code>
  - Passer le test de soumission au formulaire de validation DKIM de Devon H. O'Dell cité ci-dessus dans la section [[#Outils en ligne]]. Ce test doit afficher le résultat suivant :\\ Results:\\ **pass**\\ signature identity: **@mon-domaine.tld**\\ verify result: **pass**

=== En savoir plus sur DKIM ===
  * ietf.org > [[https://www.ietf.org/rfc/rfc6376.txt|RFC 6376]]
  * 9vx.org > [[https://9vx.org/post/explaining-dkim/|Explaining DKIM to Your Grandmother]] par Devon H. O'Dell
  * [[http://www.dkim.org]]


==== DNS > Autoconfig ====
Menu :
  * [[#Principe de fonctionnement]]
  * [[#Problème rencontré pour les domaines pris en charge par Sud-Ouest.org]]
  * [[#Contournement du problème pour les domaines pris en charge par Sud-Ouest.org]]
  * [[#Quelques documentations sur les services de découverte automatique autoconfig et autodiscover]]


=== Principe de fonctionnement ===
Comme précisé dans la section Autoconfig de la page sud-ouest2.org > [[https://sud-ouest2.org/configuration-de-votre-domaine-hebergement-dun-domaine-perso-sur-notre-infrastructure/|Configuration de votre domaine – hébergement d’un domaine perso sur notre infrastructure]], les courrielleurs utilisent des services de découverte automatique des paramètres, afin de simplifier la configuration d'une nouvelle adresse courriel.

Les courrielleurs inspirés par Mozilla utilisent préférentiellement le service autoconfig, tandis que ceux qui sont inspirés par Microsoft utilisent préférentiellement le service autodiscover. 

Concernant Mozilla Thunderbird, le service de découverte autoconfig permet que, lorsqu'un utilisateur fait : ''Menu Fichier > Nouveau > Compte courrier existant...'', le seul détail technique qu'il lui reste à configurer, est de choisir entre le protocole POP et le protocole IMAP, ou bien laisser IMAP qui est sélectionné par défaut (au moment de choisir, Thunderbird offre la possibilité de personnaliser les détails techniques en cliquant sur "Configuration manuelle").

Pour découvrir le service de découverte autoconfig, Thunderbird envoie une requête du type : %%https://autoconfig.domain.tld/mail/config-v1.1.xml?emailaddress=name@domain.tld%% afin de recevoir les informations sous la forme d'un flux XML.\\
Par exemple : [[https://autoconfig.ordi49.fr/mail/config-v1.1.xml?emailaddress=testeur@ordi49.fr]]

Pour que cela soit possible, il faut préalablement implémenter sur le serveur une redirection DNS du sous-domaine virtuel autoconfig.domain.tld vers le service autoconfig qui est fourni par le serveur sud-ouest2.org. C'est pourquoi la page sud-ouest2.org > [[https://sud-ouest2.org/configuration-de-votre-domaine-hebergement-dun-domaine-perso-sur-notre-infrastructure/|Configuration de votre domaine – hébergement d’un domaine perso sur notre infrastructure]] indique qu'il faut ajouter l'enregistrement DNS CNAME autoconfig.domain.tld.→ autoconfig.sud-ouest2.org.

À charge ensuite pour le serveur qui se trouve derrière autoconfig.sud-ouest2.org de renvoyer la ressource XML demandée, c'est-à-dire typiquement le contenu d'un fichier de configuration config-v1.1.xml remplissant les spécifications décrites par Mozilla((wiki.mozilla.org > [[https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat|Thunderbird:Autoconfiguration:ConfigFileFormat]])).

=== Problème rencontré pour les domaines pris en charge par Sud-Ouest.org ===
[[#DNS > Autoconfig|Retour au sous-menu de la section DNS > Autoconfig]].

Malheureusement, depuis que le chiffrement TLS s'est généralisé et a été implémenté aux requêtes d'autoconfig de Thunderbird en juin 2019((Source : bucksch.org (Ben Bucksch, développeur Mozilla) > [[https://www.bucksch.org/1/projects/thunderbird/autoconfiguration/|Thunderbird Autoconfiguration]])), le service de découverte autoconfig ne fonctionne pas correctement lorsque l'adresse courriel appartient à un domaine différent de sud-ouest2.org.

L'assistant de configuration Thunderbird effectue des vérifications de sécurité supplémentaires et découvre que le certificat TLS renvoyé par le serveur domain.tld correspond à un autre domaine :

{{ :domaine:thunderbird_-_assistance_ajout_compte_existant_-_exemple_de_boîte_de_dialogue_exception_de_sécurité_2.png?nolink |Exemple de boîte de dialogue d'avertissement de sécurité de l'assistant Thunderbird Menu Fichier > Nouveau > Compte courrier existant...}}

Si l'utilisateur a accepté (introduit) une exception de sécurité, il est fortement recommandé de la supprimer :
  - Paramètres Thunderbird > Vie privée et sécurité > Sécurité > Certificats > Bouton Gérer les certificats...
  - Boîte de dialogues Gestionnaire de certificats > Onglet Serveurs : Supprimer les enregistrements

Pour des raisons de **rigueur méthodologique**, je déroule ci-dessous une **procédure de vérification, dans un terminal, que l'on n'a pas tout faux depuis le début et qu'on ne cumule pas plusieurs problèmes**. Le lecteur pressé peut se reporter au sous-chapitre suivant : [[#Contournement du problème pour les domaines pris en charge par Sud-Ouest.org]].

Suite au message d'erreur dans la sécurité affiché par Thunderbird, on peut effectivement constater qu'une requête ''%%wget https://autoconfig.domain.tld/mail/config-v1.1.xml -O -%%'' n'affiche pas le contenu XML attendu, mais au contraire le message d'erreur suivant :
> Le propriétaire du certificat ne correspond pas au nom d’hôte « autoconfig.domain.tld »

Pour se rassurer et être sûr qu'on n'est pas pris d'un gros coup de fatigue, on peut effectuer une simple requête de résolution DNS :\\
''dig +short autoconfig.domain.tld''

Celle-ci renvoie la redirection précédemment configurée et qui était attendue : ''autoconfig.sud-ouest2.org.''

Pour vérifier, à l'abri dans un terminal, qu'il ne s'agit "que" d'un problème de sécurité parce que l'on peut visualiser le contenu XML renvoyé en réponse à notre requête, il faut demander à wget d'outrepasser les vérifications sécuritaires en ajoutant l'option --no-check-certificate, éventuellement avec l'option -q pour supprimer les messages envoyés vers /dev/stderr, c'est-à-dire quelque chose comme :\\
''%%wget -q --no-check-certificate https://autoconfig.domain.tld/mail/config-v1.1.xml -O -%%''

Indépendamment du problème de certificat, on constate que le contenu renvoyé est correct, ce qui nous conforte dans l'idée que la redirection via l'entrée DNS CNAME fonctionne à 100% :
<code xml>
<clientConfig version="1.1">
  <emailProvider id="sud-ouest2.org">
    <domain>sud-ouest2.org</domain>
    <displayName>Sud-Ouest2 Mail</displayName>
    <displayShortName>Sud-Ouest2</displayShortName>
    <incomingServer type="imap">
      <hostname>mail.sud-ouest2.org</hostname>
      <port>993</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>
    <incomingServer type="pop3">
      <hostname>mail.sud-ouest2.org</hostname>
      <port>995</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>
    <outgoingServer type="smtp">
      <hostname>mail.sud-ouest2.org</hostname>
      <port>587</port>
      <socketType>STARTTLS</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </outgoingServer>
    <documentation url="https://sud-ouest2.org/category/documentation">
      <descr lang="fr">Documentation utilisateur</descr>
      <descr lang="en">Generic settings page</descr>
    </documentation>
  </emailProvider>
</clientConfig>
</code>

Enfin, pour visualiser que le problème provient //__précisément__// du fait que le certificat renvoyé par le serveur de Sud-Ouest.org affiche un nom de domaine différent du nôtre qui est domain.tld, c'est-à-dire celui de Sud-Ouest.org et pas celui d'un domaine tiers((Chez mon hébergeur mutualisé parisien à bas coût Inulogic, un problème de configuration signalé et volontairement ignoré par les deux personnes de l'entreprise, fait qu'un des 4 serveurs en load balancing envoie le certificat obsolète Let's Encrypt d'un domain zwarf.fr pour tous mes sous-domaines.)), il faut demander à openssl d'afficher au format texte les clés de sécurité et les informations de méta-données contenues dans ce certificat :

À cause du [[wpfr>Server Name Indication (SNI)]], la commande diffère s'il s'agit d'un serveur mutualisé ou bien d'un serveur dédié((source : 25/10/2011: stackoverflow.com > [[https://stackoverflow.com/questions/7885785/using-openssl-to-get-the-certificate-from-a-server|Using openssl to get the certificate from a server]])) :
  * Pour un serveur mutualisé (avec SNI) : ''openssl s_client -showcerts -servername autoconfig.domain.tld -connect autoconfig.domain.tld:443 </dev/null''
  * Pour un serveur dédié (sans SNI) : ''openssl s_client -showcerts -connect autoconfig.domain.tld:443 </dev/null''

Voici la réponse renvoyée par notre serveur pour le sous-domaine autoconfig.domain.tld dont l'enregistrement DNS CNAME autoconfig.domain.tld. pointe vers autoconfig.sud-ouest2.org. :
<code>
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = sud-ouest2.org
verify return:1
---
Certificate chain
 0 s:CN = sud-ouest2.org
   i:C = US, O = Let's Encrypt, CN = R3
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=CN = sud-ouest2.org

issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA384
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4255 bytes and written 395 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 384 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE
</code>

Le "Common Name" (CN = sud-ouest2.org) indique effectivement que le certificat du chiffrement TLS est étranger au sous-domaine autoconfig.domain.tld, et qu'il appartient bien à sud-ouest2.org.

Conclusion : le seul problème à résoudre est celui de faire correspondre le certificat TLS de la réponse avec notre nom de domaine domain.tld.


=== Contournement du problème pour les domaines pris en charge par Sud-Ouest.org ===
[[#DNS > Autoconfig|Retour au sous-menu de la section DNS > Autoconfig]].

Ci-dessous, je décris une possibilité parmi d'autres, et qui est relativement simple à mettre en œuvre pour le service de découverte autoconfig qui concerne Thunderbird et les autres logiciels libres qui s'en inspirent. Il s'agit d'héberger le petit fichier config-v1.1.xml sur notre propre serveur accessible dans notre sous-domaine autoconfig.domaine.tld, plutôt que d'effectuer une redirection vers un serveur de Sud-Ouest. C'est quasiment une méthode sans-échec, puisqu'il n'est pas question de créer un sous-domaine virtuel et de passer du temps à tâtonner pour obtenir une solution idéale((Si j'avais du temps, je préférerai créer un sous-domaine virtuel sur mon propre serveur Apache, et mettre en place une solution à base de redirection de requête vers un programme php inspiré de la méthode de David Mercereau [[#Quelques documentations sur les services de découverte automatique autoconfig et autodiscover|indiquée en annexe]] et qui convient mieux à mon état d'esprit.)).

  - Dans le gestionnaire DNS du Web hosting control panel, si présent, supprimer au préalable l'enregistrement suivant :\\ ''autoconfig.domaine.tld.    CNAME    autoconfig.sud-ouest2.org.''\\ Chemin dans Plesk : Sites Web & Domaines (vue en liste dynamique ou active) > Onglet Hébergement et DNS > Paramètres DNS
  - Dans le Web hosting control panel, créer le sous-domaine autoconfig.domaine.tld.\\ Chemin dans Plesk : Sites Web & Domaines > Ajouter un sous-domaine
  - Dans le Web hosting control panel, si ce n'est pas déjà fait, activer le service DNS local pour autoconfig.domaine.tld.\\ Chemin dans Plesk : Sites Web & Domaines (vue en liste dynamique ou active) > Onglet Hébergement et DNS > Paramètres DNS : Activer le service DNS local de la zone DNS autoconfig.domaine.tld
  - Attendre la propagation de l'enregistrement DNS A pour autoconfig.domaine.tld en effectuant régulièrement des requêtes DNS :\\ ''dig +short A autoconfig.domaine.tld''
  - Dans le Web hosting control panel, créer un certificat TLS Let's Encrypt pour le sous-domaine autoconfig.\\ Chemin dans Plesk : Sites Web & Domaines > autoconfig.domaine.tld > Sécurité Certificats SSL/TLS
  - Attendre et vérifier périodiquement que la page d'accueil ''%%https://autoconfig.domaine.tld/%%'' affiche le document HTML par défaut du serveur. (Comme j'avais demandé la création d'un certificat Let's Encrypt pour tous les sous-domaines joker (wildcard), j'ai contrôlé que la commande ''dig TXT _acme-challenge.autoconfig.domaine.tld'' affiche correctement la chaîne de caractères affichée dans Plesk)
  - Sur l'ordinateur local, créer le contenu qui sera envoyé dans le répertoire du sous-domaine autoconfig du serveur distant : <code bash>
mkdir -p autoconfig/mail
cd autoconfig/mail
wget -q --no-check-certificate https://www-01.sud-ouest2.org/.well-known/autoconfig/mail/config-v1.1.xml -O - | tee config-v1.1.xml
</code>
  - Si nécessaire en fonction de la configuration par défaut du serveur Apache, ajouter le⋅s fichier⋅s .htaccess de restriction sécuritaire. Idem sous NGINX qui n'utilise pas de fichier .htaccess (sauf si le plugin github.com > e404 > [[https://github.com/e404/htaccess-for-nginx|htaccess for nginx]] est utilisé)
  - Envoyer le contenu du répertoire local autoconfig dans le répertoire du sous-domaine autoconfig sur le serveur distant
  - Tester la récupération du contenu du fichier dans un terminal :\\ ''%%wget -q https://autoconfig.domaine.tld/mail/config-v1.1.xml -O -%%''\\ Exemple :\\ ''wget -q https://autoconfig.ordi49.fr/mail/config-v1.1.xml -O -''
  - Si rien ne s'affiche, supprimer l'option ''-q'' pour afficher les messages d'erreur, ajouter l'option ''--no-check-certificate'', voire l'option ''-S'' pour visualiser l'en-tête HTTP de la réponse
  - Dans Thunderbird, effectuer un test : Menu Fichier > Nouveau > Compte courrier existant... :\\ Nom complet : ''testeur@domain.tld'' ; Adresse email : ''testeur@domain.tld'' ; Mot de passe : nimporte_quoi (ne pas retenir le mot de passe).\\ Puis cliquer sur Continuer.\\ Thunderbird affiche "Configurations disponibles" : si sous la rubrique IMAP ou POP3, le nom qui est affiché pour les serveurs entrant et sortant est ''mail.sud-ouest2.org'', alors tout fonctionne !\\ Dans tous les cas, cliquer sur le bouton Annuler pour mettre fin au test.

=== Quelques documentations sur les services de découverte automatique autoconfig et autodiscover ===
[[#DNS > Autoconfig|Retour au sous-menu de la section DNS > Autoconfig]].

**Ressources documentaires sur le service de découverte automatique autoconfig, listées par degré de complexité :**
  * 22/06/2015: philippe.scoffoni.net > [[https://philippe.scoffoni.net/comment-auto-configuration-comptes-messagerie-thunderbird-autres/|Comment mettre en place l’auto-configuration de comptes de messagerie pour Thunderbird (et d’autres)]]
  * wiki.mozilla.org > [[https://wiki.mozilla.org/Thunderbird:Autoconfiguration|Thunderbird:Autoconfiguration]]
  * wiki.mozilla.org > [[https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat|Thunderbird:Autoconfiguration:ConfigFileFormat]] : fournit un modèle complet de fichier config-v1.1.xml
  * developer.mozilla.org > [[https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration/FileFormat/HowTo|Autoconfig: How to create a configuration file]] : au 17/12/2023, renvoie (provisoirement ?) vers la ligne ci-dessous :
  * bucksch.org (Ben Bucksch, développeur Mozilla) > [[https://www.bucksch.org/1/projects/thunderbird/autoconfiguration/|Thunderbird Autoconfiguration]] : fournit plusieurs cas types de configuration des serveurs Apache et NGINX pour la prise en charge de autoconfig

**Ressources documentaires sur le service de découverte automatique autodiscover :**
  * 01/04/2016: learn.microsoft.com > [[https://learn.microsoft.com/en-us/previous-versions/office/office-2010/cc511507(v=office.14)?redirectedfrom=MSDN|Plan to automatically configure user accounts in Outlook 2010]]

**Ressources documentaires qui portent à la fois sur les services de découverte automatique autoconfig et autodiscover :**
  * 18/09/2020: david.mercereau.info > [[https://david.mercereau.info/autoconfig-thunderbird-autodiscover-outlook-sur-messagerie-heberge-ispconfig/|Autoconfig (thunderbird) & Autodiscover (outlook) sur messagerie hébergé ISPconfig]] : la démarche de David Mercereau de prise en charge universaliste des services de découverte automatique est à mon avis la plus intéressante : sa conception est simple et puissante. Mais il faut accepter que sa mise en œuvre jusqu'au succès de tous les tests prenne plus de temps que les autres démarches.
==== SSL/TLS ====
Vérifier la disponibilité des serveurs sud-ouest.org [[wpfr>Simple Mail Transfer Protocol|SMTP]], [[wpfr>Internet Message Access Protocol|IMAP]] et [[wpfr>Post Office Protocol|POP]] au travers d'un canal chiffré [[wpfr>Transport Layer Security|TLS]] :
  * Serveur IMAP : <code>openssl s_client -connect mail.sud-ouest2.org:993</code>
  * Serveur POP : <code>openssl s_client -connect mail.sud-ouest2.org:995</code>
  * Serveur SMTP : <code>openssl s_client -connect mail.sud-ouest2.org:587 -starttls smtp</code>

Via les protocoles POP et SMTP, taper quit pour sortir de la conversation((
  * POP/SSL : <code>echo quit | openssl s_client -connect mail.sud-ouest2.org:995</code>
  * SMTP/SSL : <code>echo quit | openssl s_client -connect mail.sud-ouest2.org:587 -starttls smtp</code>
)), tandis que via le protocole IMAP, il faut théoriquement taper logout (mais le serveur IMAP de sud-ouest ne comprend ni quit, ni logout, ni exit).

Exemple pour le serveur POP :
<code>
mederic@devuan:~$ openssl s_client -connect mail.sud-ouest2.org:995
CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = mail.sud-ouest2.org
verify return:1
---
Certificate chain
 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mail.sud-ouest2.org
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
[...]
quit
+OK Logging out
closed
</code>

=== Aller plus loin avec openssl ===
Si vous rencontrez un problème de connexion TLS avec un [[wpfr>Client de messagerie|courrielleur]] bien que les paramètres de configuration soient corrects, vous pouvez éventuellement réaliser un log des connexions POP/SSL et SMTP/SSL grâce au programme en ligne de commande openssl du projet [[wpfr>logiciel libre]] [[wpfr>OpenSSL]]. Ces logs révèlent des informations supplémentaires qui peuvent éventuellement aider à comprendre certains problèmes (interception des connexions chiffrées par des logiciels intermédiaires sous Microsoft Windows, etc.).

Exemples :
  * Une commande pour récupérer un log de connexion POP/SSL :\\ <code>echo quit | openssl s_client -connect mail.sud-ouest2.org:995 -state -nbio 2>&1 |tee $(date +%Y.%m.%d.%H.%M.%S).openssl-log.txt</code>
  * Une commande pour récupérer un log de connexion SMTP/SSL :\\ <code>echo quit | openssl s_client -connect mail.sud-ouest2.org:587 -state -starttls smtp 2>&1 |tee $(date +%Y.%m.%d.%H.%M.%S).openssl-log.txt</code>

**Ressources diverses en lien avec OpenSSL :**
  * manpage //complet// de la ligne de commande openssl : [[https://wiki.openssl.org/index.php/Command_Line_Utilities|wiki.openssl.org/index.php/Command_Line_Utilities]]
  * OpenSSL Command-Line HOWTO : [[https://www.madboa.com/geek/openssl/|madboa.com/geek/openssl]]
  * openssl pour Windows : [[http://gnuwin32.sourceforge.net/packages/openssl.htm|gnuwin32.sourceforge.net/packages/openssl.htm]]
  * Autres outils GNU pour Windows : [[http://gnuwin32.sourceforge.net/|gnuwin32.sourceforge.net]]