Моя компания недавно установила среду Microsoft Exchange, управляемую Active Directory, для консолидации исходящей почты. У нас есть набор промежуточных серверов, которые теперь должны использовать наш MSEXCHG в качестве smarthost для исходящей почты.
Эти серверы расположены в демилитаризованной зоне, поэтому решение, за которое проголосовали Аутентификация на смарт-хосте Exchange 2010? не является альтернативой, поскольку мы не можем позволить серверу в демилитаризованной зоне просто волей-неволей отправлять почту через наш сервер Exchange.
Что мы сделали в MSEXCHG:
Что мы сделали в exim4 (8):
update-exim4.conf (8) (ср. exim4_files (5)) мы настроили exim для использования exchange.contoso.com:587 как смартхост.exim4_files (5)) Я добавил следующую строку: exchange.contoso.com:stagingserver@activedirectory.contoso.com:secret123)После запуска exim с конфигурацией, описанной выше, я получаю следующие две ошибки TLS в главный журнал:
TLS error on connection to ex.contoso.com [192.168.1.8] (recv): A TLS packet with unexpected length was received.TLS error on connection to ex.contoso.com [192.168.1.8] (send): The specified session has been invalidated for some reason.Затем наш MSEXCHG отказывается отправлять почту, и появляется следующая (окончательная) запись в журнале:
** kiewiet@contoso.com R=smarthost T=remote_smtp_smarthost: SMTP error from remote mail server after MAIL FROM:<root@contoso-stage.com> SIZE=1538: host ex.contoso.com [192.168.1.8]: 530 5.7.1 Client was not authenticated
Что еще я пробовал:
MAIN_TLS_ENABLE = 1 в exim4.conf.localmacros (http://blog.xig.ch/Exim-Smarthost-mit-Authentifizierung-%FCber-STARTTLS_127.html)Итак, обязательный вопрос: как заставить exim использовать нашу среду MSEXCHG в качестве smarthost?
Наша проблема была довольно специфичной для нашей установки. У нас есть несколько серверов Exchange, работающих параллельно с балансировщиком нагрузки, выступающим в качестве точки доступа. LB был неправильно настроен, из-за чего он не предлагал какую-либо панель методов аутентификации. NTLM и GSSAPI даже после успешного STARTTLS рукопожатие.
Углубленное тестирование через swaks jetmore.org (очень рекомендую этот инструмент) показал это.
Имеет ли ваша организация собственный центр сертификации для внутренних серверов? Возможно, вам нужно добавить сертификаты CA для сервера Exchange в хранилище доверенных сертификатов для Exim? Многие продукты не очень хорошо сообщают об этой ошибке (я не знаю, сообщает Exim или нет).
Wireshark (сначала захват на сервере с tcpdump -p -s0 -w /tmp/foo.pcap затем скопируйте на локальную рабочую станцию с помощью Wireshark) должен иметь возможность отображать сертификат сервера, отправленный из Exchange, и если после этого клиент зависает, то распространенной причиной является отсутствие сертификата CA.
Проблема связана с сертификатами TLS. Порядок решения:
sudo apt-get install openssl
sudo / usr / share / doc / exim4-base / примеры / exim-gencert
sudo nano /etc/exim4/exim4.conf.localmacros
main_tls_enable = '1'