La totalité des documents, au format MARKDOWN, ainsi que tous les fichiers de cette section (ligne de commande Bash, scripts...) seront mis en ligne, dans une version librement (et plus facilement) téléchargeable, sur mon espace de partage GitHub (voir ma page de liens).
Configuration de Bash en mode "strict" (débogage facilité).
Ces outils comportent des "lanceurs" qui ouvrent une fenêtre console temporaire permettant d'exécuter le "cryptage/décryptage" proprement dit, de saisir le mot de passe et de s'assurer du bon déroulement.
Lancement en mode graphique par double-clic sur les programmes "lanceurs" dans le navigateur de fichiers.
Configurer les noms des fichiers "en clair" et "crypté" dans le corps des 2 scripts ".cryptage" et ".decryptage" avant le 1er lancement.
Les fichiers à crypter peuvent être des archives contenant un nombre quelconque de fichiers.
Pour ne pas encombrer le répertoire, les 2 scripts ".cryptage" et ".decryptage" sont en "fichiers cachés" (après suppression du "_" à réaliser après téléchargement, ils commenceront par un ".").
Je place le fichier crypté ainsi que les 4 fichiers de l'outil dans un même répertoire pour constituer un ensemble autonome.
L'algorithme de chiffrement choisi est "aes-256-cbc", c'est l'algorithme actuel le plus performant en terme de sécurité et rapidité. La sécurité du cryptage dépendra principalement de la robustesse du mot de passe choisi.
"OpenSSL" doit être installé sur le système.
L'ensemble des fichiers de l'outil doivent être rendus exécutables.
Avec la version que j'ai utilisée (OpenSSL 1.1.0i-fips 14 Aug 2018), le "salage" est automatique : pas besoin de le spécifier (option : "-salt" non reconnue) ; il change à chaque invocation de la commande "openssl aes-256-cbc" et il est mémorisé en début de fichier.
Réalisé et exécuté sous Linux OpenSuse Leap ; bureau KDE ; sur PC 64 bits.
On dispose d'un fichier contenant des données sensibles que l'on veut protéger. On place ce fichier ainsi que les 4 fichiers de l'outil dans un même répertoire et on configure les noms des fichiers "en clair" et "crypté" dans le corps des 2 scripts ".cryptage" et ".decryptage".
Pour ouvrir ce fichier, afin de le consulter ou de le modifier, on doubleclic sur "decryptage_lanceur".
On peut alors consulter et/ou modifier la copie en clair, générée par l'outil, à l'aide de l'éditeur approprié.
Si on souhaite crypter et conserver la version que l'on vient de modifier, on doubleclic sur "cryptage_lanceur" => ATTENTION !!! la précédente version cryptée est écrasée sans préavis par la version que l'on vient de modifier.
On efface manuellement la copie en clair.
Tous les éléments sont donnés dans ma page : Surveillance de l'activité nocturne des hérissons dans mon jardin (rubrique Sciences) et dans le repository GitHub : EnregistrementCameraSurveillance (page Liens).
Il peut être utile de programmer l'envoi automatique de mail à partir d'un programme (script ou autre) afin d'avertir un gestionnaire humain de la survenue d'un événement technique détecté ou produit par une machine.
Ce dossier relate seulement les expérimentations que j'ai conduites dans cet objectif (uniquement celles qui ont abouti, en fait !...) et ne constitue aucunement une référence ou une présentation exhaustive des possibilités offertes par les outils que j'ai essayés. Ce dossier ne s'adresse pas aux spécialistes dans ce domaine (qui en savent beaucoup plus que moi, par définition !...) mais aux néophytes qui cherchent à comprendre, à expérimenter et à compléter leurs scripts ou programmes par une fonctionnalité de communication. Cependant, je suis à l'écoute des personnes expérimentées qui voudront bien corriger les erreurs qu'ils pourront déceler et/ou compléter/améliorer certains aspects. Je les en remercie par avance.
Le présent document, au format MARKDOWN (fichier : README.md), ainsi que tous les fichiers de ce dossier, SERONT disponibles, dans une version librement (et plus facilement) téléchargeable, sur mon espace de partage GitHub (voir ma page de liens) dès que j'aurai pu conduire tous mes essais.
Plusieurs solutions existent pour ce faire et des ressources sont disponibles sur Internet. Pour ma part, j'ai expérimenté l'utilisation de la commande MAILX, facilement installable sous LINUX, qui permet (entres autres) de faire cela assez simplement.
MAILX, version évoluée de la commande UNIX historique MAIL, emprunte sa syntaxe à l'éditeur de texte en ligne ED d'UNIX (un autre dinosaure !).
L'avantage de MAILX, ainsi que des commandes similaires, est que l'on peut facilement la paramétrer et la mettre au point en ligne de commande, avant de l'intégrer dans un exécutable (ou de l'appeler par un exécutable).
J'ai réalisé ces essais avec 5 relais SMTP et j'ai consigné les résultats obtenus avec chacun d'eux, ainsi que les particularités que j'ai pu relever.
A noter que, dans le but de freiner l'envoi de spam (et aussi de d'alléger leur charge), les serveurs SMTP gratuits limitent généralement le nombre de messages envoyés quotidiennement par un utilisateur. Dans le même esprit, ils disposent de fonctionnalités, dépendant des opérateurs, qui interdisent tout envoi anonyme de mail, comme on le verra lors du bilan des essais réalisés.
Le choix des outils que j'ai utilisés a été guidé par le fait qu'ils étaient, par défaut, déjà installés et opérationnels sur ma machine.
L'ensemble de mes essais ont été réalisés dans l'environnement et avec les outils suivants :
Je n'ai fait aucune modification dans les fichiers de configuration de la messagerie éventuellement présents sur ma machine, tant au niveau système (/etc/mail.rc) qu'au niveau utilisateur (~/.mailrc). Les modifications de la configuration de MAILX nécessaires ont été faites directement sur la ligne de commande, au moment de l'appel, à l'aide de l'option -S variable[=valeur]. Je trouve que cette démarche présente plusieurs avantages. Elle permet :
Pour envoyer un mail, le MUA MAILX établit une connexion et dialogue avec un relais MTA extérieur. Le protocole SMTP est utilisé pour ce dialogue. Le message sera ensuite acheminé à travers Internet, de MTA en MTA jusqu'au destinataire qui ira le lire avec son client de messagerie en utilisant le protocole IMAP ou POP.
Les 5 relais SMTP que j'ai testés sont les suivants :
Ils sont accessibles gratuitement mais nécessitent une identification avec mot de passe lorsqu'on les sollicite pour envoyer un mail. Il est donc nécessaire d'avoir préalablement créé un compte sur ces derniers. On peut utiliser son compte de messagerie habituel auquel on accède quotidiennement via un Webmail ou avec un client comme Thunderbird.
Le port utilisé sur ces serveurs est le 587. Ce numéro de port est maintenant généralisé pour la soumission sécurisée de mails. Il permet une connexion sécurisée avec le cryptage TLS.
Je présente la ligne de commande BASH qui m'a permis de conduire les tests (contenue dans le fichier : mailx_test). Il suffit de corriger les champs adéquats puis de copier/coller cette ligne dans la console pour refaire les tests. Cette ligne peut ensuite être incorporée dans un script.
La ligne de commande utilisée pour la conduite des essais sur les différents serveurs est la suivante :
cat corps.txt | mailx -v \
-s "Objet : Texte décrivant l'objet du message" \
-a nom_du_fichier_a_joindre \
-r "Expéditeur <expediteur@domaine_expediteur>" \
-S replyto="Adresse mail de réponse <repondre_a@domaine_reponse>" \
-S smtp="nom_du_serveur_smtp:port_du_serveur_smtp" \
-S smtp-use-starttls \
-S smtp-auth=login \
-S smtp-auth-user="identifiant" \
-S smtp-auth-password="mot_de_passe" \
-S ssl-verify=ignore \
mail_destinataire_1@domaine_destinataire_1 \
mail_destinataire_2@domaine_destinataire_2Explication de la signification des options et paramètres utilisés lors de l'appel à MAILX :
-v ==> (verbose) permet de suivre, sur le terminal, le détail des opérations ; très utile pour la mise au point !
-s "Objet : Texte décrivant l'objet du message" ==> il sera affiché dans le champ "OBJET" du message reçu
-a nom_du_fichier_a_joindre ==> pièce jointe
-r "Expéditeur <expediteur@domaine_expediteur>" ==> champ visible "EXPEDITEUR" ou "DE" qui sera affiché dans l'entête du message reçu ; il se compose du commentaire : "Expéditeur" suivi de l'adresse mail encadrée par des chevrons : "expediteur@domaine_expediteur"
-S replyto="Adresse mail de réponse <repondre_a@domaine_reponse>" ==> champ visible "REPONDRE" qui sera affiché dans l'entête du message reçu ; il se compose du commentaire : "Adresse mail de réponse" suivi de l'adresse mail encadrée par des chevrons : "repondre_a@domaine_reponse"
-S smtp="nom_du_serveur_smtp:port_du_serveur_smtp" ==> nom du serveur SMTP utilisé (ou son N° IP) et port, par exemple "smtp.orange.fr:587"
-S smtp-use-starttls ==> demande à MAILX d'émettre une commande STARTTLS pour établir une connexion de session SMTP cryptée SSL/TLS (tous les serveurs ne prennent pas en charge cette commande)
-S smtp-auth=login ==> précise la METHODE utilisée pour s'identifier sur le serveur SMTP (ici : ID + PW)
-S smtp-auth-user="identifiant" ==> précise l'identifiant du compte utilisé pour s'identifier sur le serveur SMTP (c'est le plus souvent une adresse mail)
-S smtp-auth-password="mot_de_passe" ==> précise le mot de passe (en clair !) du compte utilisé pour s'identifier sur le serveur SMTP
-S ssl-verify=ignore ==> le paramètre "ssl-verify" définit l'action à effectuer si une erreur se produit lors de la validation du certificat du serveur SSL/TLS ; dans ce cas, la valeur "ignore" demande de ne pas effectuer de validation ; cela diminue la sécurité mais simplifie les échanges et évite le blocage dans certains cas
mail_destinataire_1@domaine_destinataire_1 ==> le ou les destinataires du mail
mail_destinataire_2@domaine_destinataire_2 ==> il faut alors séparer leurs adresses par un espaceFonctionne à condition de ne pas choisir l'option "starttls" (supprimer la ligne -S smtp-use-starttls). De plus, il faut que le nom de domaine de l'adresse mail indiquée comme expéditeur existe
Le nom de la machine (HOSTNAME) de l'expéditeur et ses IP publiques (IPV4 et IPV6) sont présents dans l'entête du message ainsi que l'identifiant avec lequel l'utilisateur s'est connecté, c'est-à-dire son adresse mail complète (cette dernière est codée en en base 64).
Fonctionne à condition que le nom de domaine de l'adresse mail indiquée comme expéditeur existe.
Le nom de la machine (HOSTNAME) de l'expéditeur et ses IP publiques (IPV4 et IPV6) sont présents dans l'entête du message ainsi que l'identifiant avec lequel l'utilisateur s'est connecté, c'est-à-dire son adresse mail sans le nom de domaine (@free.fr). Tout est en clair.
Le nom de la machine (HOSTNAME) de l'expéditeur et son IPV6 publique sont présents dans l'entête du message ainsi que l'identifiant avec lequel l'utilisateur s'est connecté, c'est-à-dire son adresse mail sans le nom de domaine (@free.fr). Tout est en clair.
De plus, le "Nom expéditeur" est conservé mais son "adresse mail" est remplacée par l'identifiant du compte GMAIL de l'expéditeur (son adresse mail).
A noter que pour pouvoir utiliser le compte souscrit chez GMAIL dans ces conditions, la politique de sécurité de GMAIL demande d'autoriser préalablement l'exécution d'applications moins sécurisées dans l'interface de gestion du compte.
Marche à condition que l'expéditeur donné SOIT le titulaire du compte.
Aucune confidentialité : le mail du titulaire du compte est transmis.
De plus, l'adresse IP V4 ainsi que le nom de la machine (HOSTNAME) sont présents dans l'entête (cachés). Tout est en clair.
Marche à condition que l'expéditeur donné SOIT le titulaire du compte.
Aucune confidentialité : le mail du titulaire du compte est transmis.
De plus, l'adresse IP V4 ainsi que le nom de la machine (HOSTNAME) sont présents dans l'entête (cachés). Tout est en clair.
Il est possible (dans certains cas) d'envoyer un mail en ouvrant manuellement une session avec le serveur SMTP et en dialoguant directement avec lui. Bien que plus complexe, cette démarche est formatrice et permet de comprendre, dans le détail, le fonctionnement du protocole SMTP.
Pour ce faire, je n'ai pas employé l'historique TELNET car tous les serveurs SMTP utilisent maintenant le protocole de transport sécurisé SSL. Pour ma part, j'ai utilisé openssl s_client.
Dans le cas d'un dialogue en direct, les paramètres d'authentification (ID + PW) doivent être codés en base 64 avant d'être transmis au serveur SMTP. Cela peut se faire en ligne de commande sous bash par :
echo "Chaîne de caractères à encoder" | base64
la réponse donne : "Q2hhw65uZSBkZSBjYXJhY3TDqHJlcyDDoCBlbmNvZGVyCg=="Il est facile de vérifier le résultat en exécutant le décodage :
echo "Q2hhw65uZSBkZSBjYXJhY3TDqHJlcyDDoCBlbmNvZGVyCg==" | base64 -d
la réponse donne la chaîne initiale : "Chaîne de caractères à encoder"On peut aussi utiliser une des multiples fonctionnalités de OPENSSL :
echo "Chaîne de caractères à encoder" | openssl enc -base64
la réponse donne : "Q2hhw65uZSBkZSBjYXJhY3TDqHJlcyDDoCBlbmNvZGVyCg=="A noter que ce codage n'est pas un cryptage : il ne donne absolument aucune confidentialité !
Lorsqu'on utilise un client de messagerie comme MAILX, c'est lui qui se charge du codage en base 64, avant envoi au serveur SMTP.
Comme les serveurs SMTP n'ont pas l'habitude de dialoguer directement avec des humains, ils manquent souvent de patience et on risque fort la déconnexion intempestive (timeout !) avant d'avoir terminé, ce qui est agaçant ! Il est donc préférable de préparer l'enchaînement des questions/réponses dans un script et de prévoir un système qui va automatiser l'envoi de la bonne réponse au serveur dès que la question attendue sera reçue.
Pour ce faire, j'utilise l'outil EXPECT qui fournit un shell interactif avec son propre langage, lequel comporte notamment les commandes suivantes :
Ainsi, nul besoin d'insérer des temporisations (sleep X) qui, au mieux, vont considérablement ralentir le dialogue et dont on n'est jamais sûr qu'elles vont être suffisantes dans tous les cas. Pour les vétérans, il y a une certaine analogie avec le signal acknowledge (ACK) du protocole Centronics utilisé, jadis, pour communiquer en mode parallèle avec les imprimantes.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Un exemple de script est fourni dans le fichier : openssl_test.
A noter que ces mécanismes ne sont nullement assimilables à un client de messagerie tout fait : on garde la visibilité et la maîtrise complète de chaque échange, tant au niveau du contrôle des messages reçus que de la composition de ceux qu'on envoie.