На рис. 5.1 изображена группа мобильных пользователей, которым необходимо отправить почту через почтовый сервер, находясь за пределами его локальной сети. Это обычный сценарий. Для того чтобы отличить этих законных пользователей от случайных спамеров, потребуется механизм безопасности на внутреннем интерфейсе. SASL, разработанный как часть проекта Cyrus в университете Карнеги — Мэллона (Carnegie Mellon University), обеспечивает Postfix средствами для контроля за пересылкой почты и определения ресурсов, с которых приходит отправляемая на сервер почта.
Системные администраторы могут использовать SASL для аутентификации многих взаимодействий «клиент—сервер», но каждый сервис, использующий SASL в операционной системе Linux, требует разных файлов конфигурации. Вы не можете просто установить SASL и конфигурировать его для всей системы.
Как SASL стал частью решения Postfix? За ответом придется отправиться в 1999 год, когда в IETF был создан стандарт, называемый служебным расширением SMTP для аутентификации. Вы увидите этот манускрипт, если вставите акроним ESMTP, например, в первую строку файла/etc/postfix/mai п. cf (см. табл. 5.1). ESMTP препятствует использованию неизвестных почтовых клиентов при отправке больших объемов почты. Он также обеспечивает безопасность при аутентификации пользователей и записи в журнал их действий.
IETF основало свое сервисное расширение ESMTP на SASL. Как часть протокола SMTP, ESMTP просто добавляет команду AUTH к командам, используемым серверами для связи и обмена данными.
Основа аутентификации SASL предоставляет несколько способов обмена личными данными пользователей и их хранения. Может использоваться системный пароль Linux (/etc/passwd, /etc/shadow или подключаемые модули аутентификации), отдельные файлы, внешние службы, например LDAP, Kerberos или sasldb (директория, разработанная в проекте Cyrus и включенная в SASL).
В этой главе мы покажем два способа использования Postfix с SASL. Сначала мы продемонстрируем простой метод, хорошо работающий на маленьких сайтах, при котором вы сможете дать каждому из пользователей почтовую учетную запись на сервере Linux. В этом методе применяются подключаемые модули аутентификации, а для логинов используется аутентификация по умолчанию. Вовторых, мы сконфигурируем более сложную систему, которая позволит аутентифицировать пользователей, не имеющих учетной записи на сервере.
Вход в систему можно рассматривать как двухступенчатый процесс. Вопервых, он определяет, является ли запрашивающий пользователь тем, за кого себя выдает. Вовторых, он обеспечивает пользователя запрошенным сервисом, который может быть командной оболочкой (bash, tcsh, zsh и т. д.) или сессией системы X Window, работающей под его именем.