Gradew

On n’en finit plus, cette fois c’est un nouveau serveur IRC qui vient de voir le jour.

Destiné dans un premier temps à accueillir les visiteurs du site de mon groupe (Parad1gm.net), il s’est vu remanier ses objectifs (un tant soit peu ambitieux, certes). En effet, la petite équipe constituée en un temps assez court se sent d’attaque pour gérer des utilisateurs de tous horizons (langues officielles parlées: français, anglais et allemand… on a laissé tomber le roumain :p Sisi, je vous l’assure, on a eu un canal officiel pour les Roumains, avant que son responsable ne tente un take-over ridicule… :/).

Bref, ce réseau n’a guère l’audace d’oser vouloir se mesurer à d’autres réseaux tels qu’EpiKnet et Undernet, dont les compétences ne sont plus à prouver. Je suis néanmoins agréablement surpris de voir que nous comptons dans l’équipe un ancien administrateur de tchat d’un FAI comptant pour environ 20% des parts de l’internet familial (mmmh, j’hésite à révéler le nom…:p), ou encore admin/modérateur d’un site de scripting bien connu… Bref, une petite équipe assez déjantée, prête à vous accueillir sur ce micro-réseau… disons-le carrément: sympatoche! (/me sifflotte…)

Si ça vous tente de venir y faire un tour, c’est par là:

irc.crystalirc.net:6667 (ou 6697 pour les connexions sécurisées)

Pour info, il s’agit de la dernière version d’Unreal 3 avec les services Anope (Nickserv, Chanserv, etc.).

Vous avez envie de tuer votre eggdrop parce qu’il fait n’importe quoi? C’est normal .

Le rehash du bot suffit en général à résoudre bien des problèmes, sauf dans certains cas comme le changement d’un flag lié à un canal de discussion (+/-enforcebans, par exemple). Les eggdrops ayant la fâcheuse tendance à mettre en cache leurs flags dans le fichier “.chan”, il est en général préférable d’effacer tout simplement ce fichier avant de demander au bot de redémarrer, afin de le forcer à recharger la configuration correctement. Ainsi:

• à partir de votre shell où se trouve l’eggdrop: rm -f <fichier .chan>
• sur IRC: /msg <nom du bot> rehash <mot de passe>

J’héberge depuis peu le site d’une amie graphiste. Son entreprise propose différents types de créations graphiques (plaquettes, jaquettes CD/DVD, encarts publicitaires, logos, etc.). Le travail effectué jusqu’à présent vaut réellement le détour, et pour preuve: elle compte déjà un centre de recherche de l’INRA parmis ses clients. Il est d’ailleurs prévu que Parad1gm fasse appel à ses services pour dessiner le nouveau logo du groupe, ce qui nous évitera de tomber dans tous ces vieux clichés de logos de groupe de métal (le ciel étoilé, la typo manuscrite à la Nightwish…).

Je ne croyais pas ça possible, mais finalement…. ben si: il y a encore plus énervant que de recevoir des e-mails “légitimes” dans son dossier Spam. On peut aussi ne rien recevoir du tout, et il est désormais tout à fait possible que l’expéditeur n’en soit même pas averti.

Ce problème (visiblement à ce jour de plus en plus courant) est dû à une mesure de sécurité qui a été adoptée récemment, notamment par America On Line ou encore Hotmail: les e-mails doivent obligatoirement être envoyé de serveurs de messagerie dont la configuration DNS possède un champ SPF correctement configuré, afin de s’assurer que l’expéditeur du mail est bien légitime (cf. article Wikipedia).

Malheureusement, nombreux sont les hébergeurs de messagerie qui n’ont pas correctement rempli leurs fichiers de zone DNS. Pour illustrer mon propos, voici le rapport d’analyse DNS de l’hébergeur La Poste. On constate que le champ SPF n’est pas complété (du tout!). La conséquence? Eh bien… si “toto@laposte.net” veut envoyer un e-mail à “titi@hotmail.com”, ce dernier ne le recevra jamais, en tout cas en l’état actuel des choses. C’est aussi le cas des solutions d’hébergement mutualisé; ils sont étonnament fort peu nombreux à se soucier la configuration de leurs zones DNS.

Pour ceux qui ont la chance d’avoir leur propre serveur dédié, le problème est très simple à résoudre: la syntaxe SPF étant (très!) obscure, Microsoft met à disposition un outil en ligne de génération de champ SPF.

Par exemple: supposons que vous administriez un serveur de messagerie “mail.exemple.com” dont l’adresse IP est 1.2.3.4. Le champ SPF doit impérativement respecter la syntaxe suivante:

v=spf1 a mx ptr ip4:1.2.3.4 mx:mail.exemple.com ~all

Un petit /etc/init.d/bind9 restart, et le tour est joué!!! Votre serveur sera désormais considéré comme “légitime” auprès des hébergeurs effectuant cette vérification.