Nie można odbierać wiadomości e-mail z Gmaila

15

Kilka dni temu Gmail nagle postanowił przestać wysyłać wiadomości na mój serwer pocztowy. Używam Postfix i Dovecot z płatnym certyfikatem SSL działającym na Debian 7 ze wszystkim zaktualizowanym.

Mój mail.logpokazuje następujący błąd:

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]

fragmenty mojego postfiksa 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

Nie wiem, na czym polega problem, ponieważ regularnie otrzymuję maile od innych. Nie ma błędów podczas łączenia z portem 25 przez telnet lub portem 465 przez openssl

Dodatek: otrzymałem tę wiadomość w zamian od Google:

Delivery to the following recipient failed permanently:

     <removed>

Technical details of permanent failure:
TLS Negotiation failed

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

Może to problem z moją listą szyfrów?

Odpowiedz na pytanie 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

Aktualizacja 1: Wydałem ponownie mój certyfikat SSL. Wygenerowano wszystko w następujący sposób:
openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out server.csr -sha256

Następnie utworzyłem nowy plik składający się z crti key, a następnie utworzyłem pakiet CA:
cat COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > bundle.crt

Dodałem wszystko do mojej konfiguracji dovecot i Postfix i zrestartowałem obie usługi.
Google nadal nie wysyła wiadomości e-mail z mojego serwera, co powodujeTLS Negotiation failed

Wypróbowałem innego dostawcę poczty (web.de) i wiadomość została wysłana.
dziennik 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:
Po włączeniu TLSv1i TLSv1.1na smtpd_(mandatory)_protocolsgrzywny Dostawy SEKCJA wszystko. Dzięki 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)
postfix  dovecot 
— Octfx
źródło
Jaka jest wydajność polecenia openssl s_client -connect localhost:25 -starttls smtp?
— masegaloeh
Dodałem go do mojego pytania @masegaloeh
— Octfx
Wpływa to również na mnie exim; świetne pytanie.
— Boyd Stephen Smith Jr.,
To właśnie zaczęło na mnie wpływać, nie miałem linii tls_protocol w main.cf, a udokumentowane domyślne ustawienie to wyłączenie SSL2 / 3. Jednak poniższa odpowiedź rozwiązała mój problem.
— Bwooce,

Odpowiedzi:

21

TLDR : Twoje protokoły TLS są zbyt surowe, ponieważ zezwalasz tylko na połączenie TLSv1.2.

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

A GMAIL wysyła wiadomość e-mail na Twój serwer za pomocą protokołu TLSv1 . Dlatego negocjacja TLS kończy się niepowodzeniem.

Oczywistym rozwiązaniem jest zezwolenie na protokoły TLSv1 i TLSv1.1 oraz nadal wyłączanie (niepewnych) protokołów SSLv2 i SSLv3.

Wyjaśnienie

Mogę potwierdzić Twoją sprawę, gdy nie otrzymuję wiadomości e-mail od GMAIL i FACEBOOK przez STARTTLS .

Dlaczego tylko GMAIL, który nie wysyła wiadomości e-mail na mój serwer

To fragment kodu maillog, gdy GMAIL wysyła wiadomość 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]

I to jest fragment maillog, gdy FACEBOOK wysyła 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]

Trochę analizy

  • W pierwszym fragmencie GMAIL spróbuje wysłać wiadomość e-mail przez STARTTLS. Podczas negocjacji TLS pojawia się błąd, więc serwer GMAIL rozłącz go. Omówimy, dlaczego błąd występuje poniżej.
  • W drugim fragmencie FACEBOOK również nie wysyła wiadomości e-mail przez STARTTLS. W procesie rezerwowym FACEBOOK ponownie wysyła wiadomość e-mail w trybie zwykłego tekstu. W takim przypadku nasz serwer chętnie to zaakceptuje.

To wyjaśnia, dlaczego tylko GMAIL nie wysyła wiadomości e-mail na Twój serwer. GMAIL nie ma mechanizmu awaryjnego, jeśli negocjacja TLS nie powiedzie się . Inny serwer pocztowy może korzystać z mechanizmu awaryjnego, aby zapewnić pomyślne dostarczenie wiadomości e-mail.

Dlaczego występuje błąd negocjacji TLS

Dostrzegam ciekawą linię z 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)

I dowiedz się, że określasz tę konfigurację w main.cf

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

Oznacza to, że Twój serwer akceptuje połączenie TLS tylko wtedy, gdy używany jest TLSv1.2. Inny niż TLSv1.2, twój serwer będzie narzekał na błąd negocjacji TLS.

Jeśli zmienię smtpd_tls_(mandatory_)protocolsna !SSLv2,!SSLv3,!TLSv1, błąd nadal występuje. Oznacza to, że GMAIL i FACEBOOK spróbują skontaktować się z Twoim serwerem pocztowym przy użyciu protokołów innych niż TLSv1.1 i TLSv1.2.

Jeśli zmienię smtpd_tls_(mandatory_)protocolsna !SSLv2,!SSLv3, negocjacje TLS zakończą się powodzeniem. Potwierdza, że ​​GMAIL i FACEBOOK skontaktują się z Twoim serwerem za pomocą protokołu 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)

Inni ludzie na forum FreeBSD również potwierdzają to zachowanie.

Rozwiązanie

Oczywistym rozwiązaniem jest włączenie TLSv1 i TLSv1.1 w Postfiksie. Zapewni to, że niektóre serwery pocztowe, które nie mają mechanizmu awaryjnego - takie jak GMAIL - będą mogły nadal komunikować się z twoim serwerem.

Nie znam Twojego powodu, aby wyłączyć obsługę TLSv1 i TLSv1.1, pozostawiając tylko protokół TLSv1.2. Jeśli jest to serwer sieciowy, a użytkownik będzie korzystał tylko z nowoczesnej przeglądarki, możesz wyłączyć protokół TLSv1 na serwerze. Jest to dopuszczalne, ponieważ tylko starsza przeglądarka, która nie obsługuje protokołu TLSv1 .

— masegaloeh
źródło
0

Jednym z potencjalnych problemów, które widzę, jest oczywiste użycie certyfikatu z podpisem własnym, zgłoszonego przez OpenSSL:

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

Jeśli korzystasz z płatnego certyfikatu SSL, nie powinieneś używać certyfikatu z podpisem własnym.

Sprawdziłbym, czy plik PEM zawiera płatny certyfikat, a także czy zawiera pełny łańcuch certyfikatów.

— Craig Watson
źródło
Cóż, samopodpisany certyfikat jest certyfikatem głównym z urzędu certyfikacji, który jest samopodpisany przez urząd certyfikacji.
— Octfx,
Kto jest twoim CA? Jeśli używają w swoim łańcuchu certyfikatów z podpisem własnym, musisz podać cały łańcuch w pliku .pem.
— Craig Watson
Jest to certyfikat Comodo. Nie używam podpisanych przez siebie certyfikatów. Jak powiedział Comodo, podpisuje swoje własne certyfikaty root, co w tym przypadku powodujecode: 19 (self signed certificate)
— Octfx
1
Nie powinieneś otrzymywać code 19wiadomości, jeśli Twój pełny łańcuch jest obsługiwany. Korzystam z certyfikatu StartSSL, który daje ten sam błąd w górnej części polecenia, ale ponieważ zapewniam pełny łańcuch (w tym główny urząd certyfikacji) w smtpd_tls_cert_filepliku PEM, klient ma wszystkie certyfikaty niezbędne do zweryfikowania pełnego łańcucha .
— Craig Watson,
Ponownie wystawię mój certyfikat, aby go przetestować. Problem polega na tym, że nic nie zmieniłem, Google po prostu nie może już dostarczać do mnie e-maili
— Octfx
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.