![[ICO]](/icons/blank.gif){kind=icon}
![[PARENTDIR]](/icons/back.gif){kind=icon}
Palaiseau, le vendredi 9 juillet 2021
Cher Journal,
Avec l'achat du domaine emlwks999.eu, je peux désormais régler le MX, et toute autre entrée de DNS relative au courriel, comme bon me semble. J'ai passé un bon bout de temps à passer un peu en revue les réglages possibles ; et j'ai laissé filer encore un peu plus de temps pour laisser tourner la nouvelle adresse sur les listes de diffusion, pour voir comment le montage se comporte.
D'après le relai DNS de ma box :
$ dig ANY emlwks999.eu ; <<>> DiG 9.16.15-Debian <<>> ANY emlwks999.eu ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58437 ;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;emlwks999.eu. IN ANY ;; ANSWER SECTION: emlwks999.eu. 86400 IN A 82.64.73.247 emlwks999.eu. 10800 IN NS ns-240-a.gandi.net. emlwks999.eu. 10800 IN NS ns-39-b.gandi.net. emlwks999.eu. 10800 IN NS ns-150-c.gandi.net. emlwks999.eu. 86400 IN SOA ns1.gandi.net. hostmaster.gandi.net. 1623574137 10800 3600 604800 10800 emlwks999.eu. 10800 IN MX 10 mx.mailo.com. emlwks999.eu. 10800 IN TXT "v=spf1 a include:mailo.com -all" emlwks999.eu. 10800 IN AAAA 2a01:e0a:d:3b30:b62e:99ff:fec1:90be ;; Query time: 12 msec ;; SERVER: 192.168.1.254#53(192.168.1.254) ;; WHEN: Tue Jun 15 23:36:30 CEST 2021 ;; MSG SIZE rcvd: 285
J'ai laissé le TTL à trois heures (10800 s) pour le moment. Je le monterais à une journée complète quand je considèrerais ma configuration comme stable, à l'exception notable de l'adresse IPv6, que je préfère être capable de changer rapidement en cas d'imprévus. Je ne pense pas maîtriser la pile IPv6 autant que j'ai pu être exposé à l'IPv4, mais j'ai vaguement compris que, pour mon IPv6 sans extension de vie privée, il s'agit plus ou moins de la concaténation du réseau que m'a attribué mon fournisseur d'accès, ici 2a01:e0a:d:3b30::/64, et de l'adresse MAC de ma carte réseau, avec un peu de bruit en complément, pour remplir les 64 bits restants, soit b62e:99ff:fec1:90be
On voit la configuration SPF demandée par mon fournisseur de mail, mais la configuration DMARC qu'il me suggère n'y apparait pas, en fait elle est dans le champ « texte » d'un sous domaine dédié :
$ dig TXT _dmarc.emlwks999.eu ; <<>> DiG 9.16.15-Debian <<>> TXT _dmarc.emlwks999.eu ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17733 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;_dmarc.emlwks999.eu. IN TXT ;; ANSWER SECTION: _dmarc.emlwks999.eu. 10800 IN TXT "v=DMARC1; p=quarantine;" ;; Query time: 40 msec ;; SERVER: 192.168.1.254#53(192.168.1.254) ;; WHEN: Tue Jun 15 23:46:43 CEST 2021 ;; MSG SIZE rcvd: 84
La question qui me taraude est la différence effective entre p=none et p=quarantine. Les documents sur lesquels je tombe ont soit un focus sur none et reject, soit mentionnent rapidement que le mode de quarantaine permet de d'obtenir des rapports détaillés, mais auquel cas il faut accompagner le champs d'une adresse pour recevoir lesdits rapports. Concrètement, pour l'instant, tout ce que je constate, c'est que les spams arrivent avec pas mal de retard, et qu'ils sont marqués comme tels dans leur sujet, ce qui soit dit en passant, ne me change pas du comportement avant changement d'adresse.
Pour ce qui est de la partie DKIM non vérifiée, j'ai suffisamment de bounces sur la liste Alioth debian-science-maintainers, pour que je me fasse régulièrement éjecter de la liste de diffusion ; la signature automatique en fin de message y est probablement pour quelque chose dans l'invalidation de DKIM. Ce problème était déjà présent avant que je m'abonne avec mon adresse emlwks999, mais avec mes bricolages, j'ai maintenant une idée assez précise de ce qu'il se passe sous le capot.
Pour repérer toutes les occurrences à l'ancien nom de domaine sur mon site web, je ne vais pas chercher plus loin qu'un bête grep récursif :
$ grep -RF emlwks999.hd.free.fr public_html/
Je n'ai pas affiché le résultat ; il y a du monde. Je n'ai pas lancé de sed --in-place, parce que dans de nombreux cas, le nom de domaine est utilisé dans le contenu de l'article. Je préfère donc l'y garder à fins de cohérence. La plupart des occurrences qui nécessitaient d´être changées ont pu être remplacées par une absence complète de nom de machine, notamment dans les cas de lien comprenant l'URL complète, type <a href="https://emlwks999.hd.free.fr/example">.
En grattant dans les articles, j'ai pu également réaliser que je devais mettre à jour le nom de la machine pour le mécanisme de fédération IRC, mis en place le 19 juillet 2019.
La partie SSL avec Let's Encrypt a été réglée le mois dernier. J'ai ajouté une redirection permanente vers le nouveau nom de domaine depuis l'ancien, d'une part pour m'aider à l'adopter, vu que mon historique me sort à tour de bras mes liens avec l'ancien nom de domaine, et d'autre part il parait que ça améliore le référencement. Mais est-ce que je veux être bien référencé, seulement ? Ma réponse pour le moment serait : probablement pas…
Techniquement parlant, je me suis un peu gratté la tête avec la redirection depuis l'ancien domaine. D'après la documentation du mod_alias, le premier champ prend un chemin absolu, mais pas une URL avec le protocole, du coup, en grattant dans la documentation, j'ai réalisé que je devais plutôt passer par une expression conditionnelle. Le résultat est à peu de choses près un copier/coller du premier exemple d'expression conditionnelle de la documentation :
# […]
<If "%{HTTP_HOST} == 'emlwks999.hd.free.fr'">
Redirect permanent "/" "https://emlwks999.eu/"
</If>
# […]
La redirection est permanente, je n'ai pas l'intention de revenir en arrière désormais, même si certaines middlebox refusent de transmettre mes pages web au prétexte que mon nom de domaine est trop neuf.
J'ai utilisé l'option --edit-key du programme gpg pour modifier les informations. Il est également possible d'aller plus vite avec --quick-add-uid, mais je voulais voir ce que je faisais :
$ gpg --edit-key '8F91 B227 C7D6 F2B1 948C 8236 793C F67E 8F0D 11DA'
gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec rsa4096/793CF67E8F0D11DA
created: 2020-06-30 expires: 2022-03-14 usage: SC
trust: ultimate validity: ultimate
ssb rsa4096/647A5EE1553D3462
created: 2020-06-30 expires: 2022-03-14 usage: E
[ultimate] (1). Étienne Mollier <etienne.mollier@mailoo.org>
gpg> adduid
Real name: Étienne Mollier
Email address: emollier@emlwks999.eu
Comment:
You are using the 'utf-8' character set.
You selected this USER-ID:
"Étienne Mollier <emollier@emlwks999.eu>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
sec rsa4096/793CF67E8F0D11DA
created: 2020-06-30 expires: 2022-03-14 usage: SC
trust: ultimate validity: ultimate
ssb rsa4096/647A5EE1553D3462
created: 2020-06-30 expires: 2022-03-14 usage: E
[ultimate] (1) Étienne Mollier <etienne.mollier@mailoo.org>
[ unknown] (2). Étienne Mollier <emollier@emlwks999.eu>
gpg> save
Pas d'inquiétude à avoir pour le niveau de confiance inconnu de la nouvelle adresse, le niveau ultime est pris en compte après sauvegardes des informations :
$ gpg --list-secret-keys
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 2 signed: 1 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: depth: 1 valid: 1 signed: 84 trust: 1-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2021-06-25
/home/emollier/.gnupg/pubring.kbx
---------------------------------
sec rsa3072 2018-03-20 [SC] [expired: 2021-03-14]
5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D
uid [ expired] Étienne Mollier <etienne.mollier@mailoo.org>
sec rsa4096 2020-06-30 [SC] [expires: 2022-03-14]
8F91 B227 C7D6 F2B1 948C 8236 793C F67E 8F0D 11DA
uid [ultimate] Étienne Mollier <emollier@emlwks999.eu>
uid [ultimate] Étienne Mollier <etienne.mollier@mailoo.org>
ssb rsa4096 2020-06-30 [E] [expires: 2022-03-14]
Il me reste à pousser les informations sur les serveurs sur lesquels j'ai publié ma clé :
$ gpg --keyserver hkps://keys.openpgp.org --send-keys '8F91 B227 C7D6 F2B1 948C 8236 793C F67E 8F0D 11DA' gpg: sending key 793CF67E8F0D11DA to hkps://keys.openpgp.org $ gpg --keyserver hkps://keyserver.ubuntu.com --send-keys '8F91 B227 C7D6 F2B1 948C 8236 793C F67E 8F0D 11DA' gpg: sending key 793CF67E8F0D11DA to hkps://keyserver.ubuntu.com $ gpg --keyserver hkps://keyring.debian.org --send-keys '8F91 B227 C7D6 F2B1 948C 8236 793C F67E 8F0D 11DA' gpg: sending key 793CF67E8F0D11DA to hkps://keyring.debian.org $ gpg --armor --export '8F91 B227 C7D6 F2B1 948C 8236 793C F67E 8F0D 11DA' > ~/public_html/whoami/emollier_public_key.asc
Note : le serveur de clés du projet Debian est réservé aux membres du projet. Pour le moment, pour y bootstraper l'envoi de clés, il faut effectuer un envoi vers le serveur de Canonical, et puis suivre la procédure pour devenir au choix Mainteneur ou Développeur Debian. Autrement, la dernière commande pousse la partie publique de la clé à l'endroit qui va bien pour distribution par mon serveur web.
Note supplémentaire : je pense que hkps://keys.gnupg.net est désormais hors service. Il ne fallait déjà plus s'en servir suite d'incidents, type déni de service, liés à une vulnérabilité dans le protocole de distribution des clés, en 2019.
Maintenant que j'ai une flotte d'adresses de courrier à gérer, il a fallu que fasse une petite pause et que je repense ma configuration. Jusqu'à présent, j'envoyais mes courriels avec un champ From: etienne.mollier@mailoo.org par défaut. J'avais des commandes alternatives pour me connecter en IMAP sur mes adresses, qui allaient récupérer une configuration alternative qui surchargeait certains champs. Cette fois je pense faire les choses différemment. Mutt est capable de réinjecter les valeurs des variables de configuration dans d'autres telles variables, et les variables d'environnement sont prises en charge. Du coup, je peux réutiliser des éléments comme le realname, ma variable EMAIL, éventuellement DEBEMAIL, si je devais le régler différemment dans un avenir très proche.
Je garde les détails pour plus tard, il se peut que je fasse encore quelque changements par rapport à ma configuration actuelle.
Je pense que l'aspect qui va m'occuper encore un petit bout de temps va être de retrouver mes petits dans l'ensemble des listes de diffusion sur lesquelles je suis inscrit avec etienne.mollier@mailoo.org, d'autant plus que je risque fort de tenter d'envoyer des réponses depuis la mauvaise adresse. D'autre part, étant donné que le SPF, DKIM et DMARC sont actifs, les interactions avec lesdites listes de diffusion risquent d'être sport, si j'en crois ce que j'ai pu lire sur Wikipedia, et sur le journal de Stéphane Bortzmeyer sur le sujet. Ceci étant, mon premier test sur la liste de diffusion debian-user-french@lists.debian.org a été concluant. J'ai pu m'y inscrire, y recevoir des messages, en envoyer un, recevoir le retour : j'ai pu en désinscrire mon adresse usuelle. Les anciennes listes, issue de Alioth, risquent d'être un peu plus sport de ce point de vue là, notamment avec la mise en place de DKIM et DMARC ; mais l'expérience m'a montré que c'est déjà un problème.
Et comme si ça ne suffisait pas, je suis désormais joignable sur emollier@debian.org pour toute discussion ayant trait au projet Debian ou à des problèmes d'empaquetage.
| Name | Last modified | Size |
|---|---|---|---|
| Parent Directory | - |