No puedo recibir correos de Gmail


15

Hace unos días, Gmail de repente decidió dejar de enviar correos a mi servidor de correo. Estoy usando Postfix y Dovecot con un certificado SSL pagado que se ejecuta en Debian 7 con todo actualizado.

Mi mail.logmuestra el siguiente error:

Dec 19 11:09:11 server postfix/smtpd[19878]: initializing the server-side TLS engine
Dec 19 11:09:11 server postfix/tlsmgr[19880]: open smtpd TLS cache btree:/var/lib/postfix/smtpd_scache
Dec 19 11:09:11 server postfix/tlsmgr[19880]: tlsmgr_cache_run_event: start TLS smtpd session cache cleanup
Dec 19 11:09:11 server postfix/smtpd[19878]: connect from mail-wi0-x230.google.com[2a00:1450:400c:c05::230]
Dec 19 11:09:11 server postfix/smtpd[19878]: setting up TLS connection from mail-wi0-x230.google.com[2a00:1450:400c:c05::230]
Dec 19 11:09:11 server postfix/smtpd[19878]: mail-wi0-x230.google.com[2a00:1450:400c:c05::230]: TLS cipher list "aNULL:-aNULL:ALL:+RC4:@STR                              ENGTH:!aNULL:!DES:!3DES:!MD5:!DES+MD5:!RC4:!RC4-MD5"
Dec 19 11:09:11 server postfix/smtpd[19878]: SSL_accept:before/accept initialization
Dec 19 11:09:11 server postfix/smtpd[19878]: SSL_accept:error in unknown state
Dec 19 11:09:11 server postfix/smtpd[19878]: SSL_accept error from mail-wi0-x230.google.com[2a00:1450:400c:c05::230]: -1
Dec 19 11:09:11 server postfix/smtpd[19878]: warning: TLS library problem: 19878:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown                               protocol:s23_srvr.c:647:
Dec 19 11:09:11 server postfix/smtpd[19878]: lost connection after STARTTLS from mail-wi0-x230.google.com[2a00:1450:400c:c05::230]
Dec 19 11:09:11 server postfix/smtpd[19878]: disconnect from mail-wi0-x230.google.com[2a00:1450:400c:c05::230]

Extractos de mi postfix main.cf:

smtpd_use_tls=yes
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_CAfile = path to CA Bundle
smtpd_tls_cert_file= path to cert (pem)
smtpd_tls_key_file=path to key (pem)
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4, RC4-MD5
smtpd_tls_protocols=!SSLv2,!TLSv1,!TLSv1.1,!SSLv3
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_received_header = yes
tls_preempt_cipherlist = yes
tls_medium_cipherlist = AES256+EECDH:AES256+EDH

No sé dónde está el problema, porque regularmente recibo correos de otros. No hay errores al conectarse al puerto 25 a través de telnet o al puerto 465 a través de openssl

Adición: recibí este correo a cambio de Google:

Delivery to the following recipient failed permanently:

     <removed>

Technical details of permanent failure:
TLS Negotiation failed

----- Original message -----
[...]

¿Tal vez es un problema con mi lista de cifrado?

Respuesta a la pregunta de masegaloeh:

openssl s_client -connect localhost:25 -starttls smtp
CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
[...]
---
Server certificate
-----BEGIN CERTIFICATE-----
[...]
---
No client certificate CA names sent
---
SSL handshake has read 6267 bytes and written 477 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol  : TLSv1.2
Cipher    : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: [...]
Session-ID-ctx:
Master-Key: [...]
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 3600 (seconds)
TLS session ticket: [...]

Compression: 1 (zlib compression)
Start Time: 1418986680
Timeout   : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)

---
250 DSN

Actualización 1: Reeditado mi certificado SSL. Genera todo de la siguiente manera:
openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out server.csr -sha256

Luego creé un nuevo archivo que consta de crty key, después de esto, creé el paquete CA:
cat COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > bundle.crt

Agregué todo a mi configuración de palomar y postfix y reinicié ambos servicios.
Google todavía no puede enviar correos electrónicos a mi servidor, lo que resulta enTLS Negotiation failed

Intenté con otro proveedor de correo (web.de) y el correo se envía.
web.de log:

Dec 19 17:33:15 server postfix/smtpd[14105]: connect from mout.web.de[212.227.15.3]
Dec 19 17:33:15 server postfix/smtpd[14105]: setting up TLS connection from mout.web.de[212.227.15.3]
Dec 19 17:33:15 server postfix/smtpd[14105]: mout.web.de[212.227.15.3]: TLS cipher list "aNULL:-aNULL:ALL:+RC4:@STRENGTH"
Dec 19 17:33:15 server postfix/smtpd[14105]: mout.web.de[212.227.15.3]: save session EA1635ED786AFC2D9C7AB43EF43620A1D9092DC640FDE21C01E7BA25981D2445&s=smtp&l=268439647 to smtpd cache
Dec 19 17:33:15 server postfix/tlsmgr[14107]: put smtpd session id=EA1635ED786AFC2D9C7AB43EF43620A1D9092DC640FDE21C01E7BA25981D2445&s=smtp&l=268439647 [data 127 bytes]
Dec 19 17:33:15 server postfix/tlsmgr[14107]: write smtpd TLS cache entry EA1635ED786AFC2D9C7AB43EF43620A1D9092DC640FDE21C01E7BA25981D2445&s=smtp&l=268439647: time=1419006795 [data 127 bytes]
Dec 19 17:33:15 server postfix/smtpd[14105]: Anonymous TLS connection established from mout.web.de[212.227.15.3]: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Alma:
Después de habilitar TLSv1y TLSv1.1en la smtpd_(mandatory)_protocolssección, todo funciona bien. Gracias masegaloeh !

Dec 20 11:44:46 server postfix/smtpd[31966]: initializing the server-side TLS engine
Dec 20 11:44:46 server postfix/tlsmgr[31968]: open smtpd TLS cache btree:/var/lib/postfix/smtpd_scache
Dec 20 11:44:46 server postfix/tlsmgr[31968]: tlsmgr_cache_run_event: start TLS smtpd session cache cleanup
Dec 20 11:44:46 server postfix/smtpd[31966]: connect from mail-wi0-x235.google.com[2a00:1450:400c:c05::235]
Dec 20 11:44:46 server postfix/smtpd[31966]: setting up TLS connection from mail-wi0-x235.google.com[2a00:1450:400c:c05::235]
Dec 20 11:44:46 server postfix/smtpd[31966]: mail-wi0-x235.google.com[2a00:1450:400c:c05::235]: TLS cipher list "aNULL:-aNULL:ALL:+RC4:@STRENGTH"
Dec 20 11:44:46 server postfix/smtpd[31966]: Anonymous TLS connection established from mail-wi0-x235.google.com[2a00:1450:400c:c05::235]: TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)

¿Cuál es el resultado del comando openssl s_client -connect localhost:25 -starttls smtp?
masegaloeh

Lo agregué a mi pregunta @masegaloeh
Octfx

Esto también me está afectando con exim; gran pregunta
Boyd Stephen Smith Jr.

Esto acaba de comenzar a afectarme, no tenía las líneas tls_protocol en mi main.cf, y el valor predeterminado documentado es solo deshabilitar SSL2 / 3. Sin embargo, la respuesta a continuación solucionó mi problema.
Bwooce

Respuestas:


21

TLDR : sus protocolos TLS son demasiado estrictos porque solo permite la conexión TLSv1.2.

smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols=!SSLv2,!TLSv1,!TLSv1.1,!SSLv3

Y GMAIL envía correos electrónicos a su servidor con el protocolo TLSv1 . Es por eso que la negociación de TLS falla.

La solución obvia es permitir los protocolos TLSv1 y TLSv1.1 y aún deshabilitar los protocolos SSLv2 y SSLv3 (inseguros).


Explicación

Puedo confirmar su caso cuando no recibo correos electrónicos de GMAIL y FACEBOOK través de STARTTLS .

¿Por qué solo GMAIL que no puede enviar correos electrónicos a mi servidor?

Este es el fragmento de registro de correo cuando GMAIL envía un correo electrónico

Dec 19 23:37:47 tls postfix/smtpd[3876]: initializing the server-side TLS engine
Dec 19 23:37:47 tls postfix/smtpd[3876]: connect from mail-wg0-f47.google.com[74.125.82.47]
Dec 19 23:37:48 tls postfix/smtpd[3876]: setting up TLS connection from mail-wg0-f47.google.com[74.125.82.47]
Dec 19 23:37:48 tls postfix/smtpd[3876]: mail-wg0-f47.google.com[74.125.82.47]: TLS cipher list "aNULL:-aNULL:ALL:+RC4:@STRENGTH:!aNULL:!DES:!3DES:!MD5:!DES+MD5:!RC4:!RC4-MD5"
Dec 19 23:37:48 tls postfix/smtpd[3876]: SSL_accept:before/accept initialization
Dec 19 23:37:48 tls postfix/smtpd[3876]: SSL_accept:error in unknown state
Dec 19 23:37:48 tls postfix/smtpd[3876]: SSL_accept error from mail-wg0-f47.google.com[74.125.82.47]: -1
Dec 19 23:37:48 tls postfix/smtpd[3876]: warning: TLS library problem: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:647:
Dec 19 23:37:48 tls postfix/smtpd[3876]: lost connection after STARTTLS from mail-wg0-f47.google.com[74.125.82.47]
Dec 19 23:37:48 tls postfix/smtpd[3876]: disconnect from mail-wg0-f47.google.com[74.125.82.47]

Y este es el fragmento de registro de correo cuando FACEBOOK envía un correo electrónico

Dec 19 23:11:14 tls postfix/smtpd[3844]: initializing the server-side TLS engine
Dec 19 23:11:14 tls postfix/tlsmgr[3846]: open smtpd TLS cache btree:/var/lib/postfix/smtpd_scache
Dec 19 23:11:14 tls postfix/tlsmgr[3846]: tlsmgr_cache_run_event: start TLS smtpd session cache cleanup
Dec 19 23:11:14 tls postfix/smtpd[3844]: connect from outcampmail003.ash2.facebook.com[66.220.155.162]
Dec 19 23:11:14 tls postfix/smtpd[3844]: setting up TLS connection from outcampmail003.ash2.facebook.com[66.220.155.162]
Dec 19 23:11:14 tls postfix/smtpd[3844]: outcampmail003.ash2.facebook.com[66.220.155.162]: TLS cipher list "aNULL:-aNULL:ALL:+RC4:@STRENGTH:!aNULL:!DES:!3DES:!MD5:!DES+MD5:!RC4:!RC4-MD5"
Dec 19 23:11:14 tls postfix/smtpd[3844]: SSL_accept:before/accept initialization
Dec 19 23:11:15 tls postfix/smtpd[3844]: SSL_accept:error in unknown state
Dec 19 23:11:15 tls postfix/smtpd[3844]: SSL_accept error from outcampmail003.ash2.facebook.com[66.220.155.162]: -1
Dec 19 23:11:15 tls postfix/smtpd[3844]: warning: TLS library problem: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:647:
Dec 19 23:11:15 tls postfix/smtpd[3844]: lost connection after STARTTLS from outcampmail003.ash2.facebook.com[66.220.155.162]
Dec 19 23:11:15 tls postfix/smtpd[3844]: disconnect from outcampmail003.ash2.facebook.com[66.220.155.162]
Dec 19 23:11:16 tls postfix/smtpd[3844]: connect from outcampmail004.ash2.facebook.com[66.220.155.163]
Dec 19 23:11:17 tls postfix/smtpd[3844]: 962C281443: client=outcampmail004.ash2.facebook.com[66.220.155.163]
Dec 19 23:11:18 tls postfix/cleanup[3849]: 962C281443: message-id=<722b2b198d163c43d3bf013bdd396817@www.facebook.com>
Dec 19 23:11:18 tls postfix/qmgr[3843]: 962C281443: from=<notification+zj4zc0zzjfac@facebookmail.com>, size=18002, nrcpt=1 (queue active)
Dec 19 23:11:18 tls postfix/local[3850]: 962C281443: to=<root@tls.example.net>, orig_to=<zera@tls.example.net>, relay=local, delay=1.6, delays=1.5/0/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
Dec 19 23:11:18 tls postfix/qmgr[3843]: 962C281443: removed
Dec 19 23:11:24 tls postfix/smtpd[3844]: disconnect from outcampmail004.ash2.facebook.com[66.220.155.163]

Un poco de análisis

  • En el primer fragmento, GMAIL intentará enviar correos electrónicos a través de STARTTLS. Cuando se negocia TLS, se produce algún error, por lo que el servidor GMAIL lo desconecta.Discutiremos por qué se produce el error a continuación.
  • En el segundo fragmento, FACEBOOK tampoco puede enviar correos electrónicos a través de STARTTLS. En el proceso de reserva, FACEBOOK reenvía el correo electrónico con el modo de texto sin formato. En este caso, nuestro servidor lo acepta con gusto.

Entonces, eso explica por qué solo GMAIL no puede enviar correos electrónicos a su servidor. GMAIL no tiene un mecanismo de reserva si falla la negociación de TLS . Otro servidor de correo puede usar un mecanismo de respaldo para garantizar que la entrega del correo electrónico sea exitosa.

Por qué se produce el error de negociación de TLS

Veo una línea interesante de web.de maillog

Dec 19 17:33:15 foxdev postfix/smtpd[14105]: Anonymous TLS connection established from mout.web.de[212.227.15.3]: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Y descubra que especifica esta configuración en main.cf

smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols=!SSLv2,!TLSv1,!TLSv1.1,!SSLv3

Eso significa que su servidor solo acepta conexión TLS cuando se usa TLSv1.2. Aparte de TLSv1.2, su servidor se quejará de error de negociación de TLS.

Si cambio smtpd_tls_(mandatory_)protocolsa !SSLv2,!SSLv3,!TLSv1, el error aún ocurre. Eso significa que GMAIL y FACEBOOK intentarán contactar a su servidor de correo con protocolos distintos a TLSv1.1 y TLSv1.2.

Si cambio smtpd_tls_(mandatory_)protocolsa !SSLv2,!SSLv3, la negociación TLS tendrá éxito. Confirma que GMAIL y FACEBOOK contactarán a su servidor con el protocolo TLSv1

Dec 20 00:21:46 tls postfix/smtpd[4261]: Anonymous TLS connection established from outmail038.prn2.facebook.com[66.220.144.165]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
Dec 20 00:23:00 tls postfix/smtpd[4261]: Anonymous TLS connection established from mail-wi0-f174.google.com[209.85.212.174]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

Otras personas en el foro de FreeBSD también confirman este comportamiento.

Solución

La solución obvia es habilitar TLSv1 y TLSv1.1 en su postfix. Esto asegurará que algunos servidores de correo que no tengan un mecanismo de respaldo, como GMAIL, puedan comunicarse con su servidor.

No sé su razón para deshabilitar el soporte TLSv1 y TLSv1.1, dejando solo el protocolo TLSv1.2. Si se trata de un servidor web y su usuario utilizará solo un navegador moderno, puede deshabilitar TLSv1 en su servidor. Esto es aceptable porque solo un navegador antiguo que no admite el protocolo TLSv1 .


0

Un problema potencial que puedo ver es el uso aparente de un certificado autofirmado según lo informado por OpenSSL:

Verify return code: 19 (self signed certificate in certificate chain)

Si está utilizando un certificado SSL pagado, no debe utilizar un certificado autofirmado.

Verificaría que su archivo PEM contenga su certificado pagado y también verifique que contenga la cadena de certificados completa.


Bueno, el certificado autofirmado es el certificado raíz de la CA que está autofirmado por la CA.
Octfx

¿Quién es tu CA? Si usan certificados autofirmados en su cadena, deberá proporcionar toda la cadena en su archivo .pem.
Craig Watson

Es un certificado de Comodo. No utilizo certificados firmados por mí. Como dijo Comodo firma su certificado de raíz por ellos mismo, que en este caso resulta encode: 19 (self signed certificate)
Octfx

1
No debería recibir un code 19mensaje si su cadena completa está siendo servida. Utilizo un certificado de StartSSL, que da el mismo error en la parte superior del comando, pero como proporciono la cadena completa (incluida la CA raíz) dentro del smtpd_tls_cert_filearchivo PEM, el cliente tiene todos los certificados necesarios para validar la cadena completa .
Craig Watson

Reeditaré mi certificado solo para probarlo. El problema es que no
cambié
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.