C'est tout de même dommage qu'une société qui se dit experte en solutions de "déploiement agile" ne sache pas configurer correctement une solution mail nécessaire à n'importe quel site hébergé pour ses clients et au moins isoler le système défaillant après plus d'une semaine.
On peut admettre un problème technique temporaire survenant un week-end et qui persiste encore quelques heures le lundi matin, mais si leur système est défaillant et nécessite du temps à être corrigé, il devrait avoir un système alternatif de secours pour prendre le relais (quitte à passer par un fournisseur tiers, en reconfigurant temporairement la déclaration MX de leur domaine). Cependant Jean-Michel apparaît comme faisant bien partie de cette société en tant que chef de projet web (l'abeille en haut à droite de la ruche visible sur http://makina-corpus.com/equipe) et c'est dans ses responsabilités de trouver qui chez lui réglera le problème même s'il ne le règle pas lui-même (s'il n'a pas directement la main ou la compétence pour administrer lui-même directement les serveurs installés). En revanche pour faire ses tests d'envoi, il ne devrait pas le faire en envoyant des messages à cette liste, mais en créant une liste à lui dont il contrôle les adresses de réception des destinataires (et il peut créer des utilisateurs tests chez divers fournisseurs tiers parmi les plus courants pour former sa liste de test, et en hébergeant sa liste privée aussi à l'extérieur, car les listes hébergées chez-lui dans son propre domaine n'ont peut-être pas ce problème). ---- Le dédoublonnage en tenant compte uniquement du "Message-ID:" d'origine (tout en bas des entêtes) n'est pas très fiable car très facilement "spoofable" par un tiers malveillant (qui utiliserait cela pour bloquer des messages légitimes en parvenant à envoyer un autre email quelconque utilisant le même Message-ID, avant le message original; ce qui est possible durant le temps de transit entre les différents serveurs, quelquechose qui est déjà exploité pour bloquer des alertes de sécurité sur un système attaqué et même polluer des listes de diffusion en s'insérant à la place des messages légitimes qui sont, eux, éliminés comme prétendus "doublons"). Le "spoofing" malveillant des entêtes MIME est aujourd'hui utilisé à des échelles industrielles dans les emails non sécurisés. Ce n'est fiable que si le message d'origine a une empreinte numérique sécurisée de son auteur et l'empreinte est calculée non seulement sur le contenu mais aussi ce Message-ID, son auteur, et une date assez précise (dans ce cas un message signé a priorité sur tout autre non signé qui aurait pu être émis avant et ne doit pas être bloqué). On peut comprendre qu'il soit nécessaire d'abord de vérifier le début des entêtes et la chaîne de transmission entre les domaines entrants et sortants, et les relations d'approbation interdomaines pour pouvoir ensuite utiliser les entêtes suivants. Et ici c'est le cas en utilisant non pas le Message-ID en bas, mais le champ "id" d'un des premiers entêtes "Received: from" dont il est possible de contrôler l'authenticité de l'émetteur (et ici c'est suffisant pour prouver que c'est un doublon, mais cela nécessite d'avoir un cache des derniers "id" reçus d'un domaine à contrôler et en bloquer les tentatives d'envois en doublon). Un tel filtrage devrait possible en amont de cette liste et doit exister dans ses propres filtres (la certification des entêtes existe dans des solutions dévelpopées pour SpamCop, on peut interroger les auteurs de SpamAssassin ou autres outils similaires, s'ils ont développé et intégré ce genre de test contre des doublons inattendus causés par des anomalies de réglages sur des serveurs de messagerie tiers et qui ne sont pas volontaires, pour éviter de tout bloquer à 100% mais garder la partie utile, celle du premier message authentique.
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
