Le Thu, Dec 07, 2017 at 12:52:44PM +0100, Julien Escario a écrit:
Je vois assez bien l'intérêt côté client: configurer tous tes potes avec "smtp.domain.tld" (avec auth) et "imap.domain.tld", te permet de changer de FSI plus facilement que si tu utilises smtp.fsi.tld et imap.fsi.tld, qui t'oblige à passer sur tous tes postes clients pour la moindre modif...
Bah voilà, c'est l'idée.
A part que ce n'est pas possible pour le moment, au vu de la diversité des clients mails, ou alors il faut partir du principe que tu n'en supportes que quelques-uns.
(Evidemment, la solution c'est "pas de SSL", mais sur du smtp authentifié, c'est quand même très très moche) (sur l'imap aussi, mais ça permet moins facilement d'envoyer du spam qui tache, par contre, en terme de divulgation d'infos, ça...)
Ca par contre, c'est non. Pas la peine d'argumenter, je vire direct les mecs de mon équipes qui font encore ça en 2017.
C'est la seule solution possible avec les contrainte de support de tous les clients mails possibles /et/ du domain.tld du client. La solution sécurisée ici, c'est smtp/imap.fsi.tld, et c'est tout.
Quoi que si, il y en a une autre, à l'ancienne, d'avant le SNI: une IP par certificat SSL client.
Faudrait se rappeler que le but de l'informatique, c'est d'offrir des outils à vos clients, pas de les faire chier au maximum. Si ça peut être sécurisé, tant mieux, sinon, il faut qu'ils puissent travailler quand même.
C'est une simple application du https://en.wikipedia.org/wiki/Robustness_principle Ici par exemple, on fait tout en TLS, mais on supporte quand même les versions non chiffrées, parce que ce n'est pas à nous d'imposer à un client des règles de sécurité. On leur donne les outils pour respecter les best practices, mais ce n'est certainement pas notre rôle de les forcer.
(Et bon courage devant les prud'hommes pour justifier un licenciement parce qu'un type a voulu faire en sorte qu'un client puisse être concentré sur son coeur de métier)
Arnaud, qui se demande si on est vendredi, vu les trolls.