[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Deferred: 403 4.7.0 TLS handshake failed.

	Bonjour à tous,
J'utilise sendmail depuis très très très longtemps sur des systèmes variés sans aucun problème. Depuis quelques jours, je me prends des erreurs du type : 

	Deferred: 403 4.7.0 TLS handshake failed.
sur un nombre de domaines croissant. Je viens de patcher sauvagement le sendmail de debian avec tls_failures.m4 issu de la prochain mouture de sendmail pour tenter de corriger ce problème pénible. 

	J'obtiens cette erreur malgré des MX qui renvoient par exemple :

openssl s_client -starttls smtp -connect mxav.alciom.com:25
CONNECTED(00000003)
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority 
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA 
verify return:1
depth=0 OU = Domain Control Validated, OU = Hosted by Dada S.p.A., OU = COMODO SSL Wildcard, CN = *.securemail.pro 
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=Hosted by Dada S.p.A./OU=COMODO SSL Wildcard/CN=*.securemail.pro i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root 
---
Server certificate
-----BEGIN CERTIFICATE-----

gnagnagna....
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=Hosted by Dada S.p.A./OU=COMODO SSL Wildcard/CN=*.securemail.pro issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA 
---
No client certificate CA names sent
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 6572 bytes and written 407 bytes
Verification: OK
---
New, SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
Session-ID: 4855492DCD4A58B3C060C471048FA2F0DC01515F29AFB8414A80E859746BF50E 
    Session-ID-ctx:
Master-Key: C01365653CB02B341D8D7909A855A073169AFA96C85E6A6E3818718C9216B1C93751F3A6BBFD218668751247F43F6D92 
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
   gnagnagna....
    Start Time: 1505306080
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
250 OK
qui me semble tout à fait valable (d'autant que dans cet exemple, le serveur d'en face renvoie "Secure Renegotiation IS supported"). Suis-je le seul à tomber sur ce genre de chose actuellement ? Je n'ai pas l'impression que je puis faire autre chose que de demander à mon sendmail de ne pas utiliser TLS lorsqu'il tombe sur une telle erreur puisque j'ai l'affreuse impression que le problème se situe côté MX client.
J'ai pu remarquer que certains MX renvoyant cette erreur n'envoyaient aucun certificat hier (typiquement ac-limoges.fr), en indiquant fièrement que la renégociation du protocole était interdite, et se permettent d'en envoyer un aujourd'hui. La question subsidiaire est : quelqu'un sait-il s'il y a eu une mise à jour quelconque de serveurs de mails commerciaux qui pourrait donner ce genre d'erreur récemment ? Je trouve bizarre que des domaines qui n'ont rien à voir entre eux posent des problèmes simultanément. 

	Cordialement,

	JKB
Reply to: