🚲 Tanguy Ortolo a écrit 12367 commentaires

Gné ? Il n'y a pas de différence fondamentale entre pharmacy.com. et pharmacy.. Dans le premier cas, le registre c'est VeriSign (gestionnaire de com.) et le bureau d'enregistrement, n'importe quelle entreprise à laquelle VeriSign délègue le boulot. Dans le second cas, le registre c'est l'ICANN (gestionnaire de .) et le bureau d'enregistrement c'est probablement l'ICANN directement aussi.

Dans le deux cas, tu dépends de quelqu'un. Dans le deux cas, il peut te retirer ton nom de domaine. Dans les deux cas, tu peux déléguer des zones à ta guise.

Bof, pas de quoi fouetter un chat, à mon avis. Je propose une autre lecture de l'événement : des investisseurs japonais ont décidé d'investir de l'argent en France. Autrement dit, on a créé une entreprise en France, et ça permet de faire venir de l'argent du Japon vers la France.

Par ailleurs, si cet investisseur japonais peut faire cela, c'est parce que les propriétaires français de la boîte en question sont d'accord. Et s'ils sont d'accord, tant mieux, on n'a rien à y redire. Quand aux salariés, si ça ne leur plaît pas ils peuvent recommencer ailleurs, ils ne sont pas obligés de rester.

Quid du contrôle de la revente aux spammeurs avec leur botnets type "pharmacy" qui sont hébergés sur des domaines générés automatiquement ?

Bah, le propriétaire actuel de pharmacy.com peut déjà faire de même, et je ne crois pas que ça pose problème…

Depuis quelques mois je suis utilisateur de vélos en libre service. Je vous le conseille vivement si vous vivez dans une ville qui dispose d'un de ces systèmes. Se déplacer et dépasser les autos c'est particulièrement réjouissant.

Aucun rapport. Je confirme que se déplacer et dépasser les voitures c'est réjouissant, mais ça n'a rien à voir avec le fait que la ville dispose ou non d'un réseau de location de vélo. On peut faire pareil, depuis un siècle, en mieux, dans n'importe quelle ville, en achetant son propre vélo…

Ceci dit, y a pas la 3G ?

Il y a probablement, mais c'est payant et indépendant du salon. Je trouve surprenant qu'un tel salon ne fournisse pas, en plus du courant électrique, une connexion filaire pour les stands des exposants.

Pour m'y être rendu, je confirme :

• que Linagora ne participe pas ;
• que Microsoft et SUSE sont très visibles, comme sponsors d'honneur, avec leur nom en plus gros que tout le monde ;
• que le salon est en déclin, avec moins d'exposants, une surface moins grande qu'avant, aucun accès à Internet — même pour les exposants — sauf à payer pour un identifiant wifi, et aucun service spécifique aux exposants — les années passées il y avait un genre de café.

'taing, je ne m'étais jamais rendu compte que le nom « Borg » pouvait venir de « cyborg »… Merci de m'ouvrir les yeux !

Cette solution acceptable à tes yeux car du fait de l'hébergement amateur.
Elle ne l'est pas à mes yeux (je fais aussi de l'amateur, mais j'ai choisi de le faire bien).

Bon, donc si je comprends bien je suis un amateur qui fait de la merde. Merci, j'apprécie le compliment. Maintenant, si ça ne te dérange pas, je te laisse avec tes multiples serveurs de courrier à configurer, j'ai autre chose à faire, moi.

Ça, c'est très, très con, pour une raison toute simple : ne pas avoir de nom DNS, ce n'est pas la faute de l'administrateur du serveur mais de son FAI. Suspecter quelqu'un d'être un spammeur parce que son FAI ne lui fournit pas de nom DNS inverse correct n'est pas raisonnable.

Là, tu as des statistiques en IPv4, je parie. Et en IPv6, ça donnerait quoi ? Combien de faux positifs en IPv6 ? Je penche pour plus de 50%.

Ah et j'oubliais une chose … "En jouant avec les DNS" … mais LOL quoi … t'as entendu parler du temps de propagation DNS ?

Ça se règle ça.

Par exemple, sur ton domaine, le TTL pour les enregistrements MX est de 86400…

Par exemple, tu l'as réglé à une valeur moins délirante. Genre trois heures.

Donc le MX2 n'a qu'à (au choix):
1/ Répliqué la base de données.
2/ Faire un dump dans un fichier plat toutes les XX minutes.

Y'a qu'à, évidemment. C'est un tout petit peu contraignant comme procédure, même en évitant la complexité généralement inutile d'une base MySQL et en choisissant de simples fichiers à la place. Surtout face à la solution alternative tout à fait acceptable qui consiste à ne pas avoir de MX secondaire.

Effectivement, si on utilise des services lambda de backup de MX, alors oui, ça se fait pas simplement. Mais en s'arrangeant avec d'autres auto-hébergés, pas de soucis ma bonne dame!

Va trouver un autre auto-hébergé prêt à mettre en place un serveur rsync en écriture pour que tu lui envoie ta base de données et qu'il la remonte régulièrement. Bonne chance.

Après, c'est sûr que si on prend la problématique de l'hébergement par dessus la jambe, alors on peut s'affranchir de MX2, mettre son MX principal sur une ligne 56k, etc…

Si ce que tu as chez toi, c'est une connexion 56 kb/s, alors oui, c'est suffisant pour héberger ton serveur de courrier. Pour une raison très simple :

• sans auto-hébergement, tu récupères à 56 kb/s ton courrier sur cette connexion quand tu te connectes à ton serveur externe de boîtes aux lettres ;
• avec auto-hébergement, ton courrier arrive directement à 56 kb/s sur cette connexion quand on l'envoie à ton serveur.

Si ça passe dans le premier cas, ça passe dans le second. CQFD.

Ainsi si ton MX primaire est cassé, le secondaire (qui DOIT être un autre serveur) réceptionnera l'email en attendant que le primaire revienne à la vie.

Aucun intérêt. Les serveurs expéditeurs le feraient de toute façon, en réessayant périodiquement pendant cinq jours.

Les arguments avancés dans ton post de blog sont absolument farfelus et sans fondements.

Non.

Oui, avoir plusieurs MX distincts présentent quelques difficultés supplémentaires concernant la lutte antispam… et alors ????

Et alors c'est un argument, qui n'est ni farfelu ni sans fondement.

Plutôt que de te creuser la tête et de solutionner ces problèmes, tu préfères faire l'impasse sur un MX2 en prétendant qu'il est inutile … foutaises!

Non. Il fait l'impasse sur un second MX parce que, sauf dans les deux cas précis qu'il mentionne à la fin, il est inutile.

Comme d'habitude, merci pour ces analyses et cette vulgarisation de RFC !

Une petite nimage de circonstance :

/dev/mapper/vg1-vl2

En français, on dit un groupe de volumes, et un volume logique. En anglais, on dit a volume group et a logical volume. Donc ton nommage est incohérent, il faudrait choisir entre le français gv1-vl2 et l'anglais vg1-lv2.

Accessoirement, je trouve dommage de nommer tes volumes logiques avec des numéros plutôt que de leur donner des noms logiques puisque c'est possible. En général je recommande de nommer les groupes de volumes avec le nom de la machine — pour ne pas avoir de conflit si on les branche sur une autre machine — et de nommer les volumes logiques selon leur fonction — ici, home.

Tu achètes donc pour 2000€ d'actions Nakoi (célèbre fabricant de téléphones).

D'actions tout juste émises alors. Parce que s'il s'agit de racheter des actions existantes, ce qui se fait le plus couramment en bourse, ça ne changera strictement rien à la société en question.

ils semblent dirent que en 2010 c'était deja fait pour le client web

Ça, c'est faux. Pour avoir essayé, je vous assure que le client Flash pour Google Talk utilise le vieux Jingle.

De toute manière 99% des clients qui supportent jingle utilisent libjingle

Source ? Gajim ne l'utilise pas, ou alors mal, c'est totalement incompatible avec Google Talk en face par exemple.

C'est un peu à côté de la plaque. SIP n'est pas intégrable avec un LDAP à utilisateurs/mots de passe. Il est intégrable avec un LDAP à certificats X.509 en effet, mais c'est drôlement contraignant comme contournement…

La norme SIP, inspirée d'HTTP, utilise les mêmes mécanismes d'identification. Elle a été mise à jour pour interdire le mécanisme d'identification basic d'envoi direct de mot de passe et n'autoriser que le mécanisme de défi-réponse digest.

Comme digest est un système à défi-réponse, il implique un stockage du mot de passe (ou de quelque chose qui joue le rôle du mot de passe) en clair sur le serveur. C'est incompatible avec les mots de passes stockés en hachage dans un LDAP.

Sauf que XMPP, ça peut s'intégrer avec, disons, un LDAP d'entreprise. SIP non.

Ah, avec Empathy, peut-être bien, c'est vrai que je n'ai pas essayé (trop contraignant comme client Jabber, avec son système Mission Control qui démarre des trucs en arrière plan, à peu près inutilisable sans Network Manager…).

Pas avec un Google Talk en face.

C'est une bonne idée en théorie. En pratique, Google Talk ne permet d'utiliser de la voix et de la vidéo que depuis leur client Flash, et ils utilisent une ancienne version non standard de Jingle, version qui est incompatible avec les mises en œuvre standard. Le seul logiciel que j'ai trouvé qui interopère avec Google Talk, c'est Jitsi.

Il y a des ordinateurs tatoués, quoique je n'en aie jamais vu. Mais il y a aussi d'autres choses qui peuvent passer pour un tatouage alors que ce sont juste des cartes mères mal fichues.

Par exemple, certains BIOS refusent de démarrer depuis un périphérique dont le MBR n'a pas une partition marquée « active ». C'est stupide, parce que cet indicateur historique n'est plus du tout utilisé — il est d'ailleurs interdit par le système de partitionnement GPT — et n'a a priori rien à voir avec le code de démarrage qui est situé ailleurs dans le MBR. En revanche, après avoir installé un système d'exploitation différent que celui fourni avec la machine, se prendre un « invalid boot sector » au démarrage, ça peut donner l'impression qu'on est face à un tournedows …

KDE ou Xfce alors…

Le système de ppa a, je pense, fait énormément de bien pour ça

Euh, Ubuntu n'ont pas inventé les dépôts APT perso, hein.