[Mail] Bloquage du port 25 est-ce vraiment un problème ??

Ici on parle de logiciels libres et de technologie en général
Grand Pingouin
Message(s) : 101
Inscription : 12 Oct 2015 11:25

[Mail] Bloquage du port 25 est-ce vraiment un problème ??

Message par agaric » 09 Juil 2016 10:13

Bonjour,

Le projet de loi "pour une République numérique" arrive dans sa dernière étape. Il va autoriser l'hébergement des particuliers de leur différent services web: https://www.republique-numerique.fr/pro ... ebergement

Les technophiles s’enthousiasment et critiquent Orange pour le blocage du port 25. Mais es-ce vraiment un problème ??
Le port 25 est communément utilisé pour utiliser le protocole SMTP et en général ses flux ne sont pas chiffrés. À moins de faire un STARTTLS, SMTP utilisera les ports 587 et 465 pour les flux chiffrés.

Comme il est aberrant de communiquer avec son serveur de mail sans passer un flux chiffré, le blocage du port 25 par Orange n'est-il pas une bonne chose, il ne forcerait pas les gens à utiliser des flux chiffrés?? (après je me demande combien de spammeur utilise encore le port 25, alors qu'un flux chiffré doit compliquer leur détection et leur identification comme étant des SPAM).

·
Avatar de l’utilisateur
Message(s) : 144
Inscription : 10 Août 2014 08:36

Re: [Mail] Bloquage du port 25 est-ce vraiment un problème ?

Message par greg » 09 Juil 2016 12:20

Le blocage systématique d'un port, quelle que soit la raison, est un atteinte à la neutralité du réseau. Techniquement, ce que vend Orange n'est pas de l'"Internet", puisque tu ne peux pas communiquer avec un serveur de mail distant autre que le leur.

Ceci dit, un petit point sur les protocoles mail s'impose :

1- l'utilisation du port 25 est normalement réservée aux communications entre serveurs mail, les clients doivent utiliser le port SUBMISSION (587) depuis 1998 et la RFC 2476. Evidemment, des gros FAI n'ont pas tous fait la bascule, et les clients mails non plus ; après tout, cela ne fait que 18 ans que c'est obsolète :-)

2- l'utilisation du port 465 est obsolète également, le STARTTLS étant préféré au SSL pour des raisons de plus grande flexibilité au niveau de la négociation des modes de chiffrement.

3- le 587 n'est pas forcément chiffré, cela dépend uniquement de la configuration côté serveur. En général les serveurs qui sont configurés pour le 587 exigent authentification et TLS, mais ce n'est pas obligatoire.


Enfin, en ce qui concerne le SPAM:

Tous les spammeurs utilisent le port 25, pour plusieurs raisons
A- compte tenu du volume de mails, le chiffrement a un cout CPU non négligeable
B- s'ils utilisaient du SSL, ce serait super facile de chopper leur certificat et de l'interdire, à moins qu'ils en changent à chaque envoi de mail, ce qui une fois de plus entraine un cout CPU plus important.
C- la détection de SPAM se fait au niveau du MDA, donc "dans" le serveur de destination, donc en clair.
D- Pour ces raisons d'utilisation CPU, le "greylisting" fonctionne très bien sur les botnets de SPAM, qui ne peuvent se permettre de garder en file d'attente un message rejeté à titre provisoire.

La methode de Free est la bonne : bloquer le port 25 par défaut, mais permettre aux utilisateurs qui en ont besoin de le débloquer en choisissant l'otpion avec effet immédiat.

Grand Pingouin
Message(s) : 101
Inscription : 12 Oct 2015 11:25

Re: [Mail] Bloquage du port 25 est-ce vraiment un problème ?

Message par agaric » 12 Juil 2016 22:52

Merci de tes précisions.

Tes explications renforce mon opinion que SMTP devraient être utilisé qu'avec des flux chiffrés. À minima au moins pour les communications des serveurs SMTP entre eux qui sont majoritairement gérés par des gens de métier (et des passionnés connaisseurs).
Les GAFA ont bien des défauts mais sur le SPAM, ils font des propositions et essayent de limiter le problème et produisent des RFC: DKIM et SPF

De même l’initiative, de lister les serveurs SMTP qui se connectent aux serveurs SMTP de google avec ou sans connexion chiffrées, est une bonne chose: https://www.google.com/transparencyrepo ... ail/?hl=fr

Google pondère négativement les domaines qui n'ont ni SPF, ni DKIM (ni DMARC). J'imagine que l'absence de flux chiffrés sera aussi sujet à une note négative dans un futur proche.

·
Avatar de l’utilisateur
Message(s) : 144
Inscription : 10 Août 2014 08:36

Re: [Mail] Bloquage du port 25 est-ce vraiment un problème ?

Message par greg » 13 Juil 2016 13:08

Le souci avec le SMTP, c'est qu'on parle d'un des plus anciens protocoles encore massivement utilisés, et que les choix de conception de celui-ci reflètent la puissance limitée des machines de l'époque :

- le TLS/SSL a été rajouté au dessus d'un protocole qui n'a jamais été pensé pour. De ce fait, il n'y a pas de notion de "nom de serveur" intrinsèque à SMTP, contrairement, par exemple à HTTP. Du coup, pas de moyen simple de valider le certificat serveur, et d'après mes statistiques sur mon propre serveur de mails, 70% des serveurs qui font du chiffré ont un certificat auto-signé. (Ca changera peut-être avec letsencrypt, mais pendant longtemps, la norme était de se faire un bon vieux auto-signé pour le SMTP, puisqu'il n'y a aucun contrôle possible.)

- changer quoi que ce soit au niveau des serveurs ou du protocole est bien plus lent que pour le web. Avec un site, c'est simple, il y a 4-5 navigateurs possibles, tout le monde en a un relativement récent (genre moins de 10 ans). En SMTP, il est pas rare de causer avec un sendmail d'une bonne vingtaine d'annés de conception, qui cause ni ESMTP, ni SSL, et qui se déclare au niveau protocolaire comme "localhost". Pourtant, il FAUT recevoir le mail, tu peux pas te permettre en tant que fournisseur de boite aux lettres de refuser un mail légitime sous pretexte que le serveur en face est un machin qui date de la guerre froide : souvent c'est le genre de mail qui finit par "gouv.fr" ou autre truc que tu peux pas interdire à tes usagers de recevoir.

- tout ce que tu peux faire, c'est récupérer le mail, faire du scoring pour savoir si c'est un SPAM, et c'est tout. Je rappelle que le mail est sans équivoque une correspondance privée, et que toute atteinte à ce type de flux est... juridiquement complexe :-)

Du coup, personne ne peut dire "bon, maintenant le mail c'est chiffré ou c'est refusé" : ca serait simplement perdre tes clients/tes utilisateurs.

SPF est probablement le truc le plus stupide jamais inventé : cela tend à rendre obligatoire l'envoi de mails depuis le SMTP "officiel" du domaine concerné :
tu serais content si tu ne pouvais plus envoyer des mails depuis machin@truc.com qu'en passant par smtp.truc.com ? Conceptuellement, cela fonctionne assez bien avec un poste fixe, mais avec la migration rapide vers des terminaux mobiles, c'est simplement stupide :OK, ton flux est chiffré, mais ton FAI sait que tu as une boite chez laposte.net par exemple, vu que tu t'y connectes, et si pour une raison quelconque tu ne peux joindre smtp.laposte.net, ben t'envoies pas de mail...

DKIM est une moins mauvaise approche, mais reste et restera pour longtemps, comme SPF, optionnel.

Tout ce que font ces extensions à SMTP, en plus de lier étroitement SMTP et DNS, ce qui n'est pas forcément une bonne chose, c'est rendre plus complexe un protocole simple qui marche, en tentant de résoudre deux problèmes totalement non corrélés, à savoir le SPAM et la confidentialité des communications.

Pour le SPAM, rien ne change : l'analyse ne peut se faire avec un semblant de fiabilité qu'avec l'ensemble des données, à savoir le corps du message, donc il te faudra le recevoir de toutes façons.

Pour la confidentialité des données, tu as beau mettre du SSL partout, le SMTP source et le SMTP destination ont le message en clair, à moins de faire du GPG ou du S/MIME.

Donc non, à part bouffer du CPU sur les serveurs, faire chier les gars qui ont un serveur de mails qui marche tranquille et faire croire que ça rend tes communications plus sures, forcer le SSL/TLS sur les flux en port 25 n'est pas fondamentalement une priorité, et ne changera rien au SPAM ou à la surveillance.

Tu imagines le bordel si la Poste refusait de transporter toute carte postale et obligeait chaque expéditeur à aller au guichet avec sa carte d'identité, puis à signer au dos de l'enveloppe (forcément opaque et scellée) ?

Perso, je préfère de loin que tout machin de taille raisonnable et correctement timbré que je mets dans n'importe quelle boite jaune arrive à destination. :-)

Mais je comprends, le SPAM c'est chiant.

Grand Pingouin
Message(s) : 101
Inscription : 12 Oct 2015 11:25

Re: [Mail] Bloquage du port 25 est-ce vraiment un problème ?

Message par agaric » 02 Août 2016 00:08

greg a écrit :[...]
Du coup, personne ne peut dire "bon, maintenant le mail c'est chiffré ou c'est refusé" : ca serait simplement perdre tes clients/tes utilisateurs.

SPF est probablement le truc le plus stupide jamais inventé : cela tend à rendre obligatoire l'envoi de mails depuis le SMTP "officiel" du domaine concerné :

Au contraire, je trouve le concept malin et un excellent compromis. Personne ne t'oblige à tout faire passer par ton serveur SMTP. Tu peux déclarer ~all ou bien au contraire restreindre à l'adresse IP de ton serveur ou encore ajouter des serveurs de confiance que tu peux utiliser comme relais (genre ceux d'OVH, si ton serveur auto-hébergé chez toi est en rade).
L'avantage du SMTP est qu'il déclare dans le DNS à qui le récepteur peux faire confiance ou pas.
On peut logiquement dire que les mails venant de @Nomdedomaine_machin.org devraient être +/- ou moins sous son autorité et que si il y a trop de courriels d'embrouille avec @Nomdedomaine_machin.org, on peux lui demander d'y mettre de l'autre et que si cela ne se corrige pas, on le bannit.
tu serais content si tu ne pouvais plus envoyer des mails depuis machin@truc.com qu'en passant par smtp.truc.com ? Conceptuellement, cela fonctionne assez bien avec un poste fixe, mais avec la migration rapide vers des terminaux mobiles, c'est simplement stupide :OK, ton flux est chiffré, mais ton FAI sait que tu as une boite chez laposte.net par exemple, vu que tu t'y connectes, et si pour une raison quelconque tu ne peux joindre smtp.laposte.net, ben t'envoies pas de mail...

DKIM est une moins mauvaise approche, mais reste et restera pour longtemps, comme SPF, optionnel.

Tout ce que font ces extensions à SMTP, en plus de lier étroitement SMTP et DNS, ce qui n'est pas forcément une bonne chose, c'est rendre plus complexe un protocole simple qui marche, en tentant de résoudre deux problèmes totalement non corrélés, à savoir le SPAM et la confidentialité des communications.

Pour le SPAM, rien ne change : l'analyse ne peut se faire avec un semblant de fiabilité qu'avec l'ensemble des données, à savoir le corps du message, donc il te faudra le recevoir de toutes façons.

Pour la confidentialité des données, tu as beau mettre du SSL partout, le SMTP source et le SMTP destination ont le message en clair, à moins de faire du GPG ou du S/MIME.

Donc non, à part bouffer du CPU sur les serveurs, faire chier les gars qui ont un serveur de mails qui marche tranquille et faire croire que ça rend tes communications plus sures, forcer le SSL/TLS sur les flux en port 25 n'est pas fondamentalement une priorité, et ne changera rien au SPAM ou à la surveillance.

Tu imagines le bordel si la Poste refusait de transporter toute carte postale et obligeait chaque expéditeur à aller au guichet avec sa carte d'identité, puis à signer au dos de l'enveloppe (forcément opaque et scellée) ?

Perso, je préfère de loin que tout machin de taille raisonnable et correctement timbré que je mets dans n'importe quelle boite jaune arrive à destination. :-)

Mais je comprends, le SPAM c'est chiant.


Le problème du mail c'est que l'on ne peux pas y mettre de l’authenticité et que l'on doit récurer les chiottes des autres sans un merci.

Pourquoi je peux m'amuser à envoyer un mail venant de @gouv.fr sans que personne n'y trouve à redire dans la chaîne d'échange?
Après au niveau des interfaces des clients (léger, lourd ou web) trop souvent, on cache les entêtes les plus importantes et on facilite ainsi l’usurpation.

J'ai discuté de ce sujet avec Frem, lui et moi avons 2 vision différentes du mail et notamment des rôles dévolus au serveur et aux clients.

Moi, je vois le serveur qu'un centre de stockage, ( dénommé un cloud aujourd'hui) qui me range mes petites affaires en s’appuyant allègrement sur les entêtes. C'est surtout intéressant quand on utilise un client de mail sur un mobile où on ne peux gérer les 4 Go de courriels qui traînent.
Frem ne fait pas confiance à son serveur ([troll]fallait pas utiliser Gmail[/troll off] et lui demande juste d'utiliser les champ, from, to, de minimiser les informations dans les entêtes, il ne laisse rien sur le serveur et se presse de récupérer ses courriels sur une machine de confiance.

Le souci de ta vison Greg est que j'ai peur que tu oublie l'utilisateur lamba qui tombe dans le premier panneau venu et se fait inonder de spam, espionner sa correspondance car les flux entre son POP/IMAP/SMTP ne sont pas chiffrés. Indirectement cela te déssert car sa correspondance, c'est aussi la tienne, celle que tu lui envoie.

Dans ce dernier cas, j'ai bien conscience que cela n'empêchera pas l'espionnage, on limitera un peu l'accès à certaines données qui n'ont pas être diffusés en clair.

Et puis c'est paradoxal, je rédige cette réponse sur ce forum public dans un flux chiffré, mais à l'inverse mes courriels privés ne ont pas encapsulées dans un flux chiffré et potentiellement accessible à toute personne qui connaît bien SMTP.

·
Avatar de l’utilisateur
Message(s) : 144
Inscription : 10 Août 2014 08:36

Re: [Mail] Bloquage du port 25 est-ce vraiment un problème ?

Message par greg » 02 Août 2016 00:40

agaric a écrit :Personne ne t'oblige à tout faire passer par ton serveur SMTP. Tu peux déclarer ~all (...)


Declarer ~all, c'est ne rien déclarer du tout. les systèmes de scoring le comptabilisent au mieux comme une absence de declaration, au pire comme une mauvaise configuration.

agaric a écrit :L'avantage du SMTP est qu'il déclare dans le DNS à qui le récepteur peux faire confiance ou pas.


Ce qui me dérange c'est de melanger deux services qui n'ont pas vocation à travailler ensemble. Le DNS, à part dire qui est le MX, il doit rien savoir de la manière dont les mails sont gérés et transmis.

agaric a écrit :On peut logiquement dire que les mails venant de @Nomdedomaine_machin.org devraient être +/- ou moins sous son autorité et que si il y a trop de courriels d'embrouille avec @Nomdedomaine_machin.org, on peux lui demander d'y mettre de l'autre et que si cela ne se corrige pas, on le bannit.


C'est comme ça que ca marchait "avant", quand chacun gérait son serveur et que postmaster@domaine.tld répondait avec un vrai sysadmin derrière. Depuis le "grand public" (mails de FAI puis Caramail, Voila, Yahoo, Gmail ) c'est fini.

Si on met en place un système de bannissement de domaine dans le genre que tu proposes, c'est la fin des serveurs smtp non GAFAM à court terme. Je pense que cela doit faire partie du top 10 des rêves humides des gars de Google.

agaric a écrit :Le problème du mail c'est que l'on ne peux pas y mettre de l’authenticité et que l'on doit récurer les chiottes des autres sans un merci.


On peut, ça s'appelle gpg ou s/mime.
L'authenticité ça doit venir de l'expéditeur, pas du transitaire.

agaric a écrit :Pourquoi je peux m'amuser à envoyer un mail venant de @gouv.fr sans que personne n'y trouve à redire dans la chaîne d'échange?
Après au niveau des interfaces des clients (léger, lourd ou web) trop souvent, on cache les entêtes les plus importantes et on facilite ainsi l’usurpation.


une fois de plus, si gouv.fr signait ses mails et que tout le monde prenne l'habitude de vérifier la signature au lieu du champ "from", plus de soucis.

agaric a écrit :J'ai discuté de ce sujet avec Frem, lui et moi avons 2 vision différentes du mail et notamment des rôles dévolus au serveur et aux clients.
Moi, je vois le serveur qu'un centre de stockage, ( dénommé un cloud aujourd'hui) qui me range mes petites affaires en s’appuyant allègrement sur les entêtes. C'est surtout intéressant quand on utilise un client de mail sur un mobile où on ne peux gérer les 4 Go de courriels qui traînent.


Tu as une vision "service" du mail, ce qu'il n'est pas. on parle de transit, pas de stockage. SMTP n'est pas IMAP ou POP.
Le stockage après réception n'est pas un problème et n'a aucun impact sur les soucis de SMTP.

agaric a écrit :Frem ne fait pas confiance à son serveur ([troll]fallait pas utiliser Gmail[/troll off] et lui demande juste d'utiliser les champ, from, to, de minimiser les informations dans les entêtes, il ne laisse rien sur le serveur et se presse de récupérer ses courriels sur une machine de confiance.


c'est une possibilité, je trouve qu'il a plutôt raison, mais on est dans le stockage là, pas dans le transit.

agaric a écrit :Le souci de ta vison Greg est que j'ai peur que tu oublie l'utilisateur lamba qui tombe dans le premier panneau venu et se fait inonder de spam, espionner sa correspondance car les flux entre son POP/IMAP/SMTP ne sont pas chiffrés. Indirectement cela te déssert car sa correspondance, c'est aussi la tienne, celle que tu lui envoie.


Le chiffrement ne règlera pas le souci des spams. ni l'espionnage tant qu'il stockera tout sur des machines hors de son contrôle

Grand Pingouin
Message(s) : 101
Inscription : 12 Oct 2015 11:25

Re: [Mail] Bloquage du port 25 est-ce vraiment un problème ?

Message par agaric » 22 Août 2016 23:04

greg a écrit :[....]Pourtant, il FAUT recevoir le mail, tu peux pas te permettre en tant que fournisseur de boite aux lettres de refuser un mail légitime sous pretexte que le serveur en face est un machin qui date de la guerre froide : souvent c'est le genre de mail qui finit par "gouv.fr" ou autre truc que tu peux pas interdire à tes usagers de recevoir.

- tout ce que tu peux faire, c'est récupérer le mail, faire du scoring pour savoir si c'est un SPAM, et c'est tout. Je rappelle que le mail est sans équivoque une correspondance privée, et que toute atteinte à ce type de flux est... juridiquement complexe :-)


Du coup, personne ne peut dire "bon, maintenant le mail c'est chiffré ou c'est refusé" : ça serait simplement perdre tes clients/tes utilisateurs.

Quand ton serveur perso est placé sur blacklist auprès SpamHaus, et tu perds des mails pour tes utilisateurs. Logique tu as mal-configuré ton serveur. Si tu permets pas de recevoir des mails au sein de flux chiffrés c'est pareil .


SPF est probablement le truc le plus stupide jamais inventé : cela tend à rendre obligatoire l'envoi de mails depuis le SMTP "officiel" du domaine concerné :
tu serais content si tu ne pouvais plus envoyer des mails depuis machin@truc.com qu'en passant par smtp.truc.com ? Conceptuellement, cela fonctionne assez bien avec un poste fixe, mais avec la migration rapide vers des terminaux mobiles, c'est simplement stupide :OK, ton flux est chiffré, mais ton FAI sait que tu as une boite chez laposte.net par exemple, vu que tu t'y connectes, et si pour une raison quelconque tu ne peux joindre smtp.laposte.net, ben t'envoies pas de mail...

Je vois pas le problème, si je ne peux aller à la poste, je vais pas me plaindre que mon courrier ne puisse pas arriver à destination. Je trouve toujours hallucinnat qu'un mail peut venir de n'importe et que l'on n'ait aucun moyen de dire" c'est vachement suspect". SPF permet de garder l'ancien comportement ou bien de durcir la sécurité. Avant c'était même pas possible.

DKIM est une moins mauvaise approche, mais reste et restera pour longtemps, comme SPF, optionnel.

Tout ce que font ces extensions à SMTP, en plus de lier étroitement SMTP et DNS, ce qui n'est pas forcément une bonne chose, c'est rendre plus complexe un protocole simple qui marche, en tentant de résoudre deux problèmes totalement non corrélés, à savoir le SPAM et la confidentialité des communications.

C'est déjà le cas. Il faut savoir quels sont les serveurs MX principaux et les serveurs MX relais. Alors un peu plus ou un peu moins.


Pour le SPAM, rien ne change : l'analyse ne peut se faire avec un semblant de fiabilité qu'avec l'ensemble des données, à savoir le corps du message, donc il te faudra le recevoir de toutes façons.

Pour la confidentialité des données, tu as beau mettre du SSL partout, le SMTP source et le SMTP destination ont le message en clair, à moins de faire du GPG ou du S/MIME.

On peux diminuer la surface de divulgation en protégeant déjà le transport. Actuellement, le mail se balade à poil ou bien dans un fourgon blindé appelé GPG. TLS permettrait déjà d'avoir une étape intermédiaire entre ces 2 états.


Donc non, à part bouffer du CPU sur les serveurs, faire chier les gars qui ont un serveur de mails qui marche tranquille et faire croire que ça rend tes communications plus sures, forcer le SSL/TLS sur les flux en port 25 n'est pas fondamentalement une priorité, et ne changera rien au SPAM ou à la surveillance.

Le SPAM cela ne bouffe pas de CPU? Qu'es-ce qu'un serveur de mail qui fonctionne? Un serveur qui envoie et reçoit des mails ou celui qui offre aussi de la sécurité? Une voiture doit-elle d'aller d'un point A à un point B? Ou doit-elle aussi le faire en garantissant ton intégrité ?

·
Avatar de l’utilisateur
Message(s) : 144
Inscription : 10 Août 2014 08:36

Re: [Mail] Bloquage du port 25 est-ce vraiment un problème ?

Message par greg » 30 Août 2016 03:52

agaric a écrit :Quand ton serveur perso est placé sur blacklist auprès SpamHaus, et tu perds des mails pour tes utilisateurs. Logique tu as mal-configuré ton serveur. Si tu permets pas de recevoir des mails au sein de flux chiffrés c'est pareil .

Si tu as un serveur de mails qui se trouve dans une blacklist et que tu perds les mails de tes utilisateurs plutôt que de les rediriger en cas d'echec d'envoi, faut retourner vite chez Gmail....

agaric a écrit :Je vois pas le problème, si je ne peux aller à la poste, je vais pas me plaindre que mon courrier ne puisse pas arriver à destination. Je trouve toujours hallucinnat qu'un mail peut venir de n'importe et que l'on n'ait aucun moyen de dire" c'est vachement suspect". SPF permet de garder l'ancien comportement ou bien de durcir la sécurité. Avant c'était même pas possible.


Le problème c'est que tu empêches tes utilisateurs d'envoyer des mails depuis où ils veulent/peuvent. Ça me dépasse que tu préfères ne pas pouvoir envoyer de mail plutot que d'avoir un peu de jugeote côté destinataire.

agaric a écrit :C'est déjà le cas. Il faut savoir quels sont les serveurs MX principaux et les serveurs MX relais. Alors un peu plus ou un peu moins.


Ouais, une requete DNS, avec généralement des TTL raisonnables. "Un peu plus, un peu moins" c'est total au pif ou tu as des métriques de DNS pour le prouver ? Moi j'en ai. SPF est vraiment non négligeable. Si tu veux être efficace, il faut avoir un TTL très très court (genre 1H), donc au lieu d'une requête DNS par serveur d'envoi et par semaine, tu as une requête par mail par heure. Tu la sens la différence ?

agaric a écrit :On peux diminuer la surface de divulgation en protégeant déjà le transport. Actuellement, le mail se balade à poil ou bien dans un fourgon blindé appelé GPG. TLS permettrait déjà d'avoir une étape intermédiaire entre ces 2 états.

"ouaiiiis, forçons tout le monde à utiliser letsencrypt ou a payer un certif valide"
agaric a écrit :Le SPAM cela ne bouffe pas de CPU?

si, mais du spam en SSL en bouffera encore plus.
agaric a écrit : Qu'es-ce qu'un serveur de mail qui fonctionne? Un serveur qui envoie et reçoit des mails

voila
agaric a écrit :ou celui qui offre aussi de la sécurité? Une voiture doit-elle d'aller d'un point A à un point B? Ou doit-elle aussi le faire en garantissant ton intégrité ?

une voiture n'est pas un serveur mail. Une meilleure analogie serait : "la route qu'empruntent les voitures doit-elle garantir que tout le monde sait conduire correctement ?"
et la réponse est non, sinon c'est plus une route mais une voie ferrée. :-)



Bon, maintenant qu'on a fini de troller, comment qu'on fait dans la vraie vie ?

Une des pistes serait d'utiliser le futur (un jour...) passage à IPV6, qui rend IPSEC obligatoire. Rien n'empêchera alors d'avoir une machine qui n'acceptera que de communiquer via IPSEC, en vérifiant les certifs, les CA, bla bla bla... bref, en ayant un certain niveau de connaissance de la nature de la machine d'en face, plutot qu'une simple IP.
L'avantage c'est que ça "protègera" (grosses guillemets sur le coup, hein, ipsec c'est pas pour les novices à configurer et valider correctement non plus, et ça "protège" rien, ca chiffre et authentifie, mais bon...) tous les protocoles au dessus, pas seulement SMTP.

[troll]on pourra même réutiliser telnet sur ipsec \o/[/troll]


mais bon, faut pas oublier un truc : le premier à mettre une machine comme ça en place,... il communiquera avec personne.
Oeuf, poule toussa....

Retour vers Technologie et Logiciels Libres