🚲 Tanguy Ortolo a écrit 12224 commentaires

paris. aussi. Et avec une justification débile de la part de la mairie :

Comme ça on va pouvoir vendre des noms de domaines en .paris.

Genre vous ne pouvez pas déjà en vendre en .paris.fr, quoi…

Je ne vois pas le rapport. Le sujet courant, c'est l'étude des dossiers, la facturation et la délégation d'un peu moins de deux mille noms de domaines.

(et oui, ce genre de travail, ça peut être fait par trois gus dans un garage)

Tu vis vraiment dans un autre monde…

Oui, le même monde que celui où un simple chercheur du CERN peut monter sur un coin de bureau une architecture de publication d'information qui deviendra mondialement connue et utilisée. Pendant qu'en face, d'autres peuvent dépenser pas mal d'argent pour imaginer et concevoir des trucs compliqués comme Xanadu.

Développer l'idée, monter les dossiers,

Bah, un an de travail à quelques personnes, si on veut vraiment se prendre la tête…

discuter avec les différents acteurs,

Quels acteurs ? Les propriétaires des serveurs racines ?

mettre en place les processus,

Rien à faire, les processus sont déjà là.pour l'insertion de nouveaux noms de haut niveau.

évaluer l'impact,

Bah, une analyse d'impact ça ne va pas coûter des millions non plus.

décrire les processus

Rédiger de la documentation ? Bah, pas plus cher que la même chose chez n'importe quel bureau d'enregistrement…

Tout ce que je sais, c'est que, propriétaire d'un nom de domaine (. dans le cas de l'ICANN, ortolo.eu dans mon cas), il est très facile de monter une architecture pour vendre et déléguer des noms de domaines dessous. Après si on veut se prendre la tête avec la bureaucratie… L'architecture de l'AFNIC, registre pour le nom de domaine fr, qui délègue la vente à des tas de bureaux d'enregistrement, n'a sûrement pas coûté vingt millions. Et pourtant, elle est plus complexe que celle de l'ICANN pour la délégation de noms sous . puisqu'elle passe par des intermédiaires et traite beaucoup plus de délégations.

Disons que personnellement, je serais en mesure de monter le même service pour un investissement initial de l'ordre de la centaine de milliers d'euros en comptant très large.

Le serveurs racine sont déjà là, rien à changer de leur côté. Ajouter un nom de domaine, c'est ajouter une ligne au fichier de zone sur chaque serveur, ça se fait déjà pour chaque nouveau TLD, rien à changer non plus de ce côté-là.

Il faut pouvoir étudier chaque dossier. Disons deux mille par an : il suffit d'employer une dizaine de personnes à temps plein pour en traiter un par jour-homme. Au prix du dossier, pas de problème pour payer ces employés.

Quoi d'autre ? Ah, oui, un site marchand d'immatériel à développer. Un serveur pour ce site, capable de tenir la charge pour quelques milliers de commandes par an (waouh !) : pour un telle demande on peut même économiser en recyclant une machine d'il y a vingt ans.

Ah, il faut aussi pouvoir fournir des factures. Bah, vu la demande, on peut carrément les faire à la main…

Ou utiliser l'adresse suivante pour son moteur de recherche Web préféré : http://dot/

À la fin de l'article d'Écrans :
> S’ajoute à cela le coût du développement de ce vaste programme d’extensions personnalisées (20 millions de dollars) et de la surveillance permanente du respect des engagements des candidats retenus.

Suis-je le seul que cela choque ? Vingt millions de dollars pour développer un simple bureau d'enregistrement de nom de domaine comme il y en a des milliers ? Ils paient leurs employés avec leur poids en or, l'ICANN ?

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.