Ich kann keine E-Mails von Google Mail empfangen

Vor ein paar Tagen hat Google Mail plötzlich beschlossen, keine Mails mehr an meinen Mailserver zu senden. Ich verwende Postfix und Dovecot mit einem kostenpflichtigen SSL-Zertifikat, das auf Debian 7 läuft, wobei alles aktualisiert ist.

Meine mail.logzeigt den folgenden Fehler:

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]

Auszüge aus meinem 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

Ich weiß nicht, wo das Problem liegt, weil ich regelmäßig Mails von anderen erhalte. Es gibt keine Fehler beim Verbinden mit Port 25 über Telnet oder Port 465 über OpenSSL

Zusatz: Ich habe diese E-Mail als Antwort von Google erhalten:

Delivery to the following recipient failed permanently:

     <removed>

Technical details of permanent failure:
TLS Negotiation failed

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

Vielleicht ist es ein Problem mit meiner Chiffrierliste?

Antwort auf die Frage von 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

Update 1: Mein SSL-Zertifikat wurde erneut ausgegeben. Erzeugte alles wie folgt:
openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out server.csr -sha256

Ich habe dann eine neue Datei erstellt, bestehend aus crtund key, danach habe ich das CA-Bundle erstellt:
cat COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > bundle.crt

Fügte alles zu meiner Dovecot- und Postfix-Konfiguration hinzu und startete beide Dienste neu.
Google noch nicht Mails zo mein Server in resultierenden schickenTLS Negotiation failed

Ich habe einen anderen Mail-Provider (web.de) ausprobiert und die Mail wird gesendet.
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)

Soultion:
Nach dem Aktivieren TLSv1und TLSv1.1im smtpd_(mandatory)_protocolsAbschnitt funktioniert alles gut. Danke 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
quelle

Was ist die Ausgabe des Befehls openssl s_client -connect localhost:25 -starttls smtp?

— Masegaloeh

Fügte es zu meiner Frage @masegaloeh

— Octfx

Das trifft mich auch mit Exim; tolle frage.

— Boyd Stephen Smith Jr.

Das hat mich gerade betroffen gemacht, ich hatte keine tls_protocol-Zeilen in meiner main.cf und der dokumentierte Standard ist, nur SSL2 / 3 zu deaktivieren. Die Antwort unten hat jedoch mein Problem behoben.

— Bwooce

Antworten:

TLDR : Ihre TLS-Protokolle sind zu streng, da Sie nur TLSv1.2-Verbindungen zulassen.

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

Und GMAIL sendet E-Mails mit dem TLSv1-Protokoll an Ihren Server . Aus diesem Grund schlägt die TLS-Aushandlung fehl.

Die naheliegende Lösung besteht darin, die Protokolle TLSv1 und TLSv1.1 zuzulassen und weiterhin die (unsicheren) SSLv2- und SSLv3-Protokolle zu deaktivieren.

Erläuterung

Ich kann Ihren Fall bestätigen, wenn ich keine E-Mails von GMAIL und FACEBOOK über STARTTLS erhalten habe .

Warum nur GMAIL, der keine E-Mails an meinen Server sendet

Dies ist das Mailing-Snippet, wenn GMAIL eine E-Mail sendet

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]

Und dies ist das Mailing-Snippet, wenn FACEBOOK eine E-Mail sendet

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]

Einige Analysen

Im ersten Snippet versucht GMAIL, E-Mails über STARTTLS zu senden. Bei der TLS-Aushandlung tritt ein Fehler auf, sodass der GMAIL-Server die Verbindung trennt. Wir werden im Folgenden erläutern, warum der Fehler auftritt.
Im zweiten Snippet kann FACEBOOK auch keine E-Mails über STARTTLS senden. Im Fallback-Prozess sendet FACEBOOK E-Mails im Nur-Text-Modus erneut. In diesem Fall nimmt unser Server dies gerne an.

Das erklärt, warum nur GMAIL keine E-Mails an Ihren Server senden kann. GMAIL verfügt nicht über einen Mechanismus zum Zurückgreifen, wenn die TLS-Aushandlung fehlschlägt . Andere Mail-Server verwenden möglicherweise einen Fallback-Mechanismus, um sicherzustellen, dass die E-Mail-Zustellung erfolgreich ist.

Warum TLS-Aushandlungsfehler auftritt

Ich finde interessante Zeilen von 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)

Und finden Sie heraus, dass Sie diese Konfiguration in angeben main.cf

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

Das bedeutet, dass Ihr Server nur TLS-Verbindungen akzeptiert , wenn TLSv1.2 verwendet wird. Anders als TLSv1.2 wird Ihr Server einen TLS-Aushandlungsfehler beklagen.

Wenn ich zu ändere smtpd_tls_(mandatory_)protocols, !SSLv2,!SSLv3,!TLSv1tritt der Fehler weiterhin auf. Dies bedeutet, dass GMAIL und FACEBOOK versuchen, Ihren Mailserver mit anderen Protokollen als TLSv1.1 und TLSv1.2 zu kontaktieren.

Wenn ich zu ändere smtpd_tls_(mandatory_)protocols, !SSLv2,!SSLv3wird die TLS-Aushandlung erfolgreich sein. Es wird bestätigt, dass GMAIL und FACEBOOK Ihren Server mit dem TLSv1-Protokoll kontaktieren

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)

Andere Leute im FreeBSD-Forum bestätigen dieses Verhalten ebenfalls.

Lösung

Die naheliegende Lösung ist, TLSv1 und TLSv1.1 in Ihrem Postfix zu aktivieren. Dadurch wird sichergestellt, dass einige Mailserver, die nicht über einen Fallback-Mechanismus verfügen, wie z. B. GMAIL, weiterhin mit Ihrem Server kommunizieren können.

Ich kenne Ihren Grund nicht, die TLSv1- und TLSv1.1-Unterstützung zu deaktivieren und nur das TLSv1.2-Protokoll zu belassen. Wenn es sich um einen Webserver handelt und Ihr Benutzer nur einen modernen Browser verwendet, können Sie TLSv1 auf Ihrem Server deaktivieren. Dies ist akzeptabel, da nur ältere Browser das Protokoll TLSv1 nicht unterstützen .

— masegaloeh
quelle

Ein mögliches Problem, das ich sehen kann, ist die offensichtliche Verwendung eines selbstsignierten Zertifikats, wie von OpenSSL gemeldet:

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

Wenn Sie ein kostenpflichtiges SSL-Zertifikat verwenden, sollten Sie kein selbstsigniertes Zertifikat verwenden.

Ich würde überprüfen, ob Ihre PEM-Datei Ihr bezahltes Zertifikat enthält, und sicherstellen, dass sie die vollständige Zertifikatskette enthält.

— Craig Watson
quelle

Nun, das selbstsignierte Zertifikat ist das Stammzertifikat der Zertifizierungsstelle, das von der Zertifizierungsstelle selbstsigniert wurde.

— 19.

Wer ist deine CA? Wenn sie selbstsignierte Zertifikate in ihrer Kette verwenden, müssen Sie die gesamte Kette in Ihrer PEM-Datei angeben.

— Craig Watson

Es ist ein Zertifikat von Comodo. Ich verwende keine von mir signierten Zertifikate. Wie bereits erwähnt, signiert Comodo ihr Root-Zertifikat selbst, was in diesem Fall zucode: 19 (self signed certificate)

— Octfx

Sie sollten keine code 19Nachricht erhalten, wenn Ihre gesamte Kette bedient wird. Ich verwende ein Zertifikat von StartSSL, das am Anfang des Befehls denselben Fehler ausgibt, aber da ich die vollständige Kette (einschließlich der Stammzertifizierungsstelle) in der smtpd_tls_cert_filePEM-Datei bereitstelle , verfügt der Client über alle zum Überprüfen der vollständigen Kette erforderlichen Zertifikate .

— Craig Watson

Ich werde mein Zertifikat erneut ausstellen, um es zu testen. Das Problem ist, dass ich nichts geändert habe, Google kann mir einfach keine Mails mehr

— zustellen