Gandi c’est fini

Et dire que c’était l’hébergeur de ma première adresse email associée à mon nom de domaine.

Et oui, j’en ai désormais terminé avec Gandi depuis presque un mois maintenant. Propriétaire depuis plusieurs années d’un nom de domaine géré chez Gandi, j’avais fait le choix de cet hébergeur pour sa réputation, les bons retours que j’avais pu lire à plusieurs reprises en ligne, et surtout, pour les quelques adresses mails incluses dans leur offre nom de domaine.

L’histoire commence à la mi-2023, après réception et lecture d’un mail de Gandi informant ses clients des changements à venir et des évolutions de leurs tarifs. Trahison ! L’offre mail associée à un nom de domaine va être arrêtée et les clients forcés à souscrire à une offre mail facturée à l’adresse mail. Augmentation des coûts x8 dans mon cas, puisque deux adresses sont activement utilisées. Je me félicite de n’avoir finalement pas incité mes proches à migrer leur adresse email sur mon domaine.

A l’époque, de mémoire, il était possible de créer jusqu’à 5 adresses mails associées à un nom de domaine. Mon frère et moi-même avons donc pu troquer nos adresses gérées par le FAI du moment pour passer sur des adresses plus pérennes (du moins en théorie), et affichant notre nom de domaine: unicoda.fr. Ce qui faisait pour moi l’intérêt de cette offre en particulier, était la possibilité de définir des alias en mode regex *, permettant ainsi d’avoir facilement une adresse dynamique par contexte, par site ou par provenance. Avec par exemple l’alias suivant : moi-*@mondomaine.fr, je pouvais au besoin donner l’adresse moi-vendeur1@mondomaine.fr pour les communications en provenance de vendeur1 et moi-association-xy@mondomaine.fr pour les communications en provenance de association-xy. Et cela en toute simplicité.

Cette organisation a l’intérêt de ne pas exposer son adresse mail principale à des acteurs commerciaux parfois peu scrupuleux et dont les fichiers clients peuvent être réutilisés, malgré l’opposition explicite à l’envoi de mails commerciaux, mais aussi d’identifier immédiatement la source d’une fuite de données, en cas de faille de sécurité chez le contact x ou y. Heureusement chose exceptionnelle, il m’est arrivé de recevoir des spams sur l’une de mes adresses spécifiques, m’indiquant ainsi que l’adresse confiée au contact et à son système informatique avait fini par fuiter. Si les protections anti-spam ne font pas effet, il est alors possible de mettre l’adresse en liste noire, pour bloquer définitivement les mails entrants sur cette adresse et conserver ainsi une adresse saine. Mon erreur ici, a peut-être été de ne pas choisir d’utiliser le caractère `+` pour définir mon alias, car ce type d’alias est plus standard et donc souvent supporté chez les autres fournisseurs de mail.

Revenons à nos moutons. Alors que je commençais à envisager de faire migrer d’autres membres de la famille en utilisant les adresses restantes, Gandi annonça une baisse du nombre de mail associés à un domaine et limita leur nombre à 3 adresses. Statu quo. Nous restons donc à deux utilisateurs des adresses mails fournies. Avance rapide au 14 juin 2023 et à l’annonce de la fin des adresses mails fournies avec un nom de domaine au 30 novembre de la même année. Une solution simple consisterait à migrer les 2 comptes mails que nous utilisons vers l’offre de mail de Gandi, mais celle-ci, avec l’augmentation des tarifs, va passer de 0,42e/mois à 4,2e/mois. Rien de moi qu’un x10. Pour l’utilisation que nous faisons de nos comptes personnels, l’addition est salée.

Ayant bien d’autres choses à traiter, nous avons donc cherché à limiter les dégâts. Sur les deux adresses liées à mon domaine, je n’ai conservé que la mienne, l’autre ayant été décommissionnée, et j’ai donc commencé à me voir facturer le coût mensuel d’une adresse. Une migration durant cette période me semblait hasardeuse, car risquait de me faire perdre des emails, en réception, ou en envoi, du moins le temps de résoudre les éventuels problèmes de configuration.

Les mois passant, la routine s’installe. Le service fonctionne toujours correctement et je n’ai pas l’envie ni le temps de me concentrer sur la migration de mon adresse mail, bien qu’une courte interruption de service soit maintenant acceptable.

Jusqu’à début septembre 2024, qui voit arriver le renouvellement du nom de domaine auquel sont liées les adresses. Alors que je démarre la procédure, le prix du renouvellement d’un .fr pour un an s’affiche: 30 euros et des brouettes. J’avais bien vu passer un document listant les augmentations de tarifs, mais celle-ci m’avait échappé… Une nouvelle fois, on sent que la politique tarifaire a changé après le rachat par un groupe d’investissement en 2019 : il faut que le fric rentre ! (Lire à ce sujet « Gandi, passe de « no bullshit » à « bait and switch » ? » chez linuxfr) A une semaine de la date d’expiration, j’hésite quelques instants. Rester encore un an et consentir à me faire racketter, le temps de trouver une autre solution, ou entamer une migration d’urgence.

Ce sera une migration d’urgence vers OVH, où les tarifs sont bien plus raisonnables et que j’utilise déjà pour unicoda.com: nom de domaine et serveur, sans avoir eu à m’en plaindre jusqu’à présent – excepté peut-être lorsqu’unicoda a littéralement migré dans le cloud avec l’incendie du datacenter de Strasbourg (Mais j’avais trouvé l’expérience plutôt enrichissante. Voir: Unicoda a brûlé !). Problème, les offres mail ne proposent pas de configuration d’alias * comme celle décrite plus haut. L’adresse mail comprise dans l’offre nom de domaine propose la création de 1000 alias, et l’offre pro, l’utilisation du + pour la création dynamique d’adresses. Il va falloir migrer toutes mes adresses existantes, vers un format +, en remplacement du caractère que j’utilisais jusqu’à présent.

J’ouvre une ligne de commande, et lance une analyse sur le contenu de mon password store: pass grep -E ‘monPrefix-.*@unicoda.fr’ > compte_a_migrer.txt. J’ouvre le fichier et me retrouve nez-à-nez avec 300 lignes de données, chaque compte occupant deux lignes, soit pas loin de 150 comptes à mettre à jour. Commence alors la tâche répétitive et gargantuesque de modification du mail: connexion au compte, changement du mail, validation de la nouvelle adresse, suppression de l’ancienne, mise à jour de l’entrée dans le gestionnaire de mot de passe, et on recommence.

Après trois soirées de désœuvrement intellectuel, ça y est, la majorité des adresses est migrée, et les adresses restantes ont fait l’objet d’une création d’alias manuelle. J’enclenche donc la procédure de transfert du nom de domaine, à 72h de son expiration, scotché à mon écran comme un papillon de nuit à sa lumière, inquiet de voir le processus automatisé se gripper. Tel ne fut heureusement pas le cas. La migration s’est déroulée sans accroc en ce qui m’a semblé moins de 3h et, après quelques heures de sommeil bien méritées, la partie mail a suivi, avec test d’envoi et de réception dans la foulée.

Rétrospectivement, j’aurais pu m’éviter énormément de travail en choisissant de ne migrer que les comptes importants et considérer de nombreux comptes de boutiques ou de services en ligne comme des comptes historiques. Ne pas les migrer signifiait une possibilité de perte d’accès en cas de reset forcé du mot de passe, le mail de contact n’existant plus mais, dans une telle situation, il aurait été seulement nécessaire de créer l’alias manquant pour débloquer la situation. Une autre solution, qui ne m’est venu malheureusement que bien après, aurait été d’utiliser les APIs OVH pour scripter la création des alias (POST /email/mxplan/{service}/account/{email}/alias et POST /email/pro/{service}/account/{email}/alias). Si l’idée d’automatiser ce processus rébarbatif de mise à jour des adresses mail m’a bien traversé l’esprit, l’urgence de la situation et le peu de temps restant pour migrer le domaine, via une procédure qui m’était jusqu’alors inconnue, m’ont empêchés de prendre le recul nécessaire pour envisager cette solution.

Finalement, le transfert d’un nom de domaine, opération que j’appréhendais quelque peu, est d’une simplicité enfantine et ce changement d’hébergeur me permet de limiter l’augmentation du coût des services que j’utilise et de simplifier un peu le suivi, la gestion et la facturation en les regroupant. La découverte des APIs OVH quant à elle, me donne quelques idées à explorer, un jour peut-être et vient me rappeler que, dans une situation d’urgence, il faut parfois savoir ralentir pour prendre un peu de recul. Et, qui sait, s’accorder d’explorer un autre chemin qui, s’il s’avère praticable, permettra de simplifier les choses et de gagner du temps.

Oh Gandi, c’est fini. Je ne crois pas que j’y retournerai un jour.

exim4

J’ai effectué courant décembre 2020, une migration de mes services auto-hébergés vers une nouvelle machine. Ayant réorganisé en 2019 l’ensemble de mes roles Ansible, et passant d’une base Debian 9 à Debian 10, de nombreuses corrections ont une nouvelle fois été nécessaires avant que l’ensemble soit à nouveau déployé correctement de manière automatique. La majorité des adaptations provenaient du passage à php7.4, avec un test de la version 8 (encore trop récente pour plusieurs services). Le reste concernait l’envoi de mail depuis le serveur avec exim4.

En commençant l’aventure de l’auto-hébergement, la question de l’envoi des mails ne s’était pas posée, car, dans mes souvenirs en tout cas, WordPress arrivait à me notifier par mail sans avoir de modification à effectuer au niveau du système Debian fournit avec le serveur Kimsufi que j’utilisais à l’époque. En migrant par la suite sur un VPS et en auto-hébergeant certains services à mon domicile, l’envoi de mail avait cessé de fonctionner et j’avais choisi d’ignorer la question jusqu’à la mie 2019, où j’avais réussi à produire une configuration fonctionnelle, en utilisant les serveurs de mail de l’hébergeur. Une nouvelle migration d’Unicoda courant 2020 avait à nouveau rendu l’envoi de mail inopérant. Idem avec la récente migration de ma machine locale.

Afin de continuer de recevoir les notifications liées à l’exécution des sauvegardes journalières de l’ensemble des services, et de bénéficier à nouveau des notifications WordPress, comme celles des nouveaux commentaires, je me suis donc replonger dans les profondeurs de la configuration des services mails sous GNU/Linux, afin de corriger le rôle Ansible responsable de la configuration automatique des services mails.

Voici donc à la suite, le résultat de mes notes de 2019, adaptées et corrigées après les recherches de décembre l’an dernier. J’espère ne pas avoir oublié d’étapes, mais les essais successifs de paramètres différents conduisent parfois à des incohérences, lorsque les notes ne sont pas mises à jour avec les dernières modifications effectuées à l’issue d’une session éreintante de débogage :). Par ailleurs, si mon rôle Ansible a bien été mis à jour, il me reste néanmoins à le tester une nouvelle fois, sur un système vierge, dans l’idéal, afin de garantir son bon fonctionnement. Cela étant dit, voici la configuration qui permet à mes serveurs d’envoyer des mails.

Configuration

Commençons par installer les composants nécessaires:

sudo aptitude install exim4 openssl ca-certificates mailutils

Je modifie ensuite /etc/email-addresses pour lier utilisateurs locaux et adresses mails. Ici, le but est de renvoyer tout vers l’adresse example@unicoda.com (adresse fictive pour l’exemple):

root : example@unicoda.com
monUtilisateur : example@unicoda.com
* : example@unicoda.com

Manipulation similaire, cette fois dans /etc/aliases , puis j’exécute la commande newaliases :

root: monUtilisateur
monUtilisateur : example@unicoda.com

Je modifie ensuite le fichier /etc/exim4/passwd.client, pour y ajouter une ligne contenant les informations de connexion au serveur mail choisi pour l’envoi, de la forme target.mail.server.example:login:password , et lui applique un masque 640 pour les autorisations d’accès.

Avant d’aller plus loin dans la configuration, je m’assure également que mon fichier /etc/hosts contient une ligne faisant pointer le hostname de la machine vers elle-même, soit la ligne 127.0.0.1 hostname. Par ailleurs, je modifie également /etc/mailname pour y ajouter le hostname, cette modification m’ayant été particulièrement utile pour le cas d’un message à destination d’un utilisateur de la machine, soit par exemple root@hostname.

Étape suivante, déploiement du fichier /etc/exim4/exim4.conf.localmacros avec le contenu suivant, pour l’utilisation de TLS et du port 465:

MAIN_TLS_ENABLE = 1
REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS = *
TLS_ON_CONNECT_PORTS = 465
REQUIRE_PROTOCOL = smtps
IGNORE_SMTP_LINE_LENGTH_LIMIT = true

Avant de continuer plus avant, il faut créer un certificat TLS pour exim4, on peut se baser pour cela sur l’étape 4 de ce tutoriel, qui donne la commande à exécuter. De mon côté, j’utilise les modules openssl_privatekey, openssl_csr et openssl_certificate dans ansible pour réaliser ces opérations.

J’apporte quelques modifications au fichier /etc/exim4/update-exim4.conf.conf, correspondant aux étapes 9 et 10 du tutoriel cité ci-dessus, à savoir, l’ajout du bloc suivant, juste avant la ligne .ifdef REMOTE_SMTP_HEADERS_REWRITE (étape 9):

.ifdef REQUIRE_PROTOCOL
  protocol = REQUIRE_PROTOCOL
.endif

Ainsi que le bloc suivant, juste après la ligne (étape 10):

.ifdef TLS_ON_CONNECT_PORTS
  tls_on_connect_ports = TLS_ON_CONNECT_PORTS
.endif

Enfin, édition du fichier /etc/exim4/update-exim4.conf.conf pour spécifier le comportement d’exim4, qui peut également être généré dynamiquement via sudo dpkg-reconfigure exim4-config. À noter, que le mode satellite ne prend pas en considération l’envoi local, et ne tient donc pas compte des alias configurés (comme précisé dans ce message). Pour être complet, je lui ai donc préféré le mode smarthost. J’ai pour ma part changé le dc_readhost par rapport au tutoriel dont je me suis inspiré, qui proposait localhost comme valeur. Je crois me souvenir que localhost ne fonctionnait pas dans mon cas, mais une nouvelle série de tests avec cette configuration ne serait pas inutile pour être fixé.

dc_eximconfig_configtype='smarthost'
dc_other_hostnames=''
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost='unicoda.com'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='target.mail.server.example::465'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

Nous y sommes presque, il suffit à présent de déployer la configuration exim4 via sudo update-exim4.conf, puis de redémarrer le service avec la commande sudo service exim4 restart. On peut ensuite essayer d’envoyer un mail depuis la machine avec echo "test" | mail -s "Test" example@unicoda.com. Si tout va bien, le mail arrive correctement à l’adresse fournie, sinon, il vous faudra, comme moi, parcourir les logs (sudo tail /var/log/exim4/mainlog) pour comprendre la nature du problème de configuration et parcourir les nombreux sujets et documentation autour d’exim4.

Pour finir, avant une liste d’article qui m’avait été utile lors de la configuration, voici encore quelques commandes utiles pour déboguer une configuration exim4 non fonctionnelle.

Commandes

Consulter la liste des messages gelés.

exim4 -bp

Supprimer tous les messages gelés.

exiqgrep -z -i | xargs exim -Mrm

Sources

Pourquoi j’ai migré ma boîte mail

Pendant longtemps, mon adresse mail principale a été gérée par le FAI de la famille; une adresse en @neuf.fr en l’occurrence. J’ai jonglé et jongle encore entre plusieurs adresses mails, en fonction des cas et des besoins. Je crois que j’ai pris conscience de l’importance de l’adresse mail que l’on communique (la principale, pas celle pour le spam), le jour où, en pleine recherche de stage, le serveur mail de mon école d’ingénieur s’est écroulé et est resté inaccessible pendant une petite semaine. Pas terrible, lorsque l’adresse mail qui figure sur votre CV retourne un mail d’erreur technique. On reste heureusement joignable par l’intermédiaire plus traditionnel du téléphone. Bref, dans les deux jours qui suivaient, j’avais changé l’adresse mail de mon CV par mon adresse principale FAI.

Et voilà qu’il y a de cela deux années, la question est revenue sur le devant la table. Après avoir repris le contrôle sur un certain nombre de mes données en hébergeant mes propres services, je me suis tourné vers le problème de l’adresse mail. Il faut savoir qu’en France, une adresse FAI n’est pas immuable. Tant qu’on reste chez ce FAI, pas de problème, mais dès lors que l’on résilie son abonnement, les risques apparaissent. En effet, en cas de résiliation, le fournisseur a l’obligation légale de maintenir l’accès à l’adresse pour une durée de 6 mois. Après 6 mois, la décision de conserver l’adresse mail ou de la supprimer pour pouvoir la réattribuer est à la discrétion de l’opérateur. En règle générale, les pratiques diffèrent donc d’un fournisseur à l’autre, certains garantissent la pérennité de l’adresse sans limite de temps, d’autres avec condition « d’activité » par période de 6 mois. Il est donc préférable d’éviter d’utiliser une adresse mail FAI comme adresse principale de contact, sachant que l’on peut être amené à changer de fournisseur pour l’une ou l’autre raisons.

Se pose également la question de la confiance. Bien évidemment, les mails que nous envoyons transitent en clair sur le réseau, et si les communications peuvent être éventuellement chiffrés entre les serveurs par lesquels le mail passera, celui-ci reste en clair au niveau de chaque serveur le temps d’être transféré vers le serveur suivant. On s’intéresse davantage ici à la confidentialité des données. En clair, dans quelle mesure faisons-nous confiance à l’hébergeur de notre adresse pour que celui-ci ne consulte pas le contenu de nos mails entrants et sortants; comme le fait Google à l’aide d’algorithmes pour proposer de la publicité ciblée dans son interface web ?

Ayant réfléchi à de nombreuses reprises, à l’hébergement de mon propre serveur mail, mais l’ayant toujours repoussé pour divers raisons (relative complexité, gestion du spam, mise en liste blanche de l’IP du serveur, redondance en cas de panne ou d’indisponibilité…), je me suis tourné vers une solution intermédiaire : prendre un nouveau nom de domaine chez un hébergeur proposant une solution mail associée. Ainsi, j’obtiens le premier maillon, le nom de domaine et peux par la suite rediriger les mails vers mon propre serveur. J’ai donc enregistré un nom de domaine chez Gandi puisque leur offre inclut la possibilité de créer 5 boîtes mail pour 1Go d’espace total partagé, redirection, alias, antivirus et anti-spam, avec possibilité de passer sur une offre payante spécifique pour le mail. Cette solution permet également d’envisager si nécessaire, le passage vers une offre payante chez ProtonMail, avec gestion de nom de domaine personnalisé.

Voici quelques points que j’ai noté pour mon changement d’adresse mail :

  • Ne pas se précipiter, prendre son temps. Cela ne sert à rien d’espérer tout changer en quelques jours, il faudra du temps pour s’assurer que nos contacts utilisent notre nouvelle adresse.
  • Migrer progressivement tous les comptes vers la nouvelle adresse. En effectuant la migration sur plusieurs mois, on constate au fur et à mesure quels services ne disposent pas de la nouvelle adresse.
  • Éventuellement et si possible, mettre en place un message de réponse automatique sur l’ancienne adresse pour indiquer le changement d’adresse.

Par ailleurs, ce travail de migration se trouve grandement simplifié lorsqu’on possède déjà la liste de ses comptes dans un Keepass ou équivalent. On connaît alors tous les endroits où le changement d’adresse est à effectuer; mais en contrepartie, toutes les entrées utilisant l’ancienne adresse sont à mettre à jour.

La question essentielle à se poser me semble être : « A qui puis-je faire confiance pour gérer mes mails et dans quelle mesure ? ».

PS: Reste toujours le même problème que si l’un de nos contacts à son adresse chez un fournisseur auquel nous ne faisons pas confiance, celui-ci dispose tout de même d’une copie de nos échanges. (A moins de chiffrer évidemment).

SFR et l’emailing sauvage

Avant de rentrer dans le vif du sujet, laissez-moi introduire le contexte. Il y déjà plusieurs années de cela, j’ai configuré ma première adresse mail FAI en tant qu’adresse bis de contact administratif pour la gestion de la connexion internet de mes parents. Cela n’a pas été plus utile que ça, à part pour suivre l’évolution du montant de la facture de l’abonnement et vérifier l’absence de problème. Je n’avais en revanche jamais pris la peine de remarquer que cette opération avait eu pour effet d’inscrire mon adresse sur la liste publicité pour les nouvelles offres de SFR en matière d’abonnement, etc. Jusqu’à présent, les mails que je recevais finissaient à la corbeille et leur fréquence n’était pas suffisamment haute pour être réellement dérangeante. Jusqu’au mardi 17 mai 2016…

Continuer la lecture de « SFR et l’emailing sauvage »