Non riesco a ricevere mail da Gmail


15

Qualche giorno fa Gmail ha improvvisamente deciso di interrompere l'invio di posta al mio server di posta. Sto usando Postfix e Dovecot con un certificato SSL a pagamento in esecuzione su Debian 7 con tutto aggiornato.

Il mio mail.logmostra il seguente errore:

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]

estratti dal mio 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

Non so dove sia il problema, perché ricevo regolarmente mail da altri. Non ci sono errori nel collegamento alla porta 25 tramite telnet o alla porta 465 tramite openssl

Aggiunta: ho ricevuto questa mail in cambio di Google:

Delivery to the following recipient failed permanently:

     <removed>

Technical details of permanent failure:
TLS Negotiation failed

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

Forse è un problema con la mia lista cifrata?

Risposta alla domanda di 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

Aggiornamento 1: riemesso il mio certificato SSL. Generato tutto come segue:
openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out server.csr -sha256

Ho quindi creato un nuovo file costituito da crte il key, dopo questo ho creato il bundle CA:
cat COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > bundle.crt

Aggiunto tutto alla mia configurazione dovecot e postfix e riavviato entrambi i servizi.
Google non riesce ancora a inviare e-mail sul mio serverTLS Negotiation failed

Ho provato un altro provider di posta (web.de) e la posta viene inviata.
registro web.de:

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)

Soultion:
dopo aver abilitato TLSv1e TLSv1.1nella smtpd_(mandatory)_protocolssezione tutto funziona bene. Grazie 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)

Qual è l'output del comando openssl s_client -connect localhost:25 -starttls smtp?
Masegaloeh,

Aggiunto alla mia domanda @masegaloeh
Octfx

Questo mi sta colpendo anche con exim; ottima domanda.
Boyd Stephen Smith Jr.

Questo ha iniziato a interessarmi, non avevo le righe tls_protocol nel mio main.cf e il valore predefinito documentato è disabilitare solo SSL2 / 3. Tuttavia, la risposta di seguito ha risolto il mio problema.
Bwooce,

Risposte:


21

TLDR : i protocolli TLS sono troppo rigidi perché consenti solo la connessione TLSv1.2.

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

E GMAIL invia e-mail al tuo server con protocollo TLSv1 . Ecco perché la negoziazione TLS fallisce.

La soluzione ovvia è consentire i protocolli TLSv1 e TLSv1.1 e ancora disabilitare i protocolli SSLv2 e SSLv3 (non sicuri).


Spiegazione

Posso confermare il tuo caso in caso di mancata ricezione di e-mail da GMAIL e FACEBOOK su STARTTLS .

Perché solo GMAIL che non riesce a inviare e-mail al mio server

Questo è lo snippet maillog quando GMAIL invia e-mail

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]

E questo è lo snippet maillog quando FACEBOOK invia e-mail

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]

Qualche analisi

  • Nel primo frammento, GMAIL tenterà di inviare e-mail su STARTTLS. Durante la negoziazione TLS, si verifica un errore, quindi il server GMAIL lo disconnette. Discuteremo perché l'errore si verifica di seguito.
  • Nel secondo frammento, anche FACEBOOK non riesce a inviare e-mail su STARTTLS. Nel processo di fallback, FACEBOOK reinvia l'e-mail con la modalità testo normale. In questo caso il nostro server lo accetta felicemente.

Quindi, questo spiega perché solo GMAIL non riesce a inviare e-mail al tuo server. GMAIL non ha un meccanismo di fallback se la negoziazione TLS fallisce . Altri server di posta possono utilizzare il meccanismo di fallback per garantire il corretto recapito della posta.

Perché si verifica un errore di negoziazione TLS

Individuo una linea interessante dal maillog di web.de

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)

E scopri che hai specificato questa configurazione in main.cf

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

Ciò significa che il tuo server accetta la connessione TLS solo quando TLSv1.2 è stato utilizzato. Oltre a TLSv1.2, il server lamenterà un errore di negoziazione TLS.

Se cambio smtpd_tls_(mandatory_)protocolsa !SSLv2,!SSLv3,!TLSv1, l'errore si verifica ancora. Ciò significa che GMAIL e FACEBOOK tenteranno di contattare il proprio server di posta con protocolli diversi da TLSv1.1 e TLSv1.2.

Se cambio smtpd_tls_(mandatory_)protocolsa !SSLv2,!SSLv3, la negoziazione TLS avrà successo. Conferma che GMAIL e FACEBOOK contatteranno il tuo server con protocollo 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)

Anche altre persone nel forum di FreeBSD confermano questo comportamento.

Soluzione

La soluzione ovvia è abilitare TLSv1 e TLSv1.1 nel tuo postfisso. Ciò garantirà che alcuni server di posta che non dispongono di un meccanismo di fallback - come GMAIL - possano comunque comunicare con il tuo server.

Non conosco il motivo per disabilitare il supporto TLSv1 e TLSv1.1, lasciando solo il protocollo TLSv1.2. Se si tratta di un server web e l'utente utilizzerà solo il browser moderno, è possibile disabilitare TLSv1 nel server. Questo è accettabile perché solo un browser meno recente che non supporta il protocollo TLSv1 .


0

Un potenziale problema che posso vedere è l'uso apparente di un certificato autofirmato come riportato da OpenSSL:

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

Se stai utilizzando un certificato SSL a pagamento, non dovresti utilizzare un certificato autofirmato.

Verificherei che il tuo file PEM contenga il tuo certificato a pagamento e verificherei anche che contenga l'intera catena di certificati.


Bene, il certificato autofirmato è il certificato radice della CA che è autofirmato dalla CA.
Ottfx

Chi è la tua CA? Se usano certificati autofirmati nella loro catena, dovrai fornire l'intera catena nel tuo file .pem.
Craig Watson,

È un certificato di Comodo. Non utilizzo certificati firmati da me. Come detto Comodo firma da solo il loro certificato di radice che in questo caso si traduce incode: 19 (self signed certificate)
Octfx

1
Non dovresti ricevere un code 19messaggio se viene servita l'intera catena. Uso un certificato da StartSSL, che fornisce lo stesso errore nella parte superiore del comando, ma poiché fornisco la catena completa (compresa la CA principale) all'interno del smtpd_tls_cert_filefile PEM, il client dispone di tutti i certificati necessari per convalidare la catena completa .
Craig Watson,

Emetterò nuovamente il mio certificato solo per testarlo. Il problema è che non ho cambiato nulla, google non può più
inviarmi e
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.