Não é possível receber e-mails do Gmail

15

Alguns dias atrás, o Gmail decidiu parar de enviar e-mails para o meu servidor de e-mail. Estou usando Postfix e Dovecot com um certificado SSL pago em execução no Debian 7 com tudo atualizado.

Meu mail.logmostra o seguinte erro:

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]

trechos do meu 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

Não sei onde está o problema, porque recebo e-mails regularmente de outras pessoas. Não há erros ao conectar à porta 25 via telnet ou à porta 465 via openssl

Adição: recebi este e-mail em troca do Google:

Delivery to the following recipient failed permanently:

     <removed>

Technical details of permanent failure:
TLS Negotiation failed

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

Talvez seja um problema com minha lista de códigos?

Resposta à pergunta 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

Atualização 1: Emitiu novamente meu certificado SSL. Gerou tudo da seguinte maneira:
openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out server.csr -sha256

Em seguida, criei um novo arquivo que consiste em crte key, depois disso, criei o pacote CA:
cat COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > bundle.crt

Adicionado tudo à minha configuração dovecot e postfix e reiniciei os dois serviços.
O Google ainda não envia e-mails para o meu servidor, resultando emTLS Negotiation failed

Tentei outro provedor de email (web.de) e o email é enviado.
log 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:
Após ativar TLSv1e TLSv1.1na smtpd_(mandatory)_protocolsseção tudo funciona bem. Obrigado 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)
Octfx
fonte
Qual é a saída do comando openssl s_client -connect localhost:25 -starttls smtp?
masegaloeh
Adicionei à minha pergunta @masegaloeh
Octfx
Isso também está me afetando com o exim; ótima pergunta.
Boyd Stephen Smith Jr.
Isso começou a me afetar, eu não tinha as linhas tls_protocol no meu main.cf e o padrão documentado é desativar apenas o SSL2 / 3. No entanto, a resposta abaixo corrigiu o meu problema.
Bwooce

Respostas:

21

TLDR : seus protocolos TLS são muito rigorosos porque você permite apenas a conexão TLSv1.2.

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

E o GMAIL envia email para o seu servidor com o protocolo TLSv1 . É por isso que a negociação TLS falha.

A solução óbvia é permitir os protocolos TLSv1 e TLSv1.1 e ainda desativar os protocolos SSLv2 e SSLv3 (inseguros).


Explicação

Posso confirmar seu caso ao não receber e-mails do GMAIL e do FACEBOOK pelo STARTTLS .

Por que apenas o GMAIL que não envia e-mails para o meu servidor

Esse é o snippet do maillog quando o GMAIL envia um email

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 este é o snippet do maillog quando o FACEBOOK envia um email

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=<[email protected]>
Dec 19 23:11:18 tls postfix/qmgr[3843]: 962C281443: from=<[email protected]>, size=18002, nrcpt=1 (queue active)
Dec 19 23:11:18 tls postfix/local[3850]: 962C281443: to=<[email protected]>, orig_to=<[email protected]>, 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]

Alguma análise

  • No primeiro trecho, o GMAIL tentará enviar e-mail por STARTTLS. Quando a negociação TLS ocorre, ocorre algum erro; portanto, o servidor GMAIL o desconecta. Discutiremos por que o erro está ocorrendo abaixo.
  • No segundo snippet, o FACEBOOK também falha ao enviar e-mail por STARTTLS. No processo de fallback, o FACEBOOK reenvia o email com o modo de texto sem formatação. Nesse caso, nosso servidor aceita com satisfação.

Então, isso explica por que apenas o GMAIL falha ao enviar email para o servidor. O GMAIL não tem mecanismo de fallback se a negociação do TLS falhar . Outro servidor de email pode usar o mecanismo de fallback para garantir a entrega do email com êxito.

Por que ocorre o erro de negociação TLS

Vejo uma linha interessante do 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)

E descubra que você especifica essa configuração em main.cf

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

Isso significa que seu servidor só aceita conexão TLS quando o TLSv1.2 é usado. Além do TLSv1.2, seu servidor reclamará de um erro de negociação do TLS.

Se eu mudar smtpd_tls_(mandatory_)protocolspara !SSLv2,!SSLv3,!TLSv1, o erro ainda ocorrerá. Isso significa que o GMAIL e o FACEBOOK tentarão entrar em contato com o servidor de correio com protocolos diferentes do TLSv1.1 e TLSv1.2.

Se eu mudar smtpd_tls_(mandatory_)protocolspara !SSLv2,!SSLv3, a negociação TLS será bem-sucedida. Ele confirma que o GMAIL e o FACEBOOK entrarão em contato com o servidor com o 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)

Outras pessoas no fórum FreeBSD também confirmam esse comportamento.

Solução

A solução óbvia é ativar o TLSv1 e o TLSv1.1 no seu postfix. Isso garantirá que alguns servidores de email que não possuem mecanismo de fallback - como o GMAIL - ainda possam se comunicar com o servidor.

Não sei seu motivo para desativar o suporte ao TLSv1 e TLSv1.1, deixando apenas o protocolo TLSv1.2. Se for um servidor da Web e seu usuário usar apenas o navegador moderno, você poderá desativar o TLSv1 no seu servidor. Isso é aceitável porque apenas o navegador mais antigo que não suporta o protocolo TLSv1 .

masegaloeh
fonte
0

Um possível problema que vejo é o uso aparente de um certificado autoassinado, conforme relatado pelo OpenSSL:

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

Se você estiver usando um certificado SSL pago, não deverá usar um certificado autoassinado.

Eu verificaria se seu arquivo PEM contém seu certificado pago e também se ele contém toda a cadeia de certificados.

Craig Watson
fonte
Bem, o certificado autoassinado é o certificado raiz da CA, que é autoassinado pela CA.
Octfx
Quem é seu CA? Se eles usarem certificados autoassinados em sua cadeia, você precisará fornecer toda a cadeia em seu arquivo .pem.
Craig Watson
É um certificado da Comodo. Eu não uso certificados assinados por mim. Como dito, a Comodo assina seu certificado de raiz por eles mesmos, o que, nesse caso, resulta em:code: 19 (self signed certificate)
Octfx 19/12/14
1
Você não deve receber uma code 19mensagem se sua cadeia completa estiver sendo veiculada. Uso um certificado do StartSSL, que fornece o mesmo erro na parte superior do comando, mas como forneço a cadeia completa (incluindo a CA raiz) no smtpd_tls_cert_filearquivo PEM, o cliente possui todos os certificados necessários para validar a cadeia completa .
Craig Watson
Vou reemitir meu certificado apenas para testá-lo. O problema é que eu não mudar nada, o Google simplesmente não pode entregar e-mails para mais de mim
Octfx