Envoi d'email depuis serveur kimsufi via le SMTP de ovh ssl0.ovh.net
... / Envoi d'email depuis serv...
< Previous question   -   Next question >
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
Question

Envoi d'email depuis serveur kimsufi via le SMTP de ovh ssl0.ovh.net

JP
by
Jay PETRI
Created on 2025-05-21 11:23:58 (edited on 2025-05-26 07:12:14) in MX Plan

Bonjour,
OVH m'a confirmé que mon site web lamallepourtous.com sur serveur Kimsufi pouvait bien envoyer ses emails (commandes, inscription, recup de mots de passe) via le SMTP de ovh ssl0.ovh.net... voir piece jointe.

Sauf que ça me renvoie l'erreur :  Failed to authenticate on SMTP server with username "contact@lamallepourtous.com" using 2 possible authenticators. Authenticator LOGIN returned Expected response code 235 but got code "535", with message "535 5.7.1 Authentication failed ". Authenticator PLAIN returned Expected response code 235 but got code "535", with message "535 5.7.1 Authentication failed ".

De dépit, et aussi pour éviter de perdre trop de clients, j'ai donc essayé avec notre adresse en @gmail, mais même erreur, jusqu'à ce que je trouve l'info comme quoi google fournit pour cela un "mot de passe d'application" différent du mot de passe normal de la boite à email...

J'imagine que OVH fournit aussi de tels "mots de passe d'application" mais je ne sais ni ou ni comment et ils ont clos la conversation en disant de demander ici, ou de payer un prestataire...

Autre chose, je reçois mes emails uniquement sur thunderbird, je n'ai aucun accès au webmail indiqué dans le manager OVH qui renvoie vers Zimbra qui refuse mes identifiants de boites emails... Mais ça à la limite je m'en fiche, sauf s'il y en a besoin pour configurer le "mot de passe d'application" dont j'aurais besoin pour que mon site hébergé sur Kimsufi puisse envoyer des emails de façon à ce qu'ils soient reçus.

Les emails sont bien envoyé, mais gmail.com et autres les refusent parce qu'ils veulent des enregistrement SPF DKIM et DMARC que mon serveur n'a pas... Je préférerais que mon site envoie ces emails comme avant, c'est à dire via le SMTP de ovh ssl0.ovh.net.

Pouvez-vous m'aider ?

Cordialement

  • Capture d’écran 2025-05-21 à 18.12.43.png 564.2K
Upvotes (0)
2369 Views
Accepted Solution
See this answer in context

Normalement ssl0.ovh.net:465 est accessible depuis partout. Y compris depuis les kimsufi.

Ce n'est pas votre firewall qui vous bloque ?

 
Helpful (0)
Replies (0)
8 Replies ( Latest reply on 2025-05-26 13:51:24 by
Jay PETRI
)

Bonjour,

Vous parlez de votre site hébergé sur kimsufi...

Quelles sont les versions de Linux, de PHP, de openssl ?

cat /etc/debian_version
dpkg -l openssl
php --version

 

Si votre système est trop ancestral, vous devez vous mettre à jour et supporter au moins TLS1.2 pour pouvoir discuter avec les serveurs d'OVH.

Depuis votre shell Linux, essayez la commande suivante:

openssl s_client -connect ssl0.ovh.net:465 -tls1_2

(il faudra peut-être sortir avec control-C si la dernière ligne affiche: 220 GARM-114S008 Wednesday, May 21, 2025)

Sinon qu'est-ce ça raconte ?

 
Helpful (0)
JP

Bonjour Fritz2cat :)

Mes excuses à propos d'un autre message concernant la zone DNS que j'avais écrit au nom de David Mz : Je n'ai jamais pu te répondre, et impossible de poser d'autre question depuis mon compte David Mz... Et impossible de contacter le forum à ce sujet... Pour info en fait le contact technique ne peut accéder à la zone DNS malgré le bouton [creer la zone DNS] dans le manager OVH, et alors que tu avais raison, et que c'était logique : la zone DNS existait bien... Bref, ça, c'est résolu.

Pour ce nouveau problème, je peux donc répondre à ta réponse, ouf :

Ce serveur Kimsufi est tout neuf, j'y ai installé debian 12 et il utilise TLS1.3, ci-dessous le résultat des lignes de commande demandées :

xxx@ns3xxxx1:~$ cat /etc/debian_version
12.11


xxx@ns3xxxx1:~$ dpkg -l openssl
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version          Architecture Description
+++-==============-================-============-====================================================
ii  openssl        3.0.16-1~deb12u1 amd64        Secure Sockets Layer toolkit - cryptographic utility


xxx@ns3xxxx1:~$ php --version
PHP 8.1.32 (cli) (built: Mar 13 2025 18:12:19) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.32, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.32, Copyright (c), by Zend Technologies


xxx@ns3xxxx1:~$ openssl s_client -connect ssl0.ovh.net:465 -tls1_2
CONNECTED(00000003)
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = ns0.ovh.net
verify return:1
---
Certificate chain
 0 s:CN = ns0.ovh.net
   i:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug 16 00:00:00 2024 GMT; NotAfter: Aug 16 23:59:59 2025 GMT
 1 s:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
   v:NotBefore: Nov  2 00:00:00 2018 GMT; NotAfter: Dec 31 23:59:59 2030 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHQTCCBimgAwIBAgIRAMMFDK0lOYhyTDui7X4K754wDQYJKoZIhvcNAQELBQAw
gY8xCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE3MDUGA1UE
AxMuU2VjdGlnbyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD
QTAeFw0yNDA4MTYwMDAwMDBaFw0yNTA4MTYyMzU5NTlaMBYxFDASBgNVBAMTC25z
MC5vdmgubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAkEy2zBmC
BF/xqXMsv3ScvxJ7qnrH+qpYDrHCkc7nt1CE9lZ53zKKL13g0baaGyMmNZ+R8VrP
PV3mC7rOEYObvwqNBQXQqTg3tdF7Uf54f0g+8a8Blhxi+EkXc6weqnBxrmlGWZGw
RYgn7oh4BOuPFO4PwYb1Ch+kVOMQd+QcR5tFZ4IPTAKN3bk4sVjrz+rHvPB5yWEU
gBFC//hAUWklmbl7D1yBtFATTc8nA8eFJkhaFFzFJs7KAF9mh4jupBS9DEr6Agw9
Bn/5ua0QjCKmu6bLK8Cb54iGvBffXzNnZy2FqpP+gAp9HOuTNkHgf9WOPymNSg72
2kvHdqvRu77Jytgn3LBOnkelutzpwqxHKJuWCmH1YzbJyNOMOqZCs1Ej0NHCNt+u
K6OvQRGP30nqVYZazvZuSE26sH3rv5yI3LZ3qptORJvlQ5TQ2HiS9cQG5ennt8k+
fB0U/ZFArQlG5Es1drZE21v0ft3/6he8yrjyPssaka+08Jn/SWMnnqpnJqxF4mpd
juhk+cuyVciNyzRxKwiZEJNtaTb57gehCcrFwzltzSMBkPuytjHu96+AwQeiEyvG
6/kdA0hJQyQRUva2aZXk1eY7PEH7MPqdxD1WB0Im7LFz3U0sqIrULut+70ubGPuo
2Cl9iULKGUD7PxRIYZ1cVNwhFHqnqj8BCgMCAwEAAaOCAw4wggMKMB8GA1UdIwQY
MBaAFI2MXsRUrYrhd+mb+ZsF4bgBjWHhMB0GA1UdDgQWBBS76xFV6LLzSPx+QzOU
5X8dnXftHzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAU
BggrBgEFBQcDAQYIKwYBBQUHAwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAl
MCMGCCsGAQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEw
gYQGCCsGAQUFBwEBBHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdv
LmNvbS9TZWN0aWdvUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNy
dDAjBggrBgEFBQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wggF+BgorBgEE
AdZ5AgQCBIIBbgSCAWoBaAB2AN3cyjSV1+EWBeeVMvrHn/g9HFDf2wA6FBJ2Ciys
u8gqAAABkVtJEEQAAAQDAEcwRQIgZIIU32wINxFdOkufOsoQOmrzfeoPbS7NrMA8
HxWQCvYCIQCIO2EOLdoSbOrtBmwdEiacYsc3SAf/diGbliluw30DFAB2AA3h8jAr
0w3BQGISCepVLvxHdHyx1+kw7w5CHrR+Tqo0AAABkVtJEB8AAAQDAEcwRQIgZigJ
RjlKPXP6KqAW9el25hlH1tomfUKHF+lGkFuVPM4CIQC7bOV3MdOGHGMau0b3yJoT
+Ax94C0n14KuICGn4wZTBgB2ABLxTjS9U3JMhAYZw48/ehP457Vih4icbTAFhOvl
hiY6AAABkVtJEB0AAAQDAEcwRQIgTBtx5uUIGvnVgIMAeclMZp0xtO0zS4iL3YHs
Aq5xa3ECIQD26aqfUJ/l8PadHLo2DrrGPgE5ji7poGLayftaYKjFLjA3BgNVHREE
MDAuggtuczAub3ZoLm5ldIIRc210cC5tYWlsLm92aC5uZXSCDHNzbDAub3ZoLm5l
dDANBgkqhkiG9w0BAQsFAAOCAQEAhf9nCp/FXwLnqUhPzaZeUNCUQfIZ6kDb4VTq
O1dDKy0gHGKxZ90vXum9oz3LVOhYKK9rAdk09BBB9Rydf9ImIPNteL3gvq6+Fmlm
5of42tpMa2rKIEcma+a79/FPXivUQ9vGfTvh7gRc29N9vjqnMit1ThpFN8Agv8Uo
tBF2agB0aUViha2xFFN7aBuScpnTdhYAnad+hgZdxSd2OwcHUPDF56jCmNX3JnmJ
Qm14yxi2mnZEKFnoWxt/QXRvYxu/KshiqEaWkZKtvQHXWO68VshvU9zD/6DSHd2n
XkVDQViH4bFtlLabEYAAXkTa0lrPs0fCMGwnhRoAcB4XnGvhKg==
-----END CERTIFICATE-----
subject=CN = ns0.ovh.net
issuer=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4134 bytes and written 302 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: B5150000831EACEDB2DFDF582209387FBA199819F012EB6EAC589BD23FD0234D
    Session-ID-ctx: 
    Master-Key: 4006578561352D2F3CEA1761F445D147B3E242ADE246D6692F8023783E0FDC5280E2AAA4A13C41E7CA8DDFF72D410ECD
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1747898625
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
220 GARM-98R002 Thursday, May 22, 2025
40575DDC897F0000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:../ssl/record/rec_layer_s3.c:322:

xxx@ns3xxxx1:~$ 

Je vois déjà une erreur unexpected end of file sur la dernière ligne... Mais ça te parlera surement plus qu'à moi, merci de ta réponse, cordialement :)
Helpful (0)

Merci pour cette réponse.

Maintenant qu'on sait que ton serveur est à jour (et mieux que OVH)

On peut dire que OVH n'a vraiment fait aucun effort pour s'adapter au plus grand nombre de ses clients.

Ils ont décommissionné TLS1.0 et TLS1.1 ce qui est une bonne chose en soi, car ces deux protocoles sont fortement déconseillés.

En revanche ils n'ont implémenté que TLS1.2 mais pas TLS1.3 , ce dernier est quand même commun depuis pas mal d'années
https://www.cloudflare.com/fr-fr/learning/ssl/why-use-tls-1.3/

Une fois la couche TLS établie, les deux parties doivent convenir d'un algorithme de cryptage ("cipher") commun pour pouvoir se parler.

OVH ne propose que DEUX ciphers: ECDHE-RSA-AES256-GCM-SHA384 et ECDHE-RSA-AES128-GCM-SHA256

Là où OVH ne propose qu'une version TLS (1.2) et deux ciphers, voici pour comparaison ce que smtp.gmail.com propose:

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      offered (deprecated)
 TLS 1.1    offered (deprecated)
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK)

Ciphers:
ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-SHA
               ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES256-GCM-SHA384
               ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-SHA AES256-SHA DES-CBC3-SHA

Il ne faut dès lors pas s'étonner que Gmail accepte un tas de clients "exotiques" qui n'arrivent pas à ouvrir une connexion avec le SMTP d'OVH.
Helpful (0)
JP

Bonjour :)
Et euh wow... Après contact telephonique avec un technicien de OVH, il s'est avéré que j'utilisais un mauvais mot de passe, je ne pouvais pas vérifier cela, juste faire confiance à mon client quand à cette info. Du coup j'ai pu, d'une part, enfin accéder au webmail, ce dont je n'ai pas besoin sauf pour vérifier que le mot de passe était ok, et d'autre part re-tenter de configurer l'envoi d'email par le site web (prestashop 8.1) via :
ssl0.ovh.net:465 avec l'adresse_email_ok:motdepasse_ok

Et là de nouveau une erreur :

Envoi avec TLS :
Une erreur est survenue. Veuillez vérifier les votre configuration.
Connection to tcp://ssl0.ovh.net:465 Timed Out

Si je comprends bien ce que vous me dîtes, cela pourrait être du au fait que mon serveur kimsufi utilise TLS1.3 alors qu'il faut TLS1.2 ?

Je ne sais carrément pas ce qu'est un cypher... Je vais regarder ça et regarder si je peux passer mon serveur en TLS1.2, mais si vous avez une méthode pour résoudre ça... Je vous fais plus confiance qu'à moi-même :)

Merci pour votre réponse, et d'avance pour la prochaîne :)
Cordialement
Helpful (0)
JP

J'ai donc cherché un peu... vu la config d'openSSL, mais rien trouvé dedans ni rien touché...
Dans mon VirtualMin > Web config > config SSL > options SSL j'ai trouvé que mon serveur utilisait TLS 1.2 et 1.3, j'ai donc décoché TLS 1.3 et cliqué sur "apply changes"... J'ai aussi re-démarré Apache, enfin cliqué sur "apply changes" dans Webmin > Serveur > Apache, au cas ou...

Mais toujours la même erreur quand j'envoie un email test vers mon adresse @gmail.com :

Helpful (0)
JP

Fiou... Suite à l'envoi de fichiers PNG de 300 à 500ko en pieces jointes, j'avais été banni, et pareil pour le compte David Mz il y a quelques jours... Je n'ai pu contacter personne à ce sujet alors help.ovhcloud.com a fini par me donner le contact X-twitter ovh_support_fr qui nous a dé-bannis... Une vraie galère, des jours et des jours de perdus.

Bref... Concernant le présent problème il était que :
Le mot de passe que j'utilisais était finalement le bon, et marchait très bien avec Thunderbird, mais pas sur Zimbra ni en direct avec le ssl0.ovh.net ...

Et ensuite la config que m'avait envoyé ovh était :
ssl0.ovh.net / Protocole: SMTP / Port : 465 / Sécurité: SSL-TLS / email_ok:pwd_ok

Alors que la bonne config est :
ssl0.ovh.net / Protocole: SMTP / Port : 587 / Sécurité: SSL-TLS / email_ok:pwd_ok

Merci beaucoup Fritz2cat, les infos que tu m'as donné m'ont beaucoup aidé, et à présent j'arrive même à envoyer les mails de notifs de webmin/kimsufi ainsi que de mes scripts SH de sauvegardes... Ouf ouf ouf !

Soyez bénis.
Mais faîtes quelque chose SVP pour le cas ou un utilisateur se fasse bannir pour rien, qu'il puisse contacter un responsable du forum sans être obligé de passer par tous les services de OVH avant d'être obligé de s'inscrire sur X-Twitter...

Merci encore, cordialement
Helpful (0)

Ici tu soulèves le problème du n° de port.

465 c'est une conversation SMTP qui démarre immédiatement cryptée avec SSL (ou TLS1.2 en l'occurrence)

587 c'est une conversation SMTP qui démarre en clair, et ensuite où le client demande de basculer en SSL (ou TLS1.2) via une commande "STARTTLS"

Le résultat est que le début de conversation est incompatible entre les deux.

En outre OVH a divers types d'hébergements mail.

Les hébergements historiques (avec Roundcube comme webmail) acceptent les deux.

Les hébergements Microsoft (avec OutlookWeb) n'ont jamais fonctionné avec le port 465 chez OVH.

Avec Zimbra, je ne sais pas. J'avais bien un Zimbra, mais c'était un hébergement avec un domaine que j'ai abandonné. Je ne suis pas en mesure de tester pour y répondre. Les guides donnent sans doute la bonne réponse.

 
Helpful (0)

Related questions

Join discussion