est ce que quelqu'un sait si la majorité des hébergeurs tournent encore en
SSL plutôt qu'en TLS ? en effet OVH ne gère pas le TLS ...j'ai des mails de
clients utilisant le TLS qui leur revienne..
"Nos serveurs SMTP ne supportent pas le protocole TLS à l'heure actuelle. Vous pouvez utiliser une connexion classique ou bien nos serveurs sécurisés SSL."
Leurs serveurs ne gèrent peut être pas le TLS mais dans ce cas il ne doivent pas indiquer la commande "STARTTLS" en SMTP après un "helo". Il y a bien une erreur de leur coté.
Un client qui gueule sur 300 000 ..... bonne chance.
Fred
voici leur réponse :
"Nos serveurs SMTP ne supportent pas le protocole TLS à l'heure actuelle.
Vous pouvez utiliser une connexion classique ou bien nos serveurs sécurisés
SSL."
Leurs serveurs ne gèrent peut être pas le TLS mais dans ce cas
il ne doivent pas indiquer la commande "STARTTLS" en SMTP après un
"helo". Il y a bien une erreur de leur coté.
Un client qui gueule sur 300 000 ..... bonne chance.
"Nos serveurs SMTP ne supportent pas le protocole TLS à l'heure actuelle. Vous pouvez utiliser une connexion classique ou bien nos serveurs sécurisés SSL."
Leurs serveurs ne gèrent peut être pas le TLS mais dans ce cas il ne doivent pas indiquer la commande "STARTTLS" en SMTP après un "helo". Il y a bien une erreur de leur coté.
Un client qui gueule sur 300 000 ..... bonne chance.
Fred
Samuel
Bonjour,
Leurs serveurs ne gèrent peut être pas le TLS mais dans ce cas il ne doivent pas indiquer la commande "STARTTLS" en SMTP après un "helo". Il y a bien une erreur de leur coté.
Si je ne dis pas de bêtises .... le protocole d'échange sécurisé doit être négocié entre les deux serveurs smtp ... s'ils ne tombent pas d'accord sur un protocole sécurisé (tls ou ssl), l'échange doit passer en clair , non ?
Dans ce cas, c'est l'émetteur qui est en tord de ne pas accepter d'envoyer en clair, non ?
Samuel.
Bonjour,
Leurs serveurs ne gèrent peut être pas le TLS mais dans ce cas
il ne doivent pas indiquer la commande "STARTTLS" en SMTP après un
"helo". Il y a bien une erreur de leur coté.
Si je ne dis pas de bêtises .... le protocole d'échange sécurisé doit
être négocié entre les deux serveurs smtp ... s'ils ne tombent pas
d'accord sur un protocole sécurisé (tls ou ssl), l'échange doit passer
en clair , non ?
Dans ce cas, c'est l'émetteur qui est en tord de ne pas accepter
d'envoyer en clair, non ?
Leurs serveurs ne gèrent peut être pas le TLS mais dans ce cas il ne doivent pas indiquer la commande "STARTTLS" en SMTP après un "helo". Il y a bien une erreur de leur coté.
Si je ne dis pas de bêtises .... le protocole d'échange sécurisé doit être négocié entre les deux serveurs smtp ... s'ils ne tombent pas d'accord sur un protocole sécurisé (tls ou ssl), l'échange doit passer en clair , non ?
Dans ce cas, c'est l'émetteur qui est en tord de ne pas accepter d'envoyer en clair, non ?
Samuel.
Patrick Mevzek
Si je ne dis pas de bêtises .... le protocole d'échange sécurisé doit être négocié entre les deux serveurs smtp ... s'ils ne tombent pas d'accord sur un protocole sécurisé (tls ou ssl), l'échange doit passer en clair , non ?
Pas forcément. Il peut y avoir configuration explicite pour n'autoriser que du chiffré, quand on préfère rien du tout (pas d'envoi) que quelque chose non chiffré.
De plus l'erreur retournée (454) est temporaire, ce qui veut dire que l'émetteur est en droit (même en devoir) de retransmettre le message ultérieurement, car c'est a priori un problème du côté du destinataire qui va se résoudre (ex: boîte pleine, surcharge du serveur, etc...)
Cf ftp://ftp.rfc-editor.org/in-notes/rfc3207.txt If the client receives the 454 response, the client must decide whether or not to continue the SMTP session. Such a decision is based on local policy. For instance, if TLS was being used for client authentication, the client might try to continue the session, in case the server allows it even with no authentication. However, if TLS was being negotiated for encryption, a client that gets a 454 response needs to decide whether to send the message anyway with no TLS encryption, whether to wait and try again later, or whether to give up and notify the sender of the error.
L'émetteur est donc en droit de ne pas passer en version non chiffrée.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Si je ne dis pas de bêtises .... le protocole d'échange sécurisé doit
être négocié entre les deux serveurs smtp ... s'ils ne tombent pas
d'accord sur un protocole sécurisé (tls ou ssl), l'échange doit passer
en clair , non ?
Pas forcément. Il peut y avoir configuration explicite pour n'autoriser
que du chiffré, quand on préfère rien du tout (pas d'envoi) que quelque
chose non chiffré.
De plus l'erreur retournée (454) est temporaire, ce qui veut dire que
l'émetteur est en droit (même en devoir) de retransmettre le message
ultérieurement, car c'est a priori un problème du côté du destinataire
qui va se résoudre (ex: boîte pleine, surcharge du serveur, etc...)
Cf ftp://ftp.rfc-editor.org/in-notes/rfc3207.txt
If the client receives the 454 response, the client must decide
whether or not to continue the SMTP session. Such a decision is
based on local policy. For instance, if TLS was being used for
client authentication, the client might try to continue the session,
in case the server allows it even with no authentication. However,
if TLS was being negotiated for encryption, a client that gets a 454
response needs to decide whether to send the message anyway with no
TLS encryption, whether to wait and try again later, or whether to
give up and notify the sender of the error.
L'émetteur est donc en droit de ne pas passer en version non chiffrée.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Si je ne dis pas de bêtises .... le protocole d'échange sécurisé doit être négocié entre les deux serveurs smtp ... s'ils ne tombent pas d'accord sur un protocole sécurisé (tls ou ssl), l'échange doit passer en clair , non ?
Pas forcément. Il peut y avoir configuration explicite pour n'autoriser que du chiffré, quand on préfère rien du tout (pas d'envoi) que quelque chose non chiffré.
De plus l'erreur retournée (454) est temporaire, ce qui veut dire que l'émetteur est en droit (même en devoir) de retransmettre le message ultérieurement, car c'est a priori un problème du côté du destinataire qui va se résoudre (ex: boîte pleine, surcharge du serveur, etc...)
Cf ftp://ftp.rfc-editor.org/in-notes/rfc3207.txt If the client receives the 454 response, the client must decide whether or not to continue the SMTP session. Such a decision is based on local policy. For instance, if TLS was being used for client authentication, the client might try to continue the session, in case the server allows it even with no authentication. However, if TLS was being negotiated for encryption, a client that gets a 454 response needs to decide whether to send the message anyway with no TLS encryption, whether to wait and try again later, or whether to give up and notify the sender of the error.
L'émetteur est donc en droit de ne pas passer en version non chiffrée.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Samuel
Si je ne dis pas de bêtises .... le protocole d'échange sécurisé doit être négocié entre les deux serveurs smtp ... s'ils ne tombent pas d'accord sur un protocole sécurisé (tls ou ssl), l'échange doit passer en clair , non ? Dans ce cas, c'est l'émetteur qui est en tord de ne pas accepter d'envoyer en clair, non ? Samuel.
J'ai certainement dit une bêtise à cause du STARTLS qui est annoncé ... je pensais qu'en cas d'échec du protocole utilisé (et non pas de l'annonce du protocole) le transfert se faisait en clair ... mais ça doit pas être la cas.
Samuel.
Si je ne dis pas de bêtises .... le protocole d'échange sécurisé doit
être négocié entre les deux serveurs smtp ... s'ils ne tombent pas
d'accord sur un protocole sécurisé (tls ou ssl), l'échange doit passer
en clair , non ?
Dans ce cas, c'est l'émetteur qui est en tord de ne pas accepter
d'envoyer en clair, non ?
Samuel.
J'ai certainement dit une bêtise à cause du STARTLS qui est annoncé ...
je pensais qu'en cas d'échec du protocole utilisé (et non pas de
l'annonce du protocole) le transfert se faisait en clair ... mais ça
doit pas être la cas.
Si je ne dis pas de bêtises .... le protocole d'échange sécurisé doit être négocié entre les deux serveurs smtp ... s'ils ne tombent pas d'accord sur un protocole sécurisé (tls ou ssl), l'échange doit passer en clair , non ? Dans ce cas, c'est l'émetteur qui est en tord de ne pas accepter d'envoyer en clair, non ? Samuel.
J'ai certainement dit une bêtise à cause du STARTLS qui est annoncé ... je pensais qu'en cas d'échec du protocole utilisé (et non pas de l'annonce du protocole) le transfert se faisait en clair ... mais ça doit pas être la cas.
Entendu merci pour ces réponses. Quel argument puis-je fournir afin qu'ils fassent la modification ? d'ordre technique et solides ?
merci de votre aide, j'ai besoin que ces mails arrivent.
cordialement.
GPLHost
R12y wrote:
On Thu, 01 Sep 2005 13:56:17 +0200, GPLHost wrote:
Si ça suffit pas, change de prestataire et choisi quelqu'un qui aide ses clients...
Dans beaucoup de cas, les gens auront choisi OVH pour le low cost. Ils sont donc radins, ou, plus noblement dit, cherchent à réduire leurs couts. Le cout d'une migration n'étant pas toujours négligeable, je pense que les clients OVH ne sont pas psycologiquement prêts à changer de prestataire...
Pourtant, si ils étaient chez un prestataire 10x plus cher, avec dix fois moins d'incidents, ils auraient plus rapidement décidé de changer :-)
N'importe quoi... OVH n'est pas si low cost que ça, ils sont juste au prix du marcher. Tu va pas si loin, en angleterre par exemple et t'as des prix plus bas. Exemple: easyspace.com fait un espace de 500MB pour 30 euros par an a peu près. OVH propose 90 Mo d'espace disque pour 44,50 hors taxes... Et je peux vous trouver pleins d'exemple comme ça (sans meme me faire de la pub, et comparer avec MES prix de GPLHost qui sont d'ailleurs aussi moins cher, je peux vous trouver des tas d'autres exemples chez les hébergeurs européens).
Cela dit, je ne vois pas pourquoi une migration est "cher"... Au pire, un mois ou es facturé par 2 hébergeur. Pour un petit hébergement mutualisé, c'est quelques euros...
Arretez de dire que OVH est pas cher, c'est faux.
Thomas
R12y wrote:
On Thu, 01 Sep 2005 13:56:17 +0200, GPLHost wrote:
Si ça suffit pas, change de prestataire et
choisi quelqu'un qui aide ses clients...
Dans beaucoup de cas, les gens auront choisi OVH pour le low cost.
Ils sont donc radins, ou, plus noblement dit, cherchent à réduire leurs
couts.
Le cout d'une migration n'étant pas toujours négligeable, je pense
que les clients OVH ne sont pas psycologiquement prêts à changer de
prestataire...
Pourtant, si ils étaient chez un prestataire 10x plus cher, avec dix fois
moins d'incidents, ils auraient plus rapidement décidé de changer :-)
N'importe quoi... OVH n'est pas si low cost que ça, ils sont juste au
prix du marcher. Tu va pas si loin, en angleterre par exemple et t'as
des prix plus bas. Exemple: easyspace.com fait un espace de 500MB pour
30 euros par an a peu près. OVH propose 90 Mo d'espace disque pour 44,50
hors taxes... Et je peux vous trouver pleins d'exemple comme ça (sans
meme me faire de la pub, et comparer avec MES prix de GPLHost qui sont
d'ailleurs aussi moins cher, je peux vous trouver des tas d'autres
exemples chez les hébergeurs européens).
Cela dit, je ne vois pas pourquoi une migration est "cher"... Au pire,
un mois ou es facturé par 2 hébergeur. Pour un petit hébergement
mutualisé, c'est quelques euros...
On Thu, 01 Sep 2005 13:56:17 +0200, GPLHost wrote:
Si ça suffit pas, change de prestataire et choisi quelqu'un qui aide ses clients...
Dans beaucoup de cas, les gens auront choisi OVH pour le low cost. Ils sont donc radins, ou, plus noblement dit, cherchent à réduire leurs couts. Le cout d'une migration n'étant pas toujours négligeable, je pense que les clients OVH ne sont pas psycologiquement prêts à changer de prestataire...
Pourtant, si ils étaient chez un prestataire 10x plus cher, avec dix fois moins d'incidents, ils auraient plus rapidement décidé de changer :-)
N'importe quoi... OVH n'est pas si low cost que ça, ils sont juste au prix du marcher. Tu va pas si loin, en angleterre par exemple et t'as des prix plus bas. Exemple: easyspace.com fait un espace de 500MB pour 30 euros par an a peu près. OVH propose 90 Mo d'espace disque pour 44,50 hors taxes... Et je peux vous trouver pleins d'exemple comme ça (sans meme me faire de la pub, et comparer avec MES prix de GPLHost qui sont d'ailleurs aussi moins cher, je peux vous trouver des tas d'autres exemples chez les hébergeurs européens).
Cela dit, je ne vois pas pourquoi une migration est "cher"... Au pire, un mois ou es facturé par 2 hébergeur. Pour un petit hébergement mutualisé, c'est quelques euros...
Arretez de dire que OVH est pas cher, c'est faux.
Thomas
Frédéric VANNIÈRE
Bonjour,
Finalement ils ont mis à jour leurs serveurs SMTP
Service: Emails Résumé: mise à jour qmail (sans TLS) Type de tâche: Amélioration Catégorie: MX (entrants) Etat: Fini Pourcentage achevé: 100 Détails: ------------------------------------------------------------- Tuesday, 6 Sep 2005, 11:08am Nous sommes en train de mettre en place une version de qmail sans TLS (le cryptage à l'interieur de qmail). -------------------------------------------------------------
Vous aurez plus d'information sur cette tâche à l'adresse suivante: http://travaux.ovh.net/index.php?doÞtails&idV2
Il suffit de demander :)
Frédéric.
bonjour,
est ce que quelqu'un sait si la majorité des hébergeurs tournent encore en SSL plutôt qu'en TLS ? en effet OVH ne gère pas le TLS ...j'ai des mails de clients utilisant le TLS qui leur revienne..
merci !
Bonjour,
Finalement ils ont mis à jour leurs serveurs SMTP
Service: Emails
Résumé: mise à jour qmail (sans TLS)
Type de tâche: Amélioration
Catégorie: MX (entrants)
Etat: Fini
Pourcentage achevé: 100
Détails:
-------------------------------------------------------------
Tuesday, 6 Sep 2005, 11:08am
Nous sommes en train de mettre en place une version
de qmail sans TLS (le cryptage à l'interieur de qmail).
-------------------------------------------------------------
Vous aurez plus d'information sur cette tâche à l'adresse suivante:
http://travaux.ovh.net/index.php?doÞtails&idV2
Il suffit de demander :)
Frédéric.
bonjour,
est ce que quelqu'un sait si la majorité des hébergeurs tournent encore en
SSL plutôt qu'en TLS ? en effet OVH ne gère pas le TLS ...j'ai des mails de
clients utilisant le TLS qui leur revienne..
Service: Emails Résumé: mise à jour qmail (sans TLS) Type de tâche: Amélioration Catégorie: MX (entrants) Etat: Fini Pourcentage achevé: 100 Détails: ------------------------------------------------------------- Tuesday, 6 Sep 2005, 11:08am Nous sommes en train de mettre en place une version de qmail sans TLS (le cryptage à l'interieur de qmail). -------------------------------------------------------------
Vous aurez plus d'information sur cette tâche à l'adresse suivante: http://travaux.ovh.net/index.php?doÞtails&idV2
Il suffit de demander :)
Frédéric.
bonjour,
est ce que quelqu'un sait si la majorité des hébergeurs tournent encore en SSL plutôt qu'en TLS ? en effet OVH ne gère pas le TLS ...j'ai des mails de clients utilisant le TLS qui leur revienne..
merci !
oles
Bonjour, Dis donc ... il y a des vrais feuilletons à rebondissement dans ce newsgroups :) Plus simple: vous pouvez m'envoyer un email en privé aussi ... perso je lis pas tous les jours. je crois que personne de chez ovh ne le fait.
Octave
-- Simplifiez la gestion de votre hebergement et telechargez MoM: http://www.ovh.com/fr/download pour Windows, Mac ou Linux. C'est gratuit !
Bonjour,
Dis donc ... il y a des vrais feuilletons à rebondissement dans ce newsgroups :)
Plus simple: vous pouvez m'envoyer un email en privé aussi ... perso je lis
pas tous les jours. je crois que personne de chez ovh ne le fait.
Octave
--
Simplifiez la gestion de votre hebergement et
telechargez MoM: http://www.ovh.com/fr/download
pour Windows, Mac ou Linux. C'est gratuit !
Bonjour, Dis donc ... il y a des vrais feuilletons à rebondissement dans ce newsgroups :) Plus simple: vous pouvez m'envoyer un email en privé aussi ... perso je lis pas tous les jours. je crois que personne de chez ovh ne le fait.
Octave
-- Simplifiez la gestion de votre hebergement et telechargez MoM: http://www.ovh.com/fr/download pour Windows, Mac ou Linux. C'est gratuit !
Methos
"Frédéric VANNIÈRE" a écrit dans le message de news: 431ea0d6$0$4042$
Bonjour,
Finalement ils ont mis à jour leurs serveurs SMTP
Service: Emails Résumé: mise à jour qmail (sans TLS)
Donc le TLS n'est toujours pas disponible...si je comprends bien ?
"Frédéric VANNIÈRE" <f.vanniere@planet-work.com> a écrit dans le message de
news: 431ea0d6$0$4042$636a15ce@news.free.fr...
Bonjour,
Finalement ils ont mis à jour leurs serveurs SMTP
Service: Emails
Résumé: mise à jour qmail (sans TLS)
Donc le TLS n'est toujours pas disponible...si je comprends bien ?
