Exim как smarthost, TLS и отсылка множества сообщений в одном соединении

Понадобилось установить Exim в режиме smarthost - т.е. отсылку всех сообщений через основной почтовый сервер. Однако беда - смартхост сервер прерывал соединения после приёма 10 сообщений с ошибкой:

2010-03-02 15:46:01 1NmUHO-0001Rx-0g SMTP error from remote mail server after initial connection: host <smarthost> [XX.XX.XX.XX]: 421 Connection not accepted at this time

Сконфигурировал Exim заворачивать почту в очередь, приведя /etc/default/exim4 вот к такому виду:

# /etc/default/exim4
EX4DEF_VERSION=''
 
QUEUERUNNER='separate'
QUEUEINTERVAL='2m'
COMMONOPTIONS=''
QUEUERUNNEROPTIONS=''
QFLAGS='q'
SMTPLISTENEROPTIONS='-odqs'

и после этого осталось только выполнить dpkg-reconfigure exim4-config. После этого на сервере крутились два процесса:

Listener: /usr/sbin/exim4 -bd -odqs
Queue Runner: /usr/sbin/exim4 -oP /var/run/exim4/eximqr.pid -qq2m

Однако даже с такой конфигурацией возникли проблемы - сообщения попадали в очередь, но последующая доставка снова обрывалась после 10 соединений и сообщениям приходилось ждать следующего запуска обработчика очереди и истечения таймера retry. Люди на exim-users предложили добавить параметр serialize_hosts = * к remote_smtp_smarthost

remote_smtp:
   driver = smtp
   serialize_hosts = *

это нужно добавить в /etc/exim4/exim4.conf.template (в случае, если не выбрана опция разделения конфигурации на множество файлов) и выполнить выполнить dpkg-reconfigure exim4-config . Опять не помогло :-(

В конце концов, выяснилось, что виной всему - неэффективная имплементация алгоритма зашифрованной передачи писем TLS в Exim:

Exim стартует новый процесс для каждого письма. В процессе старта он обычно передает открытый TCP/IP сокет, по которому продолжается передача новых писем. Однако при использовании TLS все усложняется. Так как состояние TLS не так просто передать из одного процесса в другой, разработчики закрывают TLS сессию после передачи каждого письма и открывают его заново для отправки следующего. К сожалению, RFC не указывает четко, что должно происходить после закрытия TLS сессии. Exim просто пробует снова послать EHLO, и при любой возвращенной ошибке закрывает сокет и открывает его заново. Сами же Exim сервера поддерживают вот такой протокол включения и выключения TLS внутри одного-единственного SMTP соединения.

В итоге решение проблемы заключалось в выключении доставки почты через TLS:

http://www.exim.org/exim-html-current/doc/html/spec_html/ch39.html#SECTmulmessam

remote_smtp_smarthost:
   driver = smtp
   hosts_avoid_tls = *

в вышеупомянутый /etc/exim4/exim4.conf.template и снова выполнить dpkg-reconfigure exim4-config