[OSM-talk-fr] Doublon de mail Was: Edition des relations pour les transports en commun > (ville de Nantes) (JeanMichel FRANCOIS)

Philippe Verdy verdy_p at wanadoo.fr
Mar 22 Juil 00:44:10 UTC 2014


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.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20140722/4e61425e/attachment.htm>


Plus d'informations sur la liste de diffusion Talk-fr