exim4: Проблемы с TLS при попытке получения писем с *.outbound.protection.outlook.com

[ladserg]

Стоит exim, настроен, работает. TLS тоже работает. Но при попытке получить письмо с серверов Microsoft устанавливаются множественные конекты с их MTA, после чего некоторое время коннекты висят и затем отпадывают с выдачей ошибки.

Пример сообщений лога:

2018-01-23 16:32:23 [9336] SMTP connection from [104.47.42.74]:18608 I=[46.146.239.184]:25 (TCP/IP connection count = 1)
2018-01-23 16:45:05 [9377] TLS error on connection from mail-by2nam03on0074.outbound.protection.outlook.com (NAM03-BY2-obe.outbound.protection.outlook.com) [104.47.42.74]:18608 I=[46.146.239.184]:25 (send): Error in the push function.
2018-01-23 16:45:05 [9377] TLS error on connection from mail-by2nam03on0074.outbound.protection.outlook.com (NAM03-BY2-obe.outbound.protection.outlook.com) [104.47.42.74]:18608 I=[46.146.239.184]:25 (recv): The TLS connection was non-properly terminated.
2018-01-23 16:45:05 [9377] H=mail-by2nam03on0074.outbound.protection.outlook.com (NAM03-BY2-obe.outbound.protection.outlook.com) [104.47.42.74]:18608 I=[46.146.239.184]:25 incomplete transaction (connection lost) from <account-security-noreply@accountprotection.microsoft.com> for **@***.***.**
2018-01-23 16:45:05 [9377] TLS error on connection from mail-by2nam03on0074.outbound.protection.outlook.com (NAM03-BY2-obe.outbound.protection.outlook.com) [104.47.42.74]:18608 I=[46.146.239.184]:25 (send): The specified session has been invalidated for some reason.
2018-01-23 16:45:05 [9377] unexpected disconnection while reading SMTP command from mail-by2nam03on0074.outbound.protection.outlook.com (NAM03-BY2-obe.outbound.protection.outlook.com) [104.47.42.74]:18608 I=[46.146.239.184]:25

Команда exiwhat во время попыток доставки следующее:

9336 daemon(4.89): -q30m, listening for SMTP on port 25 (IPv4) and for SMTPS on port 465 (IPv4) port 587 (IPv4)
12276 handling TLS incoming connection from mail-dm3nam03on0076.outbound.protection.outlook.com (NAM03-DM3-obe.outbound.protection.outlook.com) [104.47.41.76]:59392 I=[46.146.239.184]:25
12279 handling TLS incoming connection from mail-co1nam03on0058.outbound.protection.outlook.com (NAM03-CO1-obe.outbound.protection.outlook.com) [104.47.40.58]:61192 I=[46.146.239.184]:25
12280 handling TLS incoming connection from mail-by2nam03on0053.outbound.protection.outlook.com (NAM03-BY2-obe.outbound.protection.outlook.com) [104.47.42.53]:44626 I=[46.146.239.184]:25
12457 handling TLS incoming connection from mail-co1nam03on0069.outbound.protection.outlook.com (NAM03-CO1-obe.outbound.protection.outlook.com) [104.47.40.69]:39376 I=[46.146.239.184]:25

ОС - debian 9, на версии 7 и 8 проблема была та же (обновился с 7го релиза пытаясь решить проблему).

Вывод exim -bV:

Exim version 4.89 #1 built 28-Nov-2017 21:58:00
Copyright (c) University of Cambridge, 1995 - 2017
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2017
Berkeley DB: Berkeley DB 5.3.28: (September 9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS move_frozen_messages Content_Scanning DKIM DNSSEC Event OCSP PRDR PROXY SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
2018-01-23 18:06:57 Warning: purging the environment.
Suggested action: use keep_environment.
Configuration file is /var/lib/exim4/config.autogenerated

С остальными серверами проблем не наблюдается, есть ошибки вида:

2018-01-23 16:33:55 [9336] SMTP connection from [149.202.123.238]:59164 I=[46.146.239.184]:25 (TCP/IP connection count = 3)
2018-01-23 16:33:58 [9474] H=nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:59164 I=[46.146.239.184]:25 X=TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256 CV=no F=<j@nicolatesla.ru> temporarily rejected RCPT <***@***>: greylisted.
2018-01-23 16:33:58 [9474] TLS error on connection from nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:59164 I=[46.146.239.184]:25 (recv): The TLS connection was non-properly terminated.
2018-01-23 16:33:58 [9474] H=nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:59164 I=[46.146.239.184]:25 incomplete transaction (connection lost) from <j@nicolatesla.ru>
2018-01-23 16:33:58 [9474] TLS error on connection from nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:59164 I=[46.146.239.184]:25 (send): The specified session has been invalidated for some reason.
2018-01-23 16:33:58 [9474] unexpected disconnection while reading SMTP command from nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:59164 I=[46.146.239.184]:25
2018-01-23 16:46:03 [9336] SMTP connection from [149.202.123.238]:44435 I=[46.146.239.184]:25 (TCP/IP connection count = 6)
2018-01-23 16:46:04 [9861] H=nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:44435 I=[46.146.239.184]:25 X=TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256 CV=no F=<gbj@nicolatesla.ru> temporarily rejected RCPT <***@***.***.**>: greylisted.
2018-01-23 16:46:04 [9861] TLS error on connection from nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:44435 I=[46.146.239.184]:25 (recv): The TLS connection was non-properly terminated.
2018-01-23 16:46:04 [9861] H=nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:44435 I=[46.146.239.184]:25 incomplete transaction (connection lost) from <gbj@nicolatesla.ru>
2018-01-23 16:46:04 [9861] TLS error on connection from nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:44435 I=[46.146.239.184]:25 (send): The specified session has been invalidated for some reason.
2018-01-23 16:46:04 [9861] unexpected disconnection while reading SMTP command from nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:44435 I=[46.146.239.184]:25
2018-01-23 17:11:35 [9336] SMTP connection from [149.202.123.238]:49703 I=[46.146.239.184]:25 (TCP/IP connection count = 7)
2018-01-23 17:11:39 [10604] H=nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:49703 I=[46.146.239.184]:25 X=TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256 CV=no F=<svvrfa@nicolatesla.ru> temporarily rejected RCPT <***@***.***.**>: greylisted.
2018-01-23 17:11:39 [10604] TLS error on connection from nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:49703 I=[46.146.239.184]:25 (recv): The TLS connection was non-properly terminated.
2018-01-23 17:11:39 [10604] H=nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:49703 I=[46.146.239.184]:25 incomplete transaction (connection lost) from <svvrfa@nicolatesla.ru>
2018-01-23 17:11:39 [10604] TLS error on connection from nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:49703 I=[46.146.239.184]:25 (send): The specified session has been invalidated for some reason.
2018-01-23 17:11:39 [10604] unexpected disconnection while reading SMTP command from nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:49703 I=[46.146.239.184]:25
2018-01-23 18:00:50 [9336] SMTP connection from [149.202.123.238]:46242 I=[46.146.239.184]:25 (TCP/IP connection count = 7)
2018-01-23 18:00:51 [12388] H=nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:46242 I=[46.146.239.184]:25 X=TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256 CV=no F=<yawabu@nicolatesla.ru> temporarily rejected RCPT <***@***.***.**>: greylisted.
2018-01-23 18:00:51 [12388] TLS error on connection from nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:46242 I=[46.146.239.184]:25 (recv): The TLS connection was non-properly terminated.
2018-01-23 18:00:51 [12388] H=nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:46242 I=[46.146.239.184]:25 incomplete transaction (connection lost) from <yawabu@nicolatesla.ru>
2018-01-23 18:00:51 [12388] TLS error on connection from nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:46242 I=[46.146.239.184]:25 (send): The specified session has been invalidated for some reason.
2018-01-23 18:00:51 [12388] unexpected disconnection while reading SMTP command from nicolatesla.ru (mail.nicolatesla.ru) [149.202.123.238]:46242 I=[46.146.239.184]:25

Но это как я понял результат работы greylist'а.

Ставил сертификат от Let’s Encrypt, проблема не изчезла. Если точнее - то ничего не изменилось.

Не могу понять в чем проблема, а получения этих писем нам требуется.

Может есть у кого какая идея или сталкивался кто с аналогичной проблемой?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[xM]

Попробуйте для начала обновить у себя корневые сертификаты.
Для FreeBSD это делается так

Код: Выделить всё

pkg upgrade ca_root_nss

[ladserg]

Попробуйте для начала обновить у себя корневые сертификаты.
Для FreeBSD это делается так

Код: Выделить всё

pkg upgrade ca_root_nss

Спасибо за отклик. Проверил корневые сертификаты у себя. В дебиане это пакет ca-certificates, на всякий случай переустановил его:

Код: Выделить всё

apt-get install --reinstall ca-certificates

Подключил неподключенные:

Код: Выделить всё

dpkg-reconfigure ca-certificates
update-ca-certificates -f
c_rehash /etc/ssl/certs

Рестартанул exim. Проверил ssl соединение:

Код: Выделить всё

openssl s_client -connect mta.medlife.perm.ru:465 -tls1 -servername mta.medlife.perm.ru

CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = mta.medlife.perm.ru
verify return:1
---
Certificate chain
0 s:/CN=mta.medlife.perm.ru
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFCTCCA/GgAwIBAgISA9KGM+pM6hoO5Vr11qAROOHDMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xODAxMTkxMTEzMjlaFw0x
ODA0MTkxMTEzMjlaMB4xHDAaBgNVBAMTE210YS5tZWRsaWZlLnBlcm0ucnUwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4VcgN1c5xf568S1B+9xvP5JX7
jTIVjAHBMy8gIiuHSdkmC+wrSXL4kY0mbQ3mF1ewtH+4akbE5SEybrm8WqyDxYhN
oCrDnyzMi/Dlo2JLpGLpFbLl2j3tPfqbo7UsomhUAZ+k0LNQAVzoIX0KtUrDiQTK
dqJNPcjrXunsxBGKWJW/LBx9/KCnmZWALmezvV1z2Q4F72oXjvaqfXcfcU6VuP2u
byFxCwaVQbSIfaYyPUooIZJnAyZLwlctIuFP57miY/xdJ+MbPkYzCUygkdlM6xnY
5GiszUMCiTaYh5UBAN9Na1LHofNh++Ets72hGbaNTCkutanyvRCn3Sp98tZhAgMB
AAGjggITMIICDzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFGBJEfSpWaNg0rDMRAKC
wH/3CsQjMB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUF
BwEBBGMwYTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNy
eXB0Lm9yZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNy
eXB0Lm9yZy8wHgYDVR0RBBcwFYITbXRhLm1lZGxpZmUucGVybS5ydTCB/gYDVR0g
BIH2MIHzMAgGBmeBDAECATCB5gYLKwYBBAGC3xMBAQEwgdYwJgYIKwYBBQUHAgEW
Gmh0dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIGrBggrBgEFBQcCAjCBngyBm1Ro
aXMgQ2VydGlmaWNhdGUgbWF5IG9ubHkgYmUgcmVsaWVkIHVwb24gYnkgUmVseWlu
ZyBQYXJ0aWVzIGFuZCBvbmx5IGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgQ2VydGlm
aWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vbGV0c2VuY3J5cHQub3JnL3Jl
cG9zaXRvcnkvMA0GCSqGSIb3DQEBCwUAA4IBAQCQPkqrjIs5uDazD+cPXew18tMv
63pJqRoqzx5Sj3Wtl3AlCkK7TyU0yN2Z0mTWFRmRKUoQkktu/PncwwR7gCpxO5Jv
DgHs6ulZH4vSyipL6+SrMQHJ7drE3DQRrDAC+aeB+T0zbxwO1i/8nYxArz6GN8eb
QlPouHerW32ftV6aFFrsKzu6H5JbfXqufCzduXrqx8iP8PekEtm5yTXLLY0V7soY
wh1jmm4PVV7d5oVOiQFg7hkWGWdL6iFJGEhUX1UPg/V30ytew58+pk2Eq8nwwKan
PDj/V4jjHKeybV0a7K3G09o7NXhkXWxoQmtIenrZQcMqP44yvuAJxahWZVR3
-----END CERTIFICATE-----
subject=/CN=mta.medlife.perm.ru
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2993 bytes and written 268 bytes
Verification: OK
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: BF9624F0AE5BDFA317F7A6F624114F8EDDA0F5BA36EACAC451D51AADE944A563
Session-ID-ctx:
Master-Key: D3F861250549EECB0E4A5955F95BAEAB84658FA45751186483F8D630A07D4C9A76C6FE8574E0A8A623E542C9720AFAB1
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1516794076
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
220 mta.medlife.perm.ru ESMTP Exim 4.89 Wed, 24 Jan 2018 16:41:16 +0500
ehlo mta.medlife.perm.ru
250-mta.medlife.perm.ru Hello localhost [127.0.0.1]
250-SIZE 27262976
250-8BITMIME
250-PIPELINING
250 HELP
QUIT
DONE

Проверил STARTTLS:

Код: Выделить всё

swaks -a -tls -q HELO -s mta.medlife.perm.ru -au test -ap '<>'

=== Trying mta.medlife.perm.ru:25...
=== Connected to mta.medlife.perm.ru.
<- 220 mta.medlife.perm.ru ESMTP Exim 4.89 Wed, 24 Jan 2018 16:44:04 +0500
-> EHLO mta.medlife.perm.ru
<- 250-mta.medlife.perm.ru Hello localhost [127.0.0.1]
<- 250-SIZE 27262976
<- 250-8BITMIME
<- 250-PIPELINING
<- 250-STARTTLS
<- 250 HELP
-> STARTTLS
<- 220 TLS go ahead
=== TLS started with cipher TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
=== TLS no local certificate set
=== TLS peer DN="/CN=mta.medlife.perm.ru"
~> EHLO mta.medlife.perm.ru
<~ 250-mta.medlife.perm.ru Hello localhost [127.0.0.1]
<~ 250-SIZE 27262976
<~ 250-8BITMIME
<~ 250-PIPELINING
<~ 250 HELP
~> QUIT
<~ 221 mta.medlife.perm.ru closing connection
=== Connection closed with remote host.

И всё равно коннекты с *.outbound.protection.outlook.com висят подолгу, плодятся, затем отваливаются с вышеописанными ошибками

[xM]

У меня нет особенных идей. Разве что tcpdump посмотреть что там происходит.
Но, к слову, Microsoft'овская почта ещё та штука. К примеру, они умудряются в транзите повреждать тело подписанных DKIM сообщений, а шлют от другого имени хоста, нежели представляется в HELO. Ну и как не вспомнить историю, когда для всех "счастливых" пользователей Outlook/Hotmail пару недель не работал IMAP.

[ladserg]

Кстати, а в EXIM есть возможность журналировать SMTP сеанс, в смысле какие команды и сообщения в сеансе посылаются? Судя по логам сама сессия начинается, происходит проверка SPF письма, конверт письма передаётся, и на сём сессия зависает. У меня есть подозрение что с шифрованием что то не так. При чём от гугла письма приходят.
Самое обидное, что в письмах этих шлётся код верификации для входа в кабинет с лицензиями и дистрибутивами.

Может подскажет кто, как заставить именно эти сервера без не стартовать TLS?

Отправлено спустя 10 минут 23 секунды:
Упс, кажется добился от них любви и ласки. Установил правило кое пропускает все проверки для их писем и письма стали ходить. Завтра поразбираюсь на каком правиле у меня виснет.

[xM]

Возможно у вас что-то в районе согласования шифров не проходит.
В любом случае, на дебаге должно быть видно всё в деталях. У Exim он подробный.

[ladserg]

Нашел я правило, на коем подвисает коннект и валится сессия:

Код: Выделить всё

# Проверка существования адреса отправителя
warn
        hosts           = !+relay_from_hosts
        !verify         = sender/callout=3m,defer_ok
        logwrite        = [WARN][ACCC] Sender callout verify is invalid \
                          H=$sender_helo_name[$sender_host_address] F=$sender_address T:$local_part@$domain
        set acl_c_spamscore     = ${eval:$acl_c_spamscore+20}
        set acl_c_spamlog       = $acl_c_spamlog Callout error;

Теперь осталось выяснить какое решение принять по этому поводу. Похоже ряд других почтовых серверов, чьи письма так же нужны, тоже не проходят проверку на существование почтового ящика.

[xM]

!verify = sender/callout=3m,defer_ok

Это очень плохая практика. Рекомендую отказаться от callouts совершенно.

Отправлено спустя 1 минуту :
Чтобы долго не писать, вот вам статья где умный дядя всё по полочкам раскладывает
https://bsdly.blogspot.lt/2017/08/twent ... s-are.html

[ladserg]

!verify = sender/callout=3m,defer_ok

Это очень плохая практика. Рекомендую отказаться от callouts совершенно.

Отправлено спустя 1 минуту :
Чтобы долго не писать, вот вам статья где умный дядя всё по полочкам раскладывает
https://bsdly.blogspot.lt/2017/08/twent ... s-are.html

Понятно. Похоже я научился на собственной ошибке. За ссылку спасибо, хоть с англицким у меня плохо, но гугл-переводчик помог понять из статьи, что проверка сия не столь актуальна и может быть даже чревата. Вернее она стала чревата в моём случае.

Я правильно понял, что при обратной проверке на проверяемом сервере так же запускаются проверки на мою проверку, на которые мой сервер так же может запустить свои проверки?

[xM]

Да, грубо говоря, callout мало что даёт и, тем более гарантирует, создаёт нагрузку на обе системы, более того, если спамер использует несуществующий адрес в чужом домене, то callout с вашего сервера выглядит как попытка отправить туда спам, и, таким образом, вы можете попасть в spam trap с последующим баном вашего IP.

Отправлено спустя 38 секунд:

Я правильно понял, что при обратной проверке на проверяемом сервере так же запускаются проверки на мою проверку, на которые мой сервер так же может запустить свои проверки?

Смотря что там настроено, но, обычно, маловероятно.

[ladserg]

Понятно. Спасибо за науку.