2004.12.04 22:40:02 LOG7[2406:134600704]: Remote FD=12 initialized

2004.12.04 22:40:02 LOG7[2406:134600704]: Socket closed on read

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL alert (write): warning: close notify

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL write shutdown (output buffer empty)

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL alert (read): warning: close notify

2004.12.04 22:40:02 LOG7[2406:134600704]: SSL closed on SSL_read

2004.12.04 22:40:02 LOG7[2406:134600704]: Socket write shutdown (output buffer empty)

2004.12.04 22:40:02 LOG5[2406:134600704]: Connection closed: 12678 bytes sent to SSL, 10178 bytes sent to socket

2004.12.04 22:40:02 LOG7[2406:134600704]: pop3s finished (0 left)

Для того чтобы забирать письма с сервера, в данном примере использовался POP3S, но смею вас уверить, что IMAPS будет также надежно выполнять эту задачу. Вдоволь наигравшись с Outlook Express, я принялся тестировать все почтовые клиенты, что были под рукой. Поэтому могу смело заявить: как и ожидалось, Mozilla Thunderbird 0.6 и Ximian Evolution 2.0.2 работают с SSL вполне стабильно и быстро. Единственное нарекание стоит адресовать Kmail 1.7.1, который при использовании защищенных протоколов стал шевелиться в несколько раз медленнее, чем обычно. В частности, на получение тестового письма из 500 байт у него в среднем уходило примерно 45 секунд.

The Bat, любимый многими на постсоветских просторах, тоже отлично работает в наших условиях. Тесты, описанные ниже, проводились на версии 3.0.1.33. Впрочем, думаю, что с большинством версий The Bat это тоже будет работать. Итак, для того чтобы включить ночного вампира в нашу связку, нужно установить все так же, как изображено на следующем снимке. Удивляться тому, что вместо SSL приходится выбирать TLS, не стоит. Главное, что такой подход работает.

При первой попытке соединения с сервером получаем следующее предупреждение. За исключением опечаток все в нем выглядит неплохо.

Первым делом жмем «Просмотреть сертификат». И убеждаемся в том, что он действительно принадлежит нам.

С помощью кнопки «Добавить к доверенным» завершаем процедуру.

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

Итак, мы добились того, что данные нормально передаются по сети в защищенном виде. Теперь осталось сделать так, чтобы никто, кроме stunnel, не смог воспользоваться старыми версиями наших сервисов. Для этого нужно, чтобы стандартные демоны SMTP, POP3, IMAP принимали соединения только от 127.0.0.1. Соответственно, клиенты смогут работать с сервером только через stunnel. В случае c postfix все довольно просто: необходимо всего лишь установить переменную inet_interfaces = localhost в файле main.cf и перезапустить его. А вот с cucipop и dkimap4 есть два варианта решения проблемы. Первый – запретить входящие соединения с помощью межсетевого экрана. Второй – использовать tcp wrapper. О первом способе написано достаточно много статей, поэтому давайте посмотрим, как работать с tcp wrapper. При обнаружении нового входящего соединения inetd вызывает демона tcpd. Тот в свою очередь просматривает файл /etc/host.allow и в зависимости от адреса вызывающей стороны принимает решение о том, что делать с соединением. Если соединение проходит через этот контроль, то его передают демону, который будет в дальнейшем его обслуживать. В отличие от межсетевого экрана, который для принятия решений оперирует адресами и номерами портов, tcpd работает с адресами клиентов и именами вызываемых демонов. По умолчанию в /etc/hosts.allow описано разрешение принимать данные от любых хостов. Это нам не подходит, а значит, надо удалить или закомментировать строку ALL : ALL : allow и добавить в файл вот это: