Exim. Обновление до 4.90.1

EXIM, sendmail, postfix, Dovecot и прочие. Решение проблем связанных с работой электронной почты

Модератор: xM

Правила форума
Убедительная просьба юзать теги [code] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.
alkomotiv
проходил мимо
Сообщения: 9
Зарегистрирован: 2018-02-20 11:31:33

Exim. Обновление до 4.90.1

Непрочитанное сообщение alkomotiv » 2018-04-01 10:47:12

Коллеги, а неужели у всех, кроме нас, гладко проходит обновление до последней (на сегодня - 4.90.1 выпуск 3) версии Exim? Прошу заранее прощения за многобукоф, но сил потрачено много, пока безрезультатно, а потому не жаль потратить 2 часа на оформление темы.

После февральской/мартовской лавины сообщений в СМИ о необходимости скорейшего обновления старых версий в связи с обнаружением критических уязвимостей, решили обновиться.
Почтовый сервер у нас непростительно долго (около полутора лет) не обновлялся, поэтому все основные версии пакетов и ядра системы уже отстали от времени.
До обновления Exim был версии 4.84.2-2. Работает в связке с dovecot. Операционная система CentOS 7.2.1511. Сертификат используем самозаверенный, на доменные клиентские машины распространяется через GPO(устанавливается в Доверенные). Если машина не в домене, ставим ручками. Сертификат мультидоменный - у "статичных" пользователей почтовый сервер прописан по локальному dns-имени (mail.domain.local), у разных командировочных и прочих - по внешнему (mail.company.ru).
На большинстве рабочих мест в качестве почтового клиента - Windows Live Mail 2009 и 2012 (прошу только не писать - выкиньте ваш клиент, вы же знаете, что такое - "исторически сложилось"). Есть ещё совсем немного Thunderbird и Outlook Express на оставшихся Windows XP. Сам сервер находится за шлюзом и напрямую в интернет не смотрит (поэтому в логах далее: 192.168.1.2-это локальный адрес почтового сервера, 111.111.111.111 - внешний адрес, по которому он доступен, по факту - шлюз)
Все строки exim.conf, которые обеспечивают работу SMTP-сервера через SSL, стандартные, но всё равно перечислю:

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

daemon_smtp_ports = 25 : 465
tls_on_connect_ports = 465
tls_advertise_hosts = *
tls_certificate = /etc/pki/dovecot/certs/companymail.crt
tls_privatekey = /etc/pki/dovecot/private/companymail.key
Обновление решил начинать сразу с Exim. "yum update exim" подтянул как зависимости exim-mysql, а также openssl и openssl-libs(обновление с 1.0.1 до 1.0.2) и всё штатно обновилось. Начал проверять:
SSL-соединение с сервером входящей почты (по IMAP, порт 993) установилось и отработало как надо. При отправке же возникли проблемы (и dovecot и exim работают с одним и тем же сертификатом). Проблема снаружи выглядит так: когда в клиенте после оформления письма нажимаешь "Отправить", моментально возвращается ошибка 0x800ccc0f, означающая, что соединение было прервано сервером. В main.log при этом дважды пишется строка:

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

TLS error on connection from (companygate) [111.111.111.111] I=[192.168.1.2]:465 (SSL_accept): error:00000000:lib(0):func(0):reason(0)
означающая, что функция SSL_accept не отработала, но какого-то конкретного кода ошибки возвращено не было. Повторюсь, что в логе только эта строка, дважды. Никаких "(rejected our certificate?)".
На этом этапе есть интересный момент. Специфика работы клиента Windows Live Mail заключается в том, что перед непосредственной отправкой он кладёт сформированное письмо в локальную папку "Исходящие". Если письмо по какой-то причине не отправится, оно остаётся висеть на компьютере-клиенте в этой папке. Что-то вроде локальной очереди писем. Так вот после возвращения ошибки письмо лежит именно там. И если нажать в клиенте кнопку принудительной синхронизации "Отправить и получить", то это же письмо уходит без проблем и каких-либо ошибок. Таким образом, проблема возникает только при первой попытке отправки и только при использовании SSL. При отключении SSL соединяется нормально.

На этом этапе, поскольку время поджимало, мы решили остановиться и откатиться на работоспособное состояние. Подумали, что лучше всё-таки обновить полностью все пакеты, поэтапно проверяя работоспособность связки клиент-сервер, чтобы определить - обновление какого из пакетов вызывает проблемы.
Было установлено, что обновление абсолютно всех пакетов, кроме самого Exim, проблем не вызывает. Обновили всё, что возможно было - отправка работала. Как только обновляешь Exim, отправка работать перестаёт.
Также было установлено, что проблема не со всеми клиентами. Thunderbird, коммерческий MS Office Outlook 2003 и Windows Live Mail 2009 продолжают работать нормально. Windows Live Mail 2012 (80% машин) и Outlook Express выдают ошибку. Даже если "сервер хороший, а клиент плохой" у нас нет возможности быстро перевести всех на другие клиенты.

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

С помощью Wireshark было установлено, что проблема точно возникает на этапе TLS Handshake. Схема установки соединения TLS: https://habrastorage.org/files/e52/387/ ... 310962.png. Приведу разницу между нормальной установкой соединения на "старом" Exim'е (её отображением в Wireshark) и неудачной - после обновления. 192.168.1.166 - клиентский компьютер. 1.2 - почтовый сервер. Может быть, есть специалисты, кто может помочь "расшифровать" сведения. Понятно, что подробности о каждом соединении здесь не указаны.
Нормальная:

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

num	time		source		destination	protocol  length   info

346	9.100071	192.168.1.166	192.168.1.2	TCP	  66	   47750 → 465 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
347	9.100581	192.168.1.2	192.168.1.166	TCP	  66	   465 → 47750 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
348	9.100652	192.168.1.166	192.168.1.2	TCP	  54	   47750 → 465 [ACK] Seq=1 Ack=1 Win=65536 Len=0
349	9.101697	192.168.1.166	192.168.1.2	TLSv1	  214	   Client Hello
350	9.102760	192.168.1.2	192.168.1.166	TCP       60	   465 → 47750 [ACK] Seq=1 Ack=161 Win=30336 Len=0
#Server Hello здесь передаётся отдельно от остальных команд
352	9.171150	192.168.1.2	192.168.1.166	TLSv1	  1514	   Server Hello
353	9.171151	192.168.1.2	192.168.1.166	TLSv1	  1388	   Certificate, Server Key Exchange, Server Hello Done
354	9.171218	192.168.1.166	192.168.1.2  	TCP       54	   47750 → 465 [ACK] Seq=161 Ack=2795 Win=65536 Len=0
357	9.202821	192.168.1.166	192.168.1.2	TLSv1	  380	   Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
358	9.203292	192.168.1.2	192.168.1.166	TCP       60	   465 → 47750 [ACK] Seq=2795 Ack=487 Win=31360 Len=0
359	9.219767	192.168.1.2	192.168.1.166	TLSv1	  113	   Change Cipher Spec, Encrypted Handshake Message
360	9.220768	192.168.1.2	192.168.1.166	TLSv1	  160	   Application Data, Application Data
361	9.220833	192.168.1.166	192.168.1.2	TCP       54	   47750 → 465 [ACK] Seq=487 Ack=2960 Win=65280 Len=0
# установка соединения завершена, дальше идут данные приложения
362	9.221942	192.168.1.166	192.168.1.2	TLSv1	  107	   Application Data
363	9.223354	192.168.1.2	192.168.1.166	TLSv1	  272	   Application Data, Application Data
Неудачная:

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

num     time		source		destination	protocollength  info

751	12.751110	192.168.1.166	192.168.1.2	TCP	66	48132 → 465 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
752	12.752935	192.168.1.2	192.168.1.166	TCP	66	465 → 48132 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
753	12.753031	192.168.1.166	192.168.1.2	TCP	54	48132 → 465 [ACK] Seq=1 Ack=1 Win=65536 Len=0
754	12.754423	192.168.1.166	192.168.1.2	TLSv1	215	Client Hello
755	12.755644	192.168.1.2	192.168.1.166	TCP	60	465 → 48132 [ACK] Seq=1 Ack=162 Win=30336 Len=0
# строкой ниже уже видно различие в механизме. Server Hello передаётся со всеми командами
# после этого соединение закрывается (FIN)
756	12.761649	192.168.1.2	192.168.1.166	TLSv1	1078	Server Hello, Certificate, Server Key Exchange, Server Hello Done
757	12.764940	192.168.1.166	192.168.1.2	TCP	54	48132 → 465 [FIN, ACK] Seq=162 Ack=1025 Win=64512 Len=0
758	12.766093	192.168.1.166	192.168.1.2	TCP	66	48133 → 465 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
759	12.767251	192.168.1.2	192.168.1.166	TCP	60	465 → 48132 [FIN, ACK] Seq=1025 Ack=163 Win=30336 Len=0
760	12.767374	192.168.1.166	192.168.1.2	TCP	54	48132 → 465 [ACK] Seq=163 Ack=1026 Win=64512 Len=0
761	12.767645	192.168.1.2	192.168.1.166	TCP	66	465 → 48133 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
762	12.767715	192.168.1.166	192.168.1.2	TCP	54	48133 → 465 [ACK] Seq=1 Ack=1 Win=65536 Len=0
763	12.767969	192.168.1.166	192.168.1.2	TCP	54	48133 → 465 [FIN, ACK] Seq=1 Ack=1 Win=65536 Len=0
764	12.769393	192.168.1.2	192.168.1.166	TCP	60	465 → 48133 [ACK] Seq=1 Ack=2 Win=29312 Len=0
765	12.773645	192.168.1.2	192.168.1.166	TCP	60	465 → 48133 [FIN, ACK] Seq=1 Ack=2 Win=29312 Len=0
766	12.773748	192.168.1.166	192.168.1.2	TCP	54	48133 → 465 [ACK] Seq=2 Ack=2 Win=65536 Len=0
Далее стоит запустить exim в режиме отладки, чтобы увидеть обработку TLS-логики:

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

exim -d-all+tls -bd
Думаю, что в этом выводе (после "Calling SSL_accept"), самая важная информация. То, что выше отобразил Wireshark, тут видно изнутри. Только пока не понятно, что с этим делать:

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

[root@mail:exim -d-all+tls -bd
Exim version 4.90_1 uid=0 gid=0 pid=3104 D=8000000
Berkeley DB: Berkeley DB 5.3.21: (May 11, 2012)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc OpenSSL Content_Scanning DKIM DNSSEC Event OCSP PRDR TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch ldap ldapdn ldapm nis nis0 nisplus passwd sqlite
Authenticators: cram_md5 cyrus_sasl dovecot gsasl plaintext spa tls
Routers: accept dnslookup ipliteral 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
Compiler: GCC [4.8.5 20150623 (Red Hat 4.8.5-16)]
Library version: Glibc: Compile: 2.17
                        Runtime: 2.17
Library version: OpenSSL: Compile: OpenSSL 1.0.2k-fips  26 Jan 2017
                          Runtime: OpenSSL 1.0.2k-fips  26 Jan 2017
                                 : built on: reproducible build, date unspecified
Library version: Cyrus SASL: Compile: 2.1.26
                             Runtime: 2.1.26 [Cyrus SASL]
Library version: GNU SASL: Compile: 1.8.0
                           Runtime: 1.8.0
Library version: PCRE: Compile: 8.32
                       Runtime: 8.32 2012-11-30
Library version: MySQL: Compile: 50556 5.5.56-MariaDB [mariadb-5.5]
                        Runtime: 50556 5.5.56-MariaDB
                        Exim version 4.90_1
Library version: SQLite: Compile: 3.7.17
                         Runtime: 3.7.17
WHITELIST_D_MACROS unset
TRUSTED_CONFIG_LIST: "/etc/exim/trusted-configs"
tls_validate_require_cipher child 3105 ended: status=0x0
LOG: MAIN
configuration file is /etc/exim/exim.conf
log selectors = 0000cefe 0c670482
cwd=/etc/exim 3 args: exim -d-all+tls -bd
trusted user
admin user
 3104 listening on all interfaces (IPv4) port 25
 3104 listening on all interfaces (IPv4) port 465
 3104 pid written to /var/run/exim.pid
 3104 LOG: MAIN
 3104   exim 4.90_1 daemon started: pid=3104, no queue runs, listening for SMTP on port 25 (IPv4) and for SMTPS on port 465 (IPv4)
 3104 daemon running with uid=93 gid=93 euid=93 egid=93
 3104 Listening...
 3104 Connection request from 111.111.111.111 port 12058
 3104 1 SMTP accept process running
 3104 Listening...
 3106 Process 3106 is handling incoming connection from [111.111.111.111]
 3106 setting SSL CTX options: 0x1104000
 3106 Diffie-Hellman initialized from default with 2048-bit prime
 3106 ECDH OpenSSL 1.0.2+ temp key parameter settings: autoselection
 3106 tls_certificate file /etc/pki/dovecot/certs/companymail.crt
 3106 tls_privatekey file /etc/pki/dovecot/private/companymail.key
 3106 Initialized TLS
 3106 Calling SSL_accept
 3106 SSL info: before/accept initialization
 3106 SSL info: before/accept initialization
 3106 Received TLS SNI "mail.domain.local" (unused for certificate selection)
 3106 SSL info: SSLv3 read client hello A
 3106 SSL info: SSLv3 write server hello A
 3106 SSL info: SSLv3 write certificate A
 3106 SSL info: SSLv3 write key exchange A
 3106 SSL info: SSLv3 write server done A
 3106 SSL info: SSLv3 flush data
 3106 SSL info: SSLv3 read client certificate A
 3106 SSL info: SSLv3 read client key exchange A
 3106 LOG: MAIN
 3106   TLS error on connection from (companygate) [111.111.111.111] I=[192.168.1.2]:465 (SSL_accept): error:00000000:lib(0):func(0):reason(0)
 3104 Connection request from 111.111.111.111 port 12059
 3104 2 SMTP accept processes running
 3104 Listening...
 3107 Process 3107 is handling incoming connection from [111.111.111.111]
 3107 setting SSL CTX options: 0x1104000
 3107 Diffie-Hellman initialized from default with 2048-bit prime
 3107 ECDH OpenSSL 1.0.2+ temp key parameter settings: autoselection
 3107 tls_certificate file /etc/pki/dovecot/certs/companymail.crt
 3107 tls_privatekey file /etc/pki/dovecot/private/companymail.key
 3107 Initialized TLS
 3107 Calling SSL_accept
 3107 SSL info: before/accept initialization
 3107 SSL info: before/accept initialization
 3107 LOG: MAIN
 3107   TLS error on connection from (companygate) [111.111.111.111] I=[192.168.1.2]:465 (SSL_accept): error:00000000:lib(0):func(0):reason(0)
 3104 child 3106 ended: status=0x0
 3104   normal exit, 0
 3104 1 SMTP accept process now running
 3104 child 3107 ended: status=0x0
 3104   normal exit, 0
 3104 0 SMTP accept processes now running
 3104 Listening...
В выводе видно, что ошибка появляется дважды. На всякий случай приведу вывод дебага, где функция SSL_accept отрабатывает без ошибок (на строй версии Exim, но с этим же самым сертификатом):

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

3850 Calling SSL_accept
 3850 SSL info: before/accept initialization
 3850 SSL info: before/accept initialization
 3850 Received TLS SNI "mail.domain.local" (unused for certificate selection)
 3850 SSL info: SSLv3 read client hello A
 3850 SSL info: SSLv3 write server hello A
 3850 SSL info: SSLv3 write certificate A
 3850 SSL info: SSLv3 write key exchange A
 3850 SSL info: SSLv3 write server done A
 3850 SSL info: SSLv3 flush data
 3850 SSL info: SSLv3 read client certificate A
 3850 SSL info: SSLv3 read client key exchange A
 3850 SSL info: SSLv3 read certificate verify A
 3850 SSL info: SSLv3 read finished A
 3850 SSL info: SSLv3 write change cipher spec A
 3850 SSL info: SSLv3 write finished A
 3850 SSL info: SSLv3 flush data
 3850 SSL info: SSL negotiation finished successfully
 3850 SSL info: SSL negotiation finished successfully
 3850 SSL_accept was successful
Что ещё пробовали:

- перевыпустить заново сертификат - с разными длинами ключа и алгоритмами хэша. Без изменений. Входящая почта работает как надо. Отправка - с первого раза не проходит.

- активировать дополнительные опции openssl (добавил в конфиг параметр openssl_options) в различных комбинациях. Как написано на exim.org:

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

# Make both old MS and old Eudora happy:
openssl_options = -all +microsoft_big_sslv3_buffer +dont_insert_empty_fragments

# Disable older protocol versions:
openssl_options = +no_sslv2 +no_sslv3
- сэмулировать TLS соединение на порт 465. Устанавливается без ошибок (различий вывода с работоспособным вариантом не нашли), сертификаты читаются, доходит до приглашения Exim'а на ввод.

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

openssl s_client -connect mail.company.ru:465
Чтобы ещё больше не удлинять тему, вывод команды приведу по необходимости, дополнительно, другим постом.

Следующим этапом хотим попробовать использовать полноценный сертификат, заверяемый доверенным УЦ, возможно, Let's Encrypt.

Будем благодарны Вам, если Вы долистали до этого момента, а в особенности - если выскажете, какие-то мысли.
Заранее спасибо.

Хостинговая компания Host-Food.ru
Хостинг HostFood.ru
 

Услуги хостинговой компании Host-Food.ru

Хостинг 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/

Аватара пользователя
dekloper
ст. лейтенант
Сообщения: 1331
Зарегистрирован: 2008-02-24 15:43:19
Откуда: давно здесь сидим..
Контактная информация:

Exim. Обновление до 4.90.1

Непрочитанное сообщение dekloper » 2018-04-02 12:03:15

есть касяк :(
хотел предложить либре заюзать, но смысл.. консольный тлс коннект проходит..

alkomotiv
проходил мимо
Сообщения: 9
Зарегистрирован: 2018-02-20 11:31:33

Exim. Обновление до 4.90.1

Непрочитанное сообщение alkomotiv » 2018-04-02 22:59:16

Сегодня попробовали использовать сертификат от Let's Encrypt - та же ошибка один в один. Таким образом установлено, что проблема не в самоподписном сертификате.
Просто непонятно, если вдруг клиент стал плохим, то нужно узнать конкретную причину. Иначе следующий релиз Exim отсечёт ещё какой-нибудь клиент. Не будем же мы их постоянно переустанавливать.
Назревает вопрос, что делать с полученной отладочной информацией, как её более подробно интерпретировать? Может быть, нужно опубликовать всё, что удалось нарыть на каком-нибудь баг-трекере? Как правильно поступить? Я не думаю, что мы одни используем Windows Live Mail (который, кстати, с 10 января 2017 года больше не поддерживается MS).

Аватара пользователя
xM
ст. лейтенант
Сообщения: 1316
Зарегистрирован: 2009-01-15 23:57:41
Откуда: Königsberg
Контактная информация:

Exim. Обновление до 4.90.1

Непрочитанное сообщение xM » 2018-04-03 0:45:49

А вы рассылку exim читали? Багрепорты?
IT voodoo blog https://kostikov.co

alkomotiv
проходил мимо
Сообщения: 9
Зарегистрирован: 2018-02-20 11:31:33

Exim. Обновление до 4.90.1

Непрочитанное сообщение alkomotiv » 2018-04-03 10:07:10

А вы рассылку exim читали? Багрепорты?
Нет, читали только то, что на exim.org:
All versions of Exim previous to version 4.90.1 are now obsolete. The last 3.x release was 3.36. It is obsolete and should not be used.
The current version is 4.90.1
We fixed CVE-2018-6789
и на bugzilla.redhat.com:
Bug 1543269 - CVE-2018-6789 exim: Buffer overflow in utility function, when pre-conditions are met, can lead to remote code execution
Fixed In Version: exim-4.90.1-2.el7 exim-4.90.1-2.el6
А что такое рассылка exim? И на какие именно багрепорты нужно посмотреть? Будьте добры просветить.

Аватара пользователя
dekloper
ст. лейтенант
Сообщения: 1331
Зарегистрирован: 2008-02-24 15:43:19
Откуда: давно здесь сидим..
Контактная информация:

Exim. Обновление до 4.90.1

Непрочитанное сообщение dekloper » 2018-04-03 10:57:56

alkomotiv писал(а):
2018-04-03 10:07:10
Нет, читали только то, что на exim.org:
ну там и нада дальше сцылки поклацать
зы. попробуйте штоле пересобрать с либрессл или гнутлс.. вдруг..
ТОВАгИЩИ! БгАТЬЯ И СЕСТгЫ! ДОЛОЙ гАВНОДУШИЕ!

alkomotiv
проходил мимо
Сообщения: 9
Зарегистрирован: 2018-02-20 11:31:33

Exim. Обновление до 4.90.1

Непрочитанное сообщение alkomotiv » 2018-04-03 12:14:33

сцылки поклацать
Да. Большое спасибо! Мы не одиноки, это главное.
Будем изучать.

Аватара пользователя
xM
ст. лейтенант
Сообщения: 1316
Зарегистрирован: 2009-01-15 23:57:41
Откуда: Königsberg
Контактная информация:

Exim. Обновление до 4.90.1

Непрочитанное сообщение xM » 2018-04-03 12:20:52

alkomotiv писал(а):
2018-04-03 10:07:10
А что такое рассылка exim? И на какие именно багрепорты нужно посмотреть? Будьте добры просветить.
Ну что ж вы? Такие рассылки это почти всегда главный источник информации и способ решения проблем. Причём, как правило, весьма действенный.
https://lists.exim.org/mailman/listinfo/exim-users
IT voodoo blog https://kostikov.co

alkomotiv
проходил мимо
Сообщения: 9
Зарегистрирован: 2018-02-20 11:31:33

Exim. Обновление до 4.90.1

Непрочитанное сообщение alkomotiv » 2018-04-03 13:04:02

xM писал(а):
2018-04-03 12:20:52
Ну что ж вы?
Да, раньше сталкиваться не приходилось. Во время всех предыдущих обновлений серьёзных проблем не возникало.
С багтрекером разобрались - нашли эту проблему.
С рассылками более или менее ясно тоже. Подписался.
Спасибо за наводку.

alkomotiv
проходил мимо
Сообщения: 9
Зарегистрирован: 2018-02-20 11:31:33

Exim. Обновление до 4.90.1

Непрочитанное сообщение alkomotiv » 2018-04-04 16:55:42

Чтобы не оставлять тему незавершённой, буду информировать о ходе работы.
В общем-то, вся информация по проблеме относительно понятна и доступна из переписки разработчиков (Jeremy Harris и Phil Pennock ) с остальными "Folks", то есть со страждущим народом.
Если кто-то не хочет читать мой искажённый переводом текст, прошу по ссылке:
https://bugs.exim.org/show_bug.cgi?id=2255

Остальным же коротко попытаюсь рассказать, как я понял суть проблемы.
Речь будет идти о механизме кеширования сессий(SSL-соединений) почтовыми клиентами.
Если кто-то найдёт ссылку с хорошим материалом по этой теме, думаю, что всем будет большой плюс.

С одним из последних выпусков Exim разработчики решили жёстко или "безусловно" отключить (то есть отключить на стороне сервера)
использование этого механизма, считая его небезопасным. Возможно, несколько поспешно, будем смотреть на развитие событий.
Отключение произведено следующим образом:
В исходниках Exim в каталоге /src имеется файл tls-openssl.c
В этом файле помимо остальных 3000 строк есть строка, задающая значение функции
SSL_CTX_set_session_cache_mode.
Задаётся оно следующим образом: (void) SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF);
Данная строка сопровождается комментарием: "Безусловное отключение кеширования сессий"

Установка такого значения данной функции является нововведением и именно им обусловлен возврат ошибки на ряде клиентов.
Проблема в том, что некоторые клиенты как раз-таки безусловно ИСПОЛЬЗУЮТ кеширование сессий, то есть оно на них
включено и вряд ли пользователю даётся возможность управлять этим процессом.

Первоначально, когда люди начали жаловаться на проблему, разработчики предлагали разбираться со своими клиентами:
"Try to find out how to tell Outlook to not use session caching at all."
Но поскольку, вероятно, что это всё-таки невозможно на большинстве клиентов(которые названы "dubious" - сомнительными), плюс учитывая, то что ошибка появляется и на коммерческих клиентах вроде MS Outlook 2016, а может быть просто по душевной доброте разработчики вчера задумались о том, чтобы всё-таки каким-то образом откатить внесённые изменения или сделать их менее радикальными.

Сначала нас обрадовали сообщением о том, что в код Exim вносятся изменения в результате этого обсуждения.
Далее господин Phil Pennock рассуждает о том, что действительно возврат поддержки этого механизма не приведёт к каким-то фатальным последствиям.
И заканчивается вечер выходом патча seesion-cache.patch, который позволяет обрабатывать состояние механизма кеширования сессий.
Патч меняет содержимое рассмотренного выше файла tls-openssl.c. Ссылка на страницу отображения изменений, вносимых патчем:
https://bugs.exim.org/attachment.cgi?id ... ction=diff
Исходный код при этом дополняется следующим достаточно эмоциональным комментарием:

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

/* We'd like to disable session cache unconditionally, but foolish Outlook
Express clients then give up the first TLS connection and make a second one
(which works).  Only when there is an IMAP service on the same machine.
Presumably OE is trying to use the cache for A on B.  Try just setting no
internal caching, and rely on the lack of callback support for external caching.
It might work, but who knows?  The proper support only arrived in OpenSSL
versions 0.9.6h 0.9.7 1.0.0 at the same time as the control define. */
Таким образом, нам предлагается пересобрать Exim из исходников, применив разработанный патч.
Господин Pennock в очередном комментарии просит обратной связи по результатам внесения изменений в исходники.

Этим благим делом мы сегодня и занимались. Но, не затягивая ещё больше, скажу, что успеха не достигли. Патч включился в сборку без проблем, исходный код функции исправлен, rpm-пакет собран и инсталлирован, но изменений в поведении не произошло. Всё также один в один. Об этом я сообщил на своём кривом инглише в баг-трекер. Будем надеяться, что разработчики не остановят работу в этом направлении.

P.S. В ходе исследований выяснили, что если сделать свой собственный простейший патч, который просто удалит (закомментирует) из файла tls-openssl.c строку с функцией, отключающей кеширование ((void) SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF);), то проблемные клиенты начинают работать. Но является ли такой подход допустимым, к чему он может привести, а также - действительно ли это работает на ВСЕХ клиентах, пока неясно.

Аватара пользователя
xM
ст. лейтенант
Сообщения: 1316
Зарегистрирован: 2009-01-15 23:57:41
Откуда: Königsberg
Контактная информация:

Exim. Обновление до 4.90.1

Непрочитанное сообщение xM » 2018-04-04 17:57:46

alkomotiv писал(а):
2018-04-04 16:55:42
Jeremy Harris и Phil Pennock
Это самые главные чуваки теперь.
alkomotiv писал(а):
2018-04-04 16:55:42
P.S. В ходе исследований выяснили, что если сделать свой собственный простейший патч...
Не забудьте сообщить об этом разработчикам.
Вообще, вы - молодец. Правильный и конструктивный подход единиц к делу всегда идёт на пользу всему сообществу.
IT voodoo blog https://kostikov.co

alkomotiv
проходил мимо
Сообщения: 9
Зарегистрирован: 2018-02-20 11:31:33

Exim. Обновление до 4.90.1

Непрочитанное сообщение alkomotiv » 2018-04-04 23:12:03

Спасибо большое за добрые слова, уважаемый модератор.

А вот господина Harris'а по-моему сложившаяся ситуация начинает немного удивлять:
I guess the other question that ought to be asked is: has the problem been
described to Microsoft, and what answer did they give?
В вольном переводе:
Я думаю другой вопрос, который должен быть задан - это: было ли описание проблемы доведено до Майкрософт и какой ответ они дали?

Что в конкретном случае с нашими заброшенными и неподдерживаемыми клиентами предсказуемо не приведёт к положительному результату. Здесь описать сам сбой в механизме ещё не так-то просто, а уж довести его до кого-то в Майкрософте..

Аватара пользователя
dekloper
ст. лейтенант
Сообщения: 1331
Зарегистрирован: 2008-02-24 15:43:19
Откуда: давно здесь сидим..
Контактная информация:

Exim. Обновление до 4.90.1

Непрочитанное сообщение dekloper » 2018-04-05 8:47:20

alkomotiv писал(а):
2018-04-04 16:55:42
Но поскольку, вероятно, что это всё-таки невозможно на большинстве клиентов(которые названы "dubious" - сомнительными)
подтверждаю
в очень вольном переводе - "dubious" - УнылоеГоГно (все "современые" м$ поделия, разработанные после 2003г)
експресс, м$ офиз 2003 - еще можно как то мириться

Аватара пользователя
xM
ст. лейтенант
Сообщения: 1316
Зарегистрирован: 2009-01-15 23:57:41
Откуда: Königsberg
Контактная информация:

Exim. Обновление до 4.90.1

Непрочитанное сообщение xM » 2018-04-05 16:21:46

alkomotiv писал(а):
2018-04-04 23:12:03
А вот господина Harris'а по-моему сложившаяся ситуация начинает немного удивлять:
Да M$ насрать, в принципе. Но в случае (крайне маловероятном) ответа можно ждать нечто вроде "мы не поддерживаем старый софт, рекомендуем обновиться на новый" в обрамлении завитушек вежливости. И это правильно.
IT voodoo blog https://kostikov.co

alkomotiv
проходил мимо
Сообщения: 9
Зарегистрирован: 2018-02-20 11:31:33

Exim. Обновление до 4.90.1

Непрочитанное сообщение alkomotiv » 2018-04-05 17:40:16

И это правильно.
Правильно-то правильно, но в итоге вся эта ситуация остаётся НАШЕЙ проблемой.
Как резюмировал один из участников обсуждения, путей у нас несколько:
1. Отказаться от обновления SMTP-сервера
2. Обновить SMTP-сервер, но
- либо отказаться от использования SSL
- либо поменять весь ставший проблемным клиентский софт
- либо пересобрать Exim с использованием homemade-патча
- упоминается ещё способ установки отличающихся имён хоста для серверов входящей и исходящей почты в настройках почтового клиента.
В моём случае IMAP и SMTP работают на одном физическом сервере. Я создал ещё одну DNS-запись и прописал в настройках один и тот же
сервер по-разному. Не сработало. Может, что не так понял. В любом случае, варианты пока грабельно-костыльные либо трудоёмкие с
неясной переспективой.

Подождём ещё немного. Но пока ждём, начинаем у себя на предприятии гомеопатическими дозами пробовать Thunderbird - знакомить пользователей и знакомиться с тонкостями сами.

Аватара пользователя
xM
ст. лейтенант
Сообщения: 1316
Зарегистрирован: 2009-01-15 23:57:41
Откуда: Königsberg
Контактная информация:

Exim. Обновление до 4.90.1

Непрочитанное сообщение xM » 2018-04-05 20:29:33

alkomotiv писал(а):
2018-04-05 17:40:16
в итоге вся эта ситуация остаётся НАШЕЙ проблемой
Это да. Хороший пример того, что платный софт, в этом плане, не лучше бесплатного (а по факту выходит и хуже).

А не хотите, коль уж переводить, так на web-клиент а-ля Roundcube? Браузер есть у всех, клиент централизованно управляется и апдейтится. И проблем с поддержкой TLS не имеет, кстати. Красота.
IT voodoo blog https://kostikov.co

Аватара пользователя
dekloper
ст. лейтенант
Сообщения: 1331
Зарегистрирован: 2008-02-24 15:43:19
Откуда: давно здесь сидим..
Контактная информация:

Exim. Обновление до 4.90.1

Непрочитанное сообщение dekloper » 2018-04-05 22:26:24

соглашусь с гражданином из города, которого нет, действительно - красота :)
ТОВАгИЩИ! БгАТЬЯ И СЕСТгЫ! ДОЛОЙ гАВНОДУШИЕ!

alkomotiv
проходил мимо
Сообщения: 9
Зарегистрирован: 2018-02-20 11:31:33

Exim. Обновление до 4.90.1

Непрочитанное сообщение alkomotiv » 2018-04-09 14:28:22

Добрый день.
Последние дни были богаты на события. Полагаю, что проблема по большому счёту решена.
Подробнее:
Со вчерашнего дня устранение рассматриваемой проблемы официально внесено
в предстоящий релиз Exim 4.91 (https://github.com/Exim/exim/blob/maste ... /ChangeLog):
JH/37 Bug 2255: Revert the disable of the OpenSSL session caching. This
triggered odd behaviour from Outlook Express clients.
Кеширование TLS-соединений клиентами будет поддерживаться (обрабатываться) SMTP-сервером.
Более того, в будущих версиях Exim (не ранее 4.92) будет добавлен механизм обработки поведения почтовых клиентов во время установки SSL-соединений. Вероятно, можно будет в конфигурационном файле Exim выставлять опцию поддержки включенного кеширования, либо же отключать его:
The upcoming 4.91 will revert to leaving the cache uselessly
enabled; any knob will not appear before 4.92.
--
Cheers,
Jeremy
Кому интересно, функция SSL_CTX_set_session_cache_mode обработана следующим образом:

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

/* We'd like to disable session cache unconditionally, but foolish Outlook
Express clients then give up the first TLS connection and make a second one
(which works).  Only when there is an IMAP service on the same machine.
Presumably OE is trying to use the cache for A on B.  Leave it enabled for
now, until we work out a decent way of presenting control to the config.  It
will never be used because we use a new context every time. */
#ifdef notdef
 (void) SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF);
#endif
Кстати, здесь в комментарии упоминается ещё один вариант, при котором, связка клиент-сервер будет работать нормально, даже если на сервере поддержка кеширования сессий отключена, а на клиенте активна: по словам разработчиков, это будет работать если, сервер входящих сообщений (служба IMAP) и SMTP-сервер расположены на разных машинах. Этот вариант нами не проверялся.
Также люди занимаются поиском настроек кеширования соединений на стороне клиента. Ссылки по этим материалам есть в баг-трекере:
https://bugs.exim.org/show_bug.cgi?id=2255#c28 Для более полного владения ситуацией, нужно будет поработать и в этом направлении тоже, поскольку как видно из комментария к исходному коду выше:
кеширование всё равно не будет использоваться. По умолчанию будет создаваться новый контекст для каждого соединения. Поддержка кеширования будет лишь в качестве опции для обеспечения более полной совместимости.

Exim с применением последних изменений мы собрали из исходников. Пока на тестовом сервере. Всё работает штатно. Будем проверять дальше. Рабочий патч (для CentOS Linux release 7.4.1708 (Core)), вносящий изменения в файл tls-openssl.c в аттаче ниже.

Всем удачи и весеннего настроения!
Вложения
exim-4.90.1-session-cache.patch.bz2
exim-4.90.1-session-cache.patch
(630 байт) 31 скачивание

Аватара пользователя
xM
ст. лейтенант
Сообщения: 1316
Зарегистрирован: 2009-01-15 23:57:41
Откуда: Königsberg
Контактная информация:

Exim. Обновление до 4.90.1

Непрочитанное сообщение xM » 2018-04-09 21:58:39

Спасибо за информацию.
Она будет полезна многим не подписанным на оригинальный список рассылки.
IT voodoo blog https://kostikov.co

gyurza2000
лейтенант
Сообщения: 895
Зарегистрирован: 2007-07-08 23:53:20
Откуда: SPb
Контактная информация:

Exim. Обновление до 4.90.1

Непрочитанное сообщение gyurza2000 » 2018-09-21 11:46:13

Обновился до 4.91_3, в логах нашёл такую ошибку:

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

Non-CRLF-terminated header, under CHUNKING: message abandoned
SMTP protocol error in "BDAT 131072" H=localhost (adios.spb.ru) [::1] I=[::1]:25 valid RCPT command must precede BDAT
Xeon X5460, RAM 8Gb, FreeBSD 13.1-RELEASE on amd64, Apache 2.4, PHP 7.3.30, MySQL 5.7, Exim 4.95_5, Dovecot 2.3.19.1

gyurza2000
лейтенант
Сообщения: 895
Зарегистрирован: 2007-07-08 23:53:20
Откуда: SPb
Контактная информация:

Exim. Обновление до 4.90.1

Непрочитанное сообщение gyurza2000 » 2018-09-21 13:47:13

А это из лога Sieve

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

DATA failed: 552 Message header not CRLF terminated (permanent failure).
Xeon X5460, RAM 8Gb, FreeBSD 13.1-RELEASE on amd64, Apache 2.4, PHP 7.3.30, MySQL 5.7, Exim 4.95_5, Dovecot 2.3.19.1

gyurza2000
лейтенант
Сообщения: 895
Зарегистрирован: 2007-07-08 23:53:20
Откуда: SPb
Контактная информация:

Exim. Обновление до 4.90.1

Непрочитанное сообщение gyurza2000 » 2018-09-21 14:48:21

В итоге почта за пределы сервера не форвардится
Xeon X5460, RAM 8Gb, FreeBSD 13.1-RELEASE on amd64, Apache 2.4, PHP 7.3.30, MySQL 5.7, Exim 4.95_5, Dovecot 2.3.19.1

dserga
ефрейтор
Сообщения: 57
Зарегистрирован: 2008-05-23 7:23:36

Exim. Обновление до 4.90.1

Непрочитанное сообщение dserga » 2018-09-25 13:06:50

gyurza2000, аналогично столкнулся с этой же проблемой 2 недели назад... Эта трабла с exim внесена в баг лист dovecot, но пока шевеления на этом фронте я не вижу. К сожалению, как и решения или объезда.
Как вариант - это из-за использования LMTP

dserga
ефрейтор
Сообщения: 57
Зарегистрирован: 2008-05-23 7:23:36

Exim. Обновление до 4.90.1

Непрочитанное сообщение dserga » 2018-10-04 20:35:12

Dovecot и Pigeonhole обновились, но проблема все там же.

Аватара пользователя
xM
ст. лейтенант
Сообщения: 1316
Зарегистрирован: 2009-01-15 23:57:41
Откуда: Königsberg
Контактная информация:

Exim. Обновление до 4.90.1

Непрочитанное сообщение xM » 2018-10-05 17:54:24

dserga писал(а):
2018-10-04 20:35:12
Dovecot и Pigeonhole обновились, но проблема все там же.
А с чего бы она должна решиться, если это SMTP?
IT voodoo blog https://kostikov.co