CransWiki:

Réunion du Collège Technique

Présent⋅es

Ordre du jour

Trucs à pas oublier :

Dovecot sieve / Procmail

Possibilité de définir un sieve par utilisateur ?

"Est-ce qu'on utilise Dovecot au Crans ?" --> Après recherches, oui, mais "il est planqué où ?" [Ça se voit que l'IN manque de gens là ?]

Pigeon a trouvé, victoire ! "/etc/dovecot/conf.d/90-sieve.conf"

Conclusion :

On remarquera que le compte rendu n'est pas linéaire car certains points ont été abordés plusieurs fois

Point DSI

Les comptes non ENS ne fonctionnent pas sur eduroam.

Hachino s'en charge. Un jour, insh'. 2ème étage, couloir 2[A-Z]82 d'après GaBo et Pigeon.

L'espoir est très très mince. :(

Point Regex

À l'aide

Point SCP (à l'intérieur du point Quill)

Après avoir bifurqué sur Quill, Pigeon en arrive à une murder SCP qu'il écrit avec Charsle. Korenst1 est perdu par ce qu'est SCP.

S'ensuit une explication succincte de Pigeon.

Framadate

Pigeon vient de le vérifier : le bouton "Ajouter un commentaire" est un mensonge.

Personne ne sait où sont les logs de framadate, on remet le point à la prochaine IN.

Les autres points

Il manque les gens qui les ont ajoutés à l'ODJ. Derp. Ce sera pour l'IN de décembre. Bon allez, on essaye quand même.

Point Pass

Pigeon explique le principe de GPG et de Pass.

Puis bleizi arrive, c'est un miracle !

Points messages de Pigeon

Réplication BDD gitlab

On backup certains trucs de gitlab mais pas sa BDD. Elle n'est backup que pendant les MAJ gitlab (~1 fois/mois), il faudrait le faire automatiquement.

Gitlab est un énorme pâté qui installe tout seul les paquets dont il a besoin (et possiblement sa BDD).

On attend shirenn pour voir ça.

Comptes non contactables

On refuse de regarder le .forward des gens.

Possibilité : envoyer un mail aux gens "hey, ton compte semble inactif, si tu réponds pas d'ici X mois [X entre 1 et 6], on va l'archiver". Rien d'urgent ceci dit.

Signature DKIM

Signature faite par le serveur mail (redisdead au crans).

Les mails envoyés par Re2o ne sont pas signés par DKIM, donc en principe "suspects" (mais mieux vaut pas signés que mal signés).

Peut-être qu'un jour les Gafam (Gmail en tête) vont mettre en place des politiques plus strictes et les mails pas signés DKIM partiront par défaut en spam. Gênant. Pour l'instant c'est pas le cas. Sont concernés notamment les mailall annuels et les mails de confirmation d'inscription.

Les mails ne sont pas signés DKIM quand ça passe par Redisdead et faudrait enquêter pour savoir pourquoi. Gitlab envoie des mails signés DKIM, Owncloud non (mais franchement, pour OC on s'en tape).

Personne de présent n'est volontaire pour regarder ça en profondeur. bleizi propose la bouteille à la mer sur #roots (aled).

Retour de la bouteille à la mer post réunion :

Mails Zamok -> Redisdead

Quand un mail arrive pour le Crans, il passe par Redisdead, normal. Puis ça passe par Zamok, qui stocke les mails des gens. Dans certains cas, les gens ont des .forward vers une adresse extérieure (serveur perso, Gmail, ça dépend). Ça fait beaucoup d'allers-retours. bleizi a oublié la conclusion de la réflexion, mais ça a l'air sous-optimal. C'est bien noté.

Un des soucis : les headers s'empilent à chaque redirection.

L'idée serait de faire en sorte que Redisdead, plutôt que Zamok, lise le .forward des gens.

Crans OID

Le nom n'est pas le bon sur le lien (Stéphane Glondu, wouhou). Tout le monde s'en tape, GG.

En fait non, bleizi réfléchie à changer les infos, mais il faudrait voir qui reçoit les mail sur oid-admin@crans.org

Point 'hosts'

La génération du DNS est faite en regardant le LDAP et tous les trucs du LDAP sont dans ou=hosts.

Point SPF

SPF = Standard policy framework. Sert à faire de la sécurité sur les mails.

Principe : vérifier que le Mail From et le serveur qui envoie le mail sont les mêmes. Il paraît que les usurpations c'est pas bien.

On peut donner au DNS (par le LDAP) la liste des serveurs qui ont le droit d'envoyer des mails au nom du Crans. À la fin tu peux mettre un "All" pour dire que tout le monde a le droit, un "-All" pour nier le droit et un "~All" pour dire "c'est pas normal, mais on laisse passer quand même".

Pigeon trouve un "~All" dans un champ txt. Les seuls serveurs enregistrés pour le Crans sont Redisdead et Soputnik, mais pas Zamok. Dans le txt, il y a deux IPv4 et deux IPv6 (on suppose que c'est Redisdead et Sputnik). Les MX sont bien eux.

Si on lit les headers d'un mail récent du Crans, genre celui que Pigeon envoie exprès à bleizi dans la minute, on peut s'apercevoir qu'il s'agit d'un mail de Q. De qanon@crans.org, pardon. Quand c'est signé DKIM, on lit pas les SPF parce qu'on fait confiance.

bleizi poste un exemple d'analyse SPF venant de chez shirenn.

Authentication-Results: redisdead; spf=softfail (domain owner discourages use of this host) smtp.mailfrom=gmail.com (client-ip=REDACTED; helo=abys.se; envelope-from=shirenn@gmail.com; receiver=<UNKNOWN>)

Proposition de nouvelle politique : si fail (hardfail, pas softfail), alors drop le mail. Est-ce qu'on veut implémenter ça ? Débat. L'idéal serait de laisser passer le mail en informant les destinataires, mais

Par défaut, on laissera passer les mails quand même. Plus tard, quand SPF sera plus répandu et/ou que les Gafam imposeront leur loi, peut-être qu'on changera d'avis.

Pigeon et Aplanos proposent de ressusciter la Stasi en censurant a priori tous les mails. La motion est rejetée à l'unanimité.

Hosts.crans.org

Ça héberge un Django en debug. Personne ne sait ce qu'il devrait y avoir à la place. Un ssh fait tomber sur Hodaur, mais c'est normal. On demandera à de vieilles nounous si elles savent. Il est probable que ce site ne serve à rien.


CransWiki: ComptesRendusCrans/Samedi02Decembre2023 (dernière édition le 2023-12-04 12:01:43 par DsAc)