Не вдається отримати пошту від Gmail

15

Кілька днів тому Gmail раптом вирішив припинити надсилати пошту моєму поштовому серверу. Я використовую Postfix та Dovecot із платним SSL-сертифікатом, який працює на Debian 7 із усім оновленим.

Моя mail.logпоказує таку помилку:

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]

витяги з мого постфіксу 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

Я не знаю, де проблема, тому що я регулярно отримую листи від інших. Немає помилок підключення до порту 25 через telnet або порт 465 через openssl

Доповнення: я отримав цей лист взамін від Google:

Delivery to the following recipient failed permanently:

     <removed>

Technical details of permanent failure:
TLS Negotiation failed

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

Можливо, це проблема з моїм шифрованим списком?

Відповідь на питання 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

Оновлення 1: Перевидано мій сертифікат SSL. Згенеровано все так:
openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out server.csr -sha256

Потім я створив новий файл, що складається з crtі key, після цього я створив пакет CA:
cat COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > bundle.crt

Додав усе до мого конфігурації dovecot та postfix та перезапустив обидві служби.
Google все ще не в змозі надсилати пошту zo моєму серверу, в результаті чогоTLS Negotiation failed

Я спробував іншого постачальника пошти (web.de), і пошту надсилають.
журнал 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)

Душа:
Після включення TLSv1і TLSv1.1в smtpd_(mandatory)_protocolsрозділі все працює добре. Дякую 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
джерело
Який вихід команди openssl s_client -connect localhost:25 -starttls smtp?
— masegaloeh
Додав його до мого запитання @masegaloeh
— жовтня
Це також впливає на мене exim; велике запитання.
— Бойд Стівен Сміт-молодший
Це щойно почало впливати на мене, у мене не було рядків tls_protocol в моєму main.cf, і задокументованим за замовчуванням є лише відключення SSL2 / 3. Однак відповідь нижче вирішив мою проблему.
— Bwooce

Відповіді:

21

TLDR : Ваші протоколи TLS занадто суворі, тому що ви дозволяєте підключати лише TLSv1.2.

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

І GMAIL надсилає електронний лист на ваш сервер за допомогою протоколу TLSv1 . Ось чому узгодження TLS не вдається.

Очевидним рішенням є дозвіл на протоколи TLSv1 і TLSv1.1 та все ще відключення (незахищеність) протоколів SSLv2 та SSLv3.

Пояснення

Я можу підтвердити ваш випадок, коли не отримуєте електронну пошту від GMAIL та FACEBOOK через STARTTLS .

Чому тільки GMAIL, який не може надіслати електронний лист на мій сервер

Це фрагмент поштового журналу, коли GMAIL надсилає електронне повідомлення

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]

І це фрагмент поштового журналу, коли FACEBOOK надсилає електронне повідомлення

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]

Деякий аналіз

  • У першому фрагменті GMAIL спробує надіслати електронну пошту через STARTTLS. Під час узгодження TLS виникає деяка помилка, тому сервер GMAIL відключає її. Ми обговоримо, чому помилка виникає нижче.
  • У другому фрагменті FACEBOOK також не в змозі надіслати електронну пошту через STARTTLS. У процесі резервного копіювання FACEBOOK надсилає електронне повідомлення у звичайному текстовому режимі. У цьому випадку наш сервер із задоволенням приймає це.

Отже, це поясніть, чому лише GMAIL не надсилає електронну пошту на ваш сервер. GMAIL не має механізму відшкодування, якщо TLS-переговори не вдаються . Інший поштовий сервер може використовувати механізм резервного копіювання, щоб забезпечити успіх доставки електронної пошти.

Чому виникає помилка переговорів щодо TLS

Я помічаю цікавий рядок із 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)

І з’ясуйте, що ви вказали цю конфігурацію в main.cf

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

Це означає, що ваш сервер приймає TLS-з'єднання лише тоді, коли використовується TLSv1.2. Крім TLSv1.2, ваш сервер скаржиться на помилку узгодження TLS.

Якщо я перейду smtpd_tls_(mandatory_)protocolsдо !SSLv2,!SSLv3,!TLSv1, помилка все-таки виникає. Це означає, що GMAIL та FACEBOOK намагатимуться зв’язатися з вашим поштовим сервером з протоколами, відмінними від TLSv1.1 та TLSv1.2.

Якщо я змінюю smtpd_tls_(mandatory_)protocolsдо !SSLv2,!SSLv3, TLS переговорний успіх. Це підтверджує, що GMAIL та FACEBOOK зв’язуються з вашим сервером за допомогою протоколу 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)

Інші люди на форумі FreeBSD також підтверджують цю поведінку.

Рішення

Очевидним рішенням є включення TLSv1 та TLSv1.1 у вашому Postfix. Це забезпечить деякий поштовий сервер, який не має механізму резервного резервування, як-от GMAIL, все ще може спілкуватися з вашим сервером.

Я не знаю вашої причини відключити підтримку TLSv1 і TLSv1.1, залишивши лише протокол TLSv1.2. Якщо це веб-сервер і ваш користувач використовуватиме лише сучасний браузер, то ви можете відключити TLSv1 на своєму сервері. Це прийнятно, оскільки лише старший браузер, який не підтримує протокол TLSv1 .

— масегалое
джерело
0

Одне з можливих проблем, яке я бачу, - це очевидне використання самопідписаного сертифіката, як повідомляє OpenSSL:

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

Якщо ви використовуєте платний сертифікат SSL, ви не повинні використовувати cert, який підписує самостійно.

Я перевірив би, чи ваш файл PEM містить ваш платний сертифікат, а також переконався, що він містить повний ланцюжок сертифікатів.

— Крейг Уотсон
джерело
Добре самопідписаний сертифікат - це кореневий сертифікат від КА, який підписується власною службою.
— Octfx
Хто ваш КА? Якщо вони використовують самопідписані сертифікати у своєму ланцюжку, вам потрібно буде вказати весь ланцюжок у вашому файлі .pem.
— Крейг Уотсон
Це сертифікат від Comodo. Я не використовую підписані мною сертифікати. Як було сказано, Комодо підписує свою кореневу верхівку самим собою, що в цьому випадку призводить доcode: 19 (self signed certificate)
— Octfx
1
Ви не повинні отримувати code 19повідомлення, якщо ваш повний ланцюг обслуговується. Я використовую cert з StartSSL, який дає ту саму помилку у верхній частині команди, але оскільки я надаю повний ланцюжок (включаючи кореневий CA) у smtpd_tls_cert_fileфайлі PEM, клієнт має всі сертифікати, необхідні для перевірки повного ланцюжка .
— Крейг Уотсон
Я вийду зі свого серта лише для того, щоб перевірити його. Проблема полягає в тому, що я нічого не змінив, Google просто більше не може надсилати мені пошту
— Octfx
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.