Глава 11. Сетевые сервисы: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

Сетевые сервисы — это программы, с которыми пользователи взаимодействуют непосредственно в своей повседневной работе. Это верхушка айсберга информационной системы, и данная глава посвящена им; скрытые части, на которые они полагаются, — это инфраструктура, которую мы уже описали. Обычно для них требуется технология шифрования, описанная в Раздел 10.2, «X.509 certificates».

11.1. Почтовый сервер

Администраторы Falcot Corp выбрали Postfix в качестве сервера электронной почты, благодаря его надежности и легкости в конфигурации. Действительно, он спроектирован так, что каждая задача реализована в процессе с минимальным набором требуемых разрешений, что является значительной мерой против влияния проблем безопасности.

АЛЬТЕРНАТИВА Сервер Exim4

Exim4 используется в Debian в качестве почтового сервера по-умолчанию (поэтому начальная установка включает Exim4). Конфигурация поставляется в отдельном пакете exim4-config и настраивается автоматически во время установки с помощью утилиты Debconf, которая во время настройки пакета задаёт пользователю ряд вопросов, сходных с вопросами, используемыми для настройки пакета postfix.

Конфигурация может состоять либо из единственного файла (/etc/exim4/exim4.conf.template), либо из ряда файлов, размещаемых в директории /etc/exim4/conf.d/. В обоих случаях файлы используются командой update-exim4.conf в качестве шаблонов для генерации конфига /var/lib/exim4/config.autogenerated, который и используется сервером Exim4. Благодаря этому механизму, значения настроек, полученные во время конфигурирования пакета с помощью утилиты debconf и сохраняемые в файле /etc/exim4/update-exim4.conf.conf могут быть включены в конфигурацию Exim'а даже в случае, если администратор или другой пакет изменит конфигурацию по-умолчанию.

Синтаксис файла конфигурации Exim4 имеет свои особенности и кривую обучения, однако, стоит только понять эти особенности, Exim4 предстанет весьма завершённым и мощным почтовым сервером, что доказывают десятки страниц его документации.

→ https://www.exim.org/docs.html

11.1.1. Установка почтового сервера Postfix

Пакет postfix содержит основной демон SMTP . Другие пакеты (такие как postfix-ldap и postfix-pgsql) дополняют функциональность Postfix, включая доступ к отображаемым базам данных. Устанавливайте их только в том случае, если Вы знаете, что они Вам нужны.

Во время установки пакета утилита Debconf задаёт ряд вопросов, ответы на которые используются для генерации первоначальной версии конфигурационного файла /etc/postfix/main.cf.

Первый вопрос касается типа установки. В случае сервера, подключенного к сети Интернет, из предложенных ответов только два имеют отношение к делу – “Internet site” («сайт Интернет») и “Internet with smarthost” («Интернет с ретранслятором»). Первый вариант подходит для сервера, который совершает обмен почтой напрямую с сервером получателя и поэтому хорошо приспособлен для Falcot Corp. Другой вариант подходит для сервера, который получает входящую почту обычным образом, но исходящую почту отправляет через сторонний SMTP-сервер («ретранслятор»), а не напрямую на сервер получателя. Это главным образом нужно для пользователей с динамическими IP-адресами, поскольку множество почтовых серверов не принимает сообщения, исходящие напрямую от таких IP-адресов. В этом случае «ретранслятором» обычно является SMTP-сервер провайдера Интернета. Интернет-провайдеры обычно настраивают свои сервера так, что они принимают почту от их абонентов и соответственным образом пересылают её. Такой вид установки (с «ретранслятором») также подходит для серверов, которые не имеют постоянного подключения к Интернету, поскольку избавляет их от необходимости обслуживать очередь недоставляемых сообщений, требующих повторной отправки.

Второй вопрос касается полного имени машины, которое будет использовано для генерации почтовых адресов из имён локальных пользователей. Полное имя машины является частью адреса после символа «собачка» (at-sign) ("@"). В случае Falcot, ответ должен быть mail.falcot.com. Это единственный вопрос, задаваемый по-умолчанию, однако та конфигурация, которая с его помощью создаётся, не является достаточно полной для нужд Falcot, поэтому администраторы запускают команду dpkg-reconfigure postfix для того, чтобы настроить больше параметров.

Один из дополнительных вопросов касается все доменных имён, относящихся к машине. Список по умолчанию включает полное имя и несколько синонимов для localhost, но основной домен falcot.com нужно добавить вручную. В общем, это все доменные имена, для который машина является MX сервером, другими словами — все доменные имена, для которых в DNS указано, что эта машина принимает электронную почту. Эта информация завершается переменной mydestination в основном конфигурационном файле Postfix /etc/postfix/main.cf.

Рисунок 11.1. Роль DNS MX записи в процессе отсылки письма

В некоторых случаях, при установке будет задан вопрос каким сетям позволено посылать электронную почту через машину. В настройках по умолчанию, Postfix принимает почту только с самой машины, обычно добавляется и локальная сеть. Администраторы корпорации Falcot добавили 192.168.0.0/16 для ответа по умолчанию. Если вопрос не задан, подходящая переменная в конфигурационном файле — mynetworks. Смотрите пример внизу.

Локальная почта может быть доставлена через procmail. Этот команда сортирует входящую почту в соответствии с правилами, хранящимися в файле ~/.procmailrc. И Postfix, и Exim4 предлагают procmail по умолчанию, но есть альтернативы, такие как maildrop или Sieve фильтры.

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

Пример 11.1. Initial /etc/postfix/main.cf file

# См. /usr/share/postfix/main.cf.dist для более полной версии с комментариями


# Особенность Debian:  Установка имени файла приведет к тому, что  первая 
# строка этого файла будет использоваться как имя.  Значение по умолчанию в  Debian 
# /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# Добавление .domain - задача  MUA.
append_dot_mydomain = no

# Раскомментируйте следующую строку, чтобы генерировать  предупреждения "отложенной почты" 
#delay_warning_time = 4h

readme_directory = no

# См. http://www.postfix.org/COMPATIBILITY_README.html --  значение по умолчанию - 2
# для установок с нуля.
compatibility_level = 2



# Параметры TLS 
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level=may

smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache


smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.falcot.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
default_transport = smtp
relay_transport = smtp
inet_protocols = all
myorigin = /etc/mailname

БЕЗОПАСНОСТЬ Snake oil SSL сертификаты

Эти snake oilсертификаты, называемые snake oil (змеиное масло), похожи на продаваемое недобросовестными шарлатанами в прежние времена «лекарство», не имеющее абсолютно никакой ценности: вы не должны полагаться на них для аутентификации сервера, поскольку это создаваемые автоматически самоподписанные сертификаты. Однако они полезны для улучшения конфиденциальности при обмене.

Как правило, их следует использовать только для тестирования, а основная служба должна использовать подписанные сертификаты. Так Let's encrypt предлагает бесплатные подписанные сертификаты SSL/TLS, которые можно создать с помощью пакета certbot, как описано в Раздел 11.2.2, «Добавление поддержки SSL», а затем использовать в postfix следующим образом:

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/DOMAIN/privkey.pem
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_CApath = /etc/ssl/certs
smtp_tls_CApath = /etc/ssl/certs

Другой способ генерирования собственных сертификатов, используя свой собственный сервис сертификации, описан в Раздел 10.2.2, «Инфраструктура открытых ключей: easy-rsa».

11.1.2. Настройка Виртуальных доменов

Почтовый сервер может получать почту, адресованные другими доменами, помимо основного домена; они известны как «виртуальные» домены. В большинстве случаев, когда это происходит, электронные письма в конечном итоге не предназначены для локальных пользователей. Postfix предоставляет две интересные функции для обработки виртуальных доменов.

11.1.2.1. Домены виртуальных псевдонимов

Домен виртуального псевдонима содержит только псевдонимы, то есть адреса, которые пересылают электронные письма только на другие адреса.

Такой домен включен путем добавления его имени в переменную virtual_alias_domains и ссылается на файл сопоставления адресов в virtual_alias_maps переменной.

virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual

Файл /etc/postfix/virtual описывает сопоставление с довольно простым синтаксисом: каждая строка содержит два поля, разделенные пробелом; Первое поле - имя псевдонима, второе поле - это список адресов электронной почты, куда оно перенаправляет. Специальный синтаксис @domain.com покрывает все оставшиеся псевдонимы в домене.

webmaster@falcotsbrand.com  jean@falcot.com
contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
# The alias below is generic and covers all addresses within
# the falcotsbrand.com domain not otherwise covered by this file.
# These addresses forward email to the same user name in the
# falcot.com domain.
@falcotsbrand.com           @falcot.com

После изменения /etc/postfix/virtual таблица postfix-а /etc/postfix/virtual.db должна быть обновлена командой sudo postmap /etc/postfix/virtual.

11.1.2.2. Виртуальные почтовые домены

ПРЕДОСТЕРЕЖЕНИЕ Комбинированный виртуальный домен?

Postfix не позволяет использовать один и тот же домен в virtual_alias_domains и virtual_mailbox_domains. Тем не менее, каждый домен virtual_mailbox_domains неявно включен в virtual_alias_domains, что позволяет смешивать псевдонимы и почтовые ящики в виртуальном домене.

Сообщения, адресованные виртуальному почтовому домену, хранятся в почтовых ящиках, не предназначенных для локального системного пользователя.

Создание домена виртуального почтового ящика требует именования этого домена в переменной virtual_mailbox_domains и ссылки на отображение почтового ящика в virtual_mailbox_maps . Параметр virtual_mailbox_base содержит каталог в котором будут храниться почтовые ящики.

virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts

virtual_uid_maps параметр (соответственно virtual_gid_maps) указывает файл, содержащий сопоставление между адресом электронной почты и пользователем системы (соответственно группой), который "владеет" соответствующим почтовым ящиком. Чтобы получить все почтовые ящики, принадлежащие одному и тому же владельцу/группе, синтаксис static:5000 присваивает фиксированный UID/GID (здесь его значение 5000).

Опять же, синтаксис файла /etc/postfix/vmailbox довольно прост: два поля, разделённые пробелом. Первое поле - адрес электронной почты в одном из виртуальных доменов, а второе поле - расположение соответствующего почтового ящика (относительно каталога, указанного в virtual_mailbox_base. Если имя почтового ящика заканчивается символом слэш (/), электронные письма будут храниться в формате maildir; в противном случае будет использоваться традиционный формат mbox. Формат maildir использует целый каталог для хранения почтового ящика, каждое отдельное сообщение хранится в отдельном файле. В формате mbox , с другой стороны, весь почтовый ящик хранится в одном файле, и каждая строка, начиная с “From ” (From за ним следует пробел), сигнализирует о начале нового сообщения.

# Jean's email is stored as maildir, with
# one file per email in a dedicated directory
jean@falcot.org falcot.org/jean/
# Sophie's email is stored in a traditional "mbox" file,
# with all mails concatenated into one single file
sophie@falcot.org falcot.org/sophie

11.1.3. Ограничения на прием и отправку

Растущее количество незапрошенных массовых электронных писем (spam) требует всё более строгого решения о том, какие электронные письма должен принимать сервер. В этом разделе представлены некоторые из стратегий, включённых в Postfix.

Если правила отклонения будут слишком строгими, может случиться так, что даже законный трафик электронной почты будет заблокирован. Поэтому хорошей привычкой является тестирование ограничений и предотвращение постоянного отклонения запросов в течение этого времени с помощью директивы soft_bounce = yes. Если перед директивой типа reject добавить warn_if_reject, то вместо отклонения запроса будет записано только сообщение журнала.

КУЛЬТУРА Проблема спама

“Spam”(спам) - это общий термин, используемый для обозначения всех незапрошенных коммерческих электронных писем (также известных как UCE), которые наводняют наши электронные почтовые ящики; недобросовестные люди, отправляющие их, известны как спамеры. Они мало заботятся о неприятности, которую они вызывают, поскольку отправка электронной почты стоит очень мало, и только очень небольшой процент получателей должны быть привлечены предложениями при рассылке спама, чтобы заработать больше денег, чем это стоит. Процесс в основном автоматизирован, и любой адрес электронной почты, обнародованный (например, на веб-форуме или в архивах списка рассылки, или в блоге, и так далее), скорее всего, будет обнаружен роботами спамеров и подвергнут бесконечному потоку незапрошенных сообщений. Также каждый контакт, найденный в скомпрометированной системе, является целевым.

Все системные администраторы пытаются справиться с этой неприятностью с помощью спам-фильтров, но, конечно, спамеры продолжают приспосабливаться, пытаясь обойти эти фильтры. Некоторые даже арендуют сети скомпрометированных "червями" компьютеров у различных преступных синдикатов. По последним статистическим данным, до 95% всех электронных писем, циркулирующих в Интернете, являются спамом!

11.1.3.1. Ограничения доступа на основе IP-адреса

Директива smtpd_client_restrictions контролирует, какие машины могут общаться с сервером электронной почты.

Когда переменная содержит список правил, как в приведенном ниже примере, эти правила оцениваются в порядке от первого до последнего. Каждое правило может принять сообщение, отклонить его или оставить решение следующему правилу. Как следствие, порядок имеет значение, и просто переключение двух правил может привести к совершенно другому поведению.

Пример 11.2. Ограничения, основанные на адресе клиента

smtpd_client_restrictions =
    permit_mynetworks,
    warn_if_reject reject_unknown_client_hostname,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rhsbl_reverse_client dbl.spamhaus.org,
    reject_rhsbl_reverse_client rhsbl.sorbs.net,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client dnsbl.sorbs.net

Директива permit_mynetworks, используемая в качестве первого правила, принимает все электронные письма, поступающие от машины в локальной сети (как определено в переменной конфигурации mynetworks).

Вторая директива обычно отклоняет электронные письма, поступающие с компьютеров без полностью корректной конфигурации DNS. Такая допустимая конфигурация означает, что IP-адрес может быть преобразован в имя, и что это имя, в свою очередь, преобразуется в IP-адрес. Это ограничение часто бывает слишком строгим, поскольку многие почтовые серверы не имеют обратного DNS для своего IP-адреса. Это объясняет, почему администраторы Falcot предварили модификатор warn_if_reject директивой reject_unknown_client : этот модификатор превращает отказ в простое предупреждение, записанное в журналах . Затем администраторы могут отслеживать количество сообщений, которые были бы отклонены, если бы правило действительно применялось, и позже принять обоснованное решение, если они захотят включить такое применение.

СОВЕТ access tables

Критерии ограничения включают изменяемые администратором таблицы, в которых перечислены комбинации отправителей, IP-адресов и разрешённых или запрещённых имён хостов. Эти таблицы могут быть созданы с использованием копии файла /usr/share/doc/postfix/examples/access, поставляемого с postfix-doc и описанного в (5). Эта модель самодокументирована комментариями, что означает, что каждая таблица описывает свой собственный синтаксис.

В таблице /etc/postfix/access_clientip перечислены IP-адреса и сети; /etc/postfix/access_helo перечислены доменные имена; /etc/postfix/access_sender содержится адрес электронной почты отправителя. Все эти файлы должны быть превращены в хэш-таблицы (формат, оптимизированный для быстрого доступа) после каждого изменения командой sudo postmap /etc/postfix/file.

Директива check_client_access позволяет администратору настроить чёрный список и список серверов электронной почты, хранящихся в файле /etc/postfix/access_clientip. Серверы в белом списке считаются доверенными, и поэтому электронные письма, поступающие оттуда, не проходят через следующие правила фильтрации.

Последние четыре правила отвергают любые сообщения, поступающие с сервера, указанного в одном из указанных чёрных списков. RBL - аббревиатура Remote Black List, и RHSBL обозначает Right-Hand Side Black List. Разница состоит в том, что в первых - списки IP-адресов, а в последних перечисляются доменные имена. Существует несколько таких сервисов. Они перечисляют домены и IP-адреса с плохой репутацией, плохо настроенные серверы, которые спамеры используют для передачи электронных писем, а также неожиданные почтовые релеи, такие как машины, зараженные червями или вирусами.

СОВЕТ Белый список и RBL

Чёрные списки иногда включают легитимный сервер, который страдает от инцидента. В этих ситуациях все электронные письма, поступающие с одного из этих серверов, будут отклоняться, если сервер не будет включен в белый список, определённый в /etc/postfix/access_clientip.

Поэтому благоразумно включить в белый список (списки) все надёжные серверы, с которых обычно поступает много электронных писем.

11.1.3.2. Проверка достоверности команд `EHLO` или `HELO`

Каждый SMTP-обмен начинается с команды HELO (или EHLO), за которой следует имя отправляющего почтового сервера. Проверка правильности этого имени может быть интересной. Для полного соблюдения ограничений, перечисленных в smtpd_helo_restrictions, необходимо включить smtpd_helo_required. В противном случае клиенты могли пропустить ограничения, не отправив ни одной команды HELO/EHLO.

Пример 11.3. Ограничения на имя, объявленное в EHLO

smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    warn_if_reject reject_unknown_helo_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_rhsbl_helo multi.surbl.org

Первая директива permit_mynetworks позволяет всем машинам в локальной сети свободно представляться. Это важно, потому что некоторые почтовые программы недостаточно соблюдают эту часть протокола SMTP и могут представляться бессмысленными именами.

Правило reject_invalid_helo_hostname отклоняет электронные письма, когда EHLO объявляет синтаксически неправильное имя хоста. Правило reject_non_fqdn_helo_hostname отвергает сообщения, когда анонсированное имя хоста не является полностью квалифицированным доменным именем (включая доменное имя, а также имя хоста). Правило reject_unknown_helo_hostname отвергает сообщения, если объявленное имя не существует в DNS. Поскольку это последнее правило, к сожалению, приводит к большому количеству отказов, администраторы изменили его действие на простое предупреждение с модификатором warn_if_reject в качестве первого шага; они могут решить удалить этот модификатор на более позднем этапе, после проверки результатов этого правила.

reject_rhsbl_helo позволяет указать чёрный список, чтобы проверить имя хоста на RHSBL.

Использование permit_mynetworks как первое правило имеет интересный побочный эффект: следующие правила применяются только к хостам за пределами локальной сети. Это позволяет занести в чёрный список все хосты, которые объявляют себя частью сети falcot.com, например, путем добавления строки falcot.com REJECT Вы не в нашей сети! к файлу /etc/postfix/access_helo.

11.1.3.3. Приём или отклонение писем в зависимости от указанного отправителя

Каждое сообщение имеет отправителя, объявленного командой MAIL FROM протокола SMTP; опять же, эта информация может быть проверена несколькими различными способами.

Пример 11.4. Проверки отправителя

smtpd_sender_restrictions =
    check_sender_access hash:/etc/postfix/access_sender,
    reject_unknown_sender_domain,
    reject_unlisted_sender,
    reject_non_fqdn_sender,
    reject_rhsbl_sender rhsbl.sorbs.net

В таблице /etc/postfix/access_sender устанавливается особый режим для некоторых отправителей. Обычно это означает внесение некоторых отправителей в белый или чёрный список.

Правило reject_unknown_sender_domain требует действительного домена отправителя, поскольку он необходим для действительного адреса. Правило reject_unlisted_sender отклоняет местных отправителей, если адреса не существует; это предотвращает отправку по электронной почте с недействительного адреса в домене falcot.com, и сообщения, исходящие от joe.bloggs@falcot.com принимаются только в том случае, если такой адрес действительно существует.

Наконец, правило reject_non_fqdn_sender отвергает электронные письма, предположительно приходящие с адресов без полного квалифицированного доменного имени. На практике это означает отказ от писем, поступающих от user@machine: адрес должен быть объявлен как user@machine.example.com или user@example.com.

Правило reject_rhsbl_sender отвергает отправителей на основе (доменного) RHSBL сервиса.

11.1.3.4. Приём или отклонение писем в зависимости от получателя

Каждая электронная почта имеет по крайней мере одного получателя, анонсированного командой RCPT TO протокола SMTP. Эти адреса также требуют проверки, даже если это может быть менее релевантно, чем проверки, произведённые на адресе отправителя.

Пример 11.5. Проверки получателей

smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    reject_unlisted_recipient,
    reject_non_fqdn_recipient,
    permit

reject_unauth_destination является основным правилом, которое требует, чтобы внешние сообщения были адресованы нам; сообщения, отправленные на адрес, не обслуживаемый этим сервером, отклоняются. Без этого правила сервер становится открытым релеем, который позволяет спамерам отправлять незапрошенные электронные письма; поэтому это правило является обязательным, и будет лучше всего включать его в начале списка проверок, так что никакие другие правила не могут разрешить сообщение до того, как его пункт назначения будет проверен.

Правило reject_unlisted_recipient отвергает сообщения, отправленные несуществующим местным пользователям, что имеет смысл. Наконец, правило reject_non_fqdn_recipient отклоняет неполностью квалифицированные адреса; это делает невозможным отправку электронной почты на jean или jean@machine, и требует использования полного адреса вместо этого, например jean@machine.falcot.com или jean@falcot.com.

Директива permit в конце не обязательна. Но это может быть полезно в конце списка ограничений, чтобы сделать политику по умолчанию явной.

11.1.3.5. Ограничения, связанные с командой `DATA`

Команда SMTP DATA выдается перед содержимым сообщения. Она не предоставляет никакой информации как таковой, кроме объявления о том, что будет дальше. Она всё ещё может быть подвергнута проверке.

Пример 11.6. DATA проверки

smtpd_data_restrictions = reject_unauth_pipelining

Директивы reject_unauth_pipelining приводят к отклонению сообщения, если отправляющая сторона отправляет команду до того, как был отправлен ответ на предыдущую команду. Это защищает от обычной оптимизации, используемой роботами-спамерами, поскольку они обычно наплевательски относятся к ответам и сосредотачиваются только на отправке как можно большего количества электронных писем за максимально короткое время.

11.1.3.6. Применение ограничений

Хотя вышеупомянутые команды проверяют информацию на различных этапах обмена SMTP, Postfix по умолчанию отправляет фактическое отклонение в качестве ответа на командуRCPT TO.

Это означает, что даже если сообщение отклонено из-за недопустимой командыEHLO, Postfix знает отправителя и получателя при объявлении отклонения. Затем он может зарегистрировать в журнале более явное сообщение, чем это было бы, если бы транзакция была прервана с самого начала. Кроме того, ряд SMTP-клиентов не ожидают сбоев при выполнении ранних SMTP-команд, и эти клиенты будут меньше обеспокоены таким поздним отклонением.

Последним преимуществом этого выбора является то, что правила могут накапливать информацию на различных этапах обмена SMTP; это позволяет определять более подробные разрешения, такие как отклонение нелокального соединения, если оно объявляет о себе с помощью локального отправителя.

Поведение по умолчанию контролируется правилом smtpd_delay_reject.

11.1.3.7. Фильтрация на основе содержимого сообщения

Система проверки и ограничения была бы неполной без способа применения проверок к содержимому сообщения. Postfix отличает проверки, применяемые к заголовкам электронных писем, от проверок, применяемых к тексту электронного письма.

Пример 11.7. Включение фильтров на основе содержимого

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

Оба файла содержат список регулярных выражений (обычно известных как regexps или regexes) и связанных с ними действий, которые должны срабатывать, когда заголовки электронной почты (или тело) совпадают с выражением.

Пример 11.8. Пример файла /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)
/^Subject: *Your email contains VIRUSES/ DISCARD virus notification

К ОСНОВАМ Регулярное выражение

Термин регулярное выражение (сокращаемый до regexp или regex) означает общее обозначение для описания содержания и/или структуры строки символов. Определённые специальные символы позволяют определять альтернативы (например, foo|bar соответствует либо “foo”, либо “bar”), наборы разрешённых символов (например, [0-9] означает «любую цифру» и . — точка — означает «любой символ»), количественное определение (s? соответствует s или пустой строке, другими словами, 0 или 1 появление s; s+ соответствует одному или нескольким последовательным s символам; и так далее). Круглые скобки позволяют группировать результаты поиска.

Точный синтаксис этих выражений варьируется в зависимости от инструментов, использующих их, но основные функции похожи.

→ https://en.wikipedia.org/wiki/Regular_expression

Первый проверяет заголовок, упоминая программное обеспечение электронной почты; если GOTO Sarbacane (программное обеспечение для массовой рассылки электронной почты) найдено, сообщение отклоняется. Второе выражение управляет темой сообщения; если в нем упоминается уведомление о вирусе, мы можем решить не отвергать сообщение, а немедленно отказаться от него.

Использование этих фильтров - это обоюдоострое оружие, потому что легко сделать правила слишком общими и, как следствие, потерять законные электронные письма. В этих случаях будут потеряны не только сообщения, но и их отправители получат нежелательные (и раздражающие) сообщения об ошибках.

11.1.4. Настройка greylisting

“Greylisting” - это метод фильтрации, согласно которому сообщение изначально отклоняется с временным кодом ошибки и принимается только после дальнейшей попытки доставки с некоторой задержкой. Эта фильтрация особенно эффективна против спама, отправляемого многими машинами, инфицированными червями и вирусами, так как это программное обеспечение редко действует как полный агент SMTP (проверяя код ошибки и возвращая неудавшиеся сообщения позже), тем более, что многие из заготовленных адресов на самом деле недействительны и повторная попытка доставки будет означать только потерю времени.

Postfix изначально не предоставляет грейлистинг, но есть функция, с помощью которой решение о принятии или отклонении данного сообщения может быть делегировано внешней программе. Пакет postgrey содержит именно такую программу, предназначенную для взаимодействия с этой службой делегирования политики доступа.

После установки postgrey он работает как демон и слушает порт 10023. Затем Postfix можно настроить для его использования, добавив параметр check_policy_service в качестве дополнительного ограничения:

smtpd_recipient_restrictions =
    permit_mynetworks,
    [...]
    check_policy_service inet:127.0.0.1:10023

Каждый раз, когда Postfix достигает этого правила в наборе правил, он будет подключаться к демону postgrey и отправлять ему информацию о соответствующем сообщении. Со своей стороны, Postgrey учитывает триплет IP-адреса / отправителя / получателя и проверяет в своей базе данных, был ли этот же триплет замечен в последнее время. Если это так, Postgrey отвечает, что сообщение должно быть принято; если нет, в ответе указывается, что сообщение должно быть временно отклонено, и триплет записывается в базу данных.

Основным недостатком грейлистинга является то, что законные сообщения задерживаются, что не всегда является приемлемым. Это также увеличивает нагрузку на серверы, которые отправляют много законных писем.

НА ПРАКТИКЕ Недостатки грейлистинга

Теоретически "серый список" (грейлистинг) должен задерживать только отправку первого письма от данного отправителя данному получателю, и типичная задержка составляет не более нескольких минут. Реальность, однако, может немного отличаться. Некоторые крупные интернет-провайдеры используют кластеры SMTP-серверов, и когда сообщение изначально отклоняется, сервер, который повторяет попытку передачи, может отличаться от первоначального. Когда это происходит, второй сервер также получает временное сообщение об ошибке из-за серого списка и так далее; может пройти несколько часов, прежде чем попытка передачи будет предпринята сервером, который уже был задействован, поскольку SMTP-серверы обычно увеличивают задержку между повторными попытками при каждом сбое.

Как следствие, входящий IP-адрес может меняться со временем даже для одного отправителя. Но дело идет дальше: даже адрес отправителя может измениться. Например, многие серверы списков рассылки кодируют дополнительную информацию в адресе отправителя, чтобы иметь возможность обрабатывать сообщения об ошибках (известные как bounces). Каждое новое сообщение, отправленное в список рассылки, может затем проходить через серый список, что означает, что оно должно храниться (временно) на сервере отправителя. Для очень больших списков рассылки (с десятками тысяч подписчиков) это вскоре может стать проблемой.

Чтобы смягчить эти недостатки, Postgrey управляет списком таких сайтов, и сообщения, исходящие от них, немедленно принимаются без прохождения серого списка. Этот список можно легко адаптировать к местным потребностям, так как он хранится в файле /etc/postgrey/whitelist_clients.

УГЛУБЛЯЕМСЯ Выборочный серый список с milter-greylist

Недостатки серого списка могут быть смягчены только с помощью серого списка на подмножестве клиентов, которые уже считаются вероятными источниками спама (потому что они перечислены в чёрном списке DNS). Это невозможно с postgrey, но milter-greylist может быть использован таким образом.

В этом сценарии, поскольку чёрные списки DNS никогда не вызывают окончательного отказа, становится разумным использовать агрессивные черные списки, в том числе те, которые перечисляют все динамические IP-адреса от клиентов ISP (такие как pbl.spamhaus.org или dul.dnsbl.sorbs.net).

Поскольку milter-greylist использует milter интерфейс Sendmail, postfix сторона его конфигурации ограничена “smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock”. greylist.conf(5) страницы руководства /etc/milter-greylist/greylist.conf и многочисленные способы настройки milter-greylist. Вам также придется редактировать /etc/default/milter-greylist, чтобы действительно включить сервис.

11.1.5. Настройка фильтров в зависимости от получателя

Раздел 11.1.3, «Ограничения на прием и отправку» и Раздел 11.1.4, «Настройка greylisting» рассмотривают многие из возможных ограничений. Все они полезны для ограничения количества получаемого спама, но также все они имеют свои недостатки. Поэтому все чаще и чаще используется настройка набора фильтров в зависимости от получателя. В Falcot Corp "серый список" интересен большинству пользователей, но он затрудняет работу некоторых пользователей, которым требуется низкая задержка в их электронных письмах (например, в службе технической поддержки). Аналогичным образом, у коммерческого сервиса иногда возникают проблемы с получением электронных писем от некоторых азиатских провайдеров, которые могут быть занесены в чёрные списки; этот сервис запросил неотфильтрованный адрес, чтобы иметь возможность переписываться.

Postfix предоставляет такую настройку фильтров с понятием “restriction class”. Классы декларируются в параметре smtpd_restriction_classes и определяются так же, как smtpd_recipient_restrictions. Директива check_recipient_access затем определяет таблицу, сопоставляющую данному получателю соответствующий набор ограничений.

Пример 11.9. Определение классов ограничения в main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive

greylisting = check_policy_service inet:127.0.0.1:10023
aggressive =
        reject_rbl_client sbl-xbl.spamhaus.org,
        check_policy_service inet:127.0.0.1:10023
permissive = permit

smtpd_recipient_restrictions =
        permit_mynetworks,
        reject_unauth_destination,
        check_recipient_access hash:/etc/postfix/recipient_access

Пример 11.10. Файл /etc/postfix/recipient_access

# Unfiltered addresses
postmaster@falcot.com  permissive
support@falcot.com     permissive
sales-asia@falcot.com  permissive

# Aggressive filtering for some privileged users
joe@falcot.com         aggressive

# Special rule for the mailing-list manager
sympa@falcot.com       reject_unverified_sender

# Greylisting by default
falcot.com             greylisting

11.1.6. Интеграция антивирусного фильтра

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

БЕЗОПАСНОСТЬ Противоречивое обсуждение антивирусного программного обеспечения

Использование антивирусных сканеров, или так называемого антивирусного программного обеспечения, вызывает споры. Обычно существует промежуток между выпуском какой-либо вредоносной программы и добавлением правил обнаружения в базу данных антивируса. В течение этого промежутка времени программная защита отсутствует. Кроме того, для использования часто требуется запускать дополнительное программное обеспечение, например, для распаковки архивов и сканирования всех видов исполняемых файлов, что резко увеличивает потенциал злонамеренного эксплуатирования самого антивирусного программного обеспечения. Поэтому использование таких программных решений никогда не может заменить информационные кампании и простые правила поведения (никогда не открывайте непрошеные вложения и т.д.).

Администраторы Falcot выбрали clamav из одноимённого пакета.

Задача взаимодействия между антивирусом и сервером электронной почты возлагается на clamav-milter. milter (сокращаемый до mail filter ) - это программа фильтрации, специально предназначенная для взаимодействия с серверами электронной почты. Милтер использует стандартный интерфейс программирования приложений (API), который обеспечивает гораздо лучшую производительность, чем фильтры, внешние по отношению к серверам электронной почты. Милтеры были первоначально введены Sendmail, но Postfix вскоре последовал его примеру.

КРАТКИЙ ЭКСКУРС Милтер для Spamassassin

Пакет spamass-milter предоставляет milter на основе SpamAssassin, знаменитого детектора нежелательной почты. Его можно использовать для пометки сообщений как вероятного спама (путём добавления дополнительного заголовка) и / или для полного отклонения сообщений, если их оценка “spamminess” (нежелательности) превышает заданный порог.

После установки пакета clamav-milter, milter следует перенастроить для запуска на TCP-порту, а не на именованном сокете по умолчанию. Этого можно добиться с помощью команды dpkg-reconfigure clamav-milter. При запросе на “Communication interface with Sendmail”, ответ “inet:10002@127.0.0.1”.

ЗАМЕТКА Реальный TCP-порт против именованного сокета

Причина, по которой мы используем реальный TCP-порт, а не именованный сокет, заключается в том, что демоны postfix часто запускаются без чрутинга (chrooted) и не имеют доступа к каталогу, в котором размещен именованный сокет. Вы также можете решить продолжать использовать именованный сокет и выбрать местоположение в chroot (/var/spool/postfix/).

Стандартная конфигурация ClamAV соответствует большинству ситуаций, но некоторые важные параметры всё ещё могут быть настроены с помощью dpkg-reconfigure clamav-base.

Последний шаг включает в себя указание Postfix использовать недавно настроенный фильтр. Это простой вопрос добавления следующей директивы к /etc/postfix/main.cf:

# Virus check with clamav-milter
smtpd_milters = inet:[127.0.0.1]:10002

Если антивирус вызывает проблемы, эту строку можно закомментировать, и следует запустить systemctl reload postfix, чтобы это изменение было учтено.

НА ПРАКТИКЕ Тестирование антивируса

После настройки антивируса необходимо протестировать его корректное поведение. Самый простой способ сделать это - отправить тестовое электронное письмо с вложением, содержащим eicar.co (или eicar.com.zp ), которое можно скачать онлайн:

→ https://2016.eicar.org/86-0-Intended-use.html

Этот файл не является настоящим вирусом, а тестовым файлом, который все антивирусные программы, представленные на рынке, диагностируют как вирус, чтобы разрешить проверку установки.

Все сообщения, обработанные Postfix, теперь проходят через антивирусный фильтр.

11.1.7. Борьба со спамом с помощью SPF, DKIM и DMARC

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

ПРЕДОСТЕРЕЖЕНИЕ Спорная Дискуссия

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

11.1.7.1. Интеграция Sender Policy Framework (SPF)

Sender Policy Framework (SPF) используется для проверки, если определённому почтовому серверу разрешено отправлять электронные письма для данного домена. В основном он настроен через DNS. Синтаксис создаваемой записи подробно описан на:

→ http://www.open-spf.org/SPF_Record_Syntax

→ https://tools.ietf.org/html/rfc7208

→ https://en.wikipedia.org/wiki/Sender_Policy_Framework

Ниже приведена примерная запись DNS, в которой говорится, что все Mail Exchange Resource Records (Записи ресурсов почтового обмена) (MX-RRs) могут отправлять электронную почту для текущего домена, а все другие запрещены. Записи DNS не обязательно присваивать имя. Но для использования директивы include, она должна иметь её.

Name: example.org
Type: TXT
TTL:  3600
Data: v=spf1 a mx -all

Давайте бегло взглянем на запись falcot.org.

# host -t TXT falcot.org
falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"

В ней говорится, что IP-адрес отправителя должен соответствовать A-записи для отправляющего домена, или должен быть указан в качестве одной из MX-записей (Mail Exchange Resource Records) для текущего домена, или должен быть одним из трёх упомянутых адресов IP4. Все остальные хосты должны быть помечены как запрещённые для отправки электронной почты для домена отправителя. Последнее называется "soft fail" («мягкий сбой») и предназначено для соответствующей маркировки электронного письма, но при этом его принятия.

Почтовый сервер postfix может проверять запись SPF на наличие входящих писем с помощью пакета postfix-policyd-spf-python, это - агент политики, написанный на Python. Файл /usr/share/doc/postfix-policyd-spf-python/README.Debian описывает необходимые шаги для интеграции агента в postfix, поэтому не будем здесь повторяться.

Конфигурация выполняется в файле /etc/postfix-policyd-spf-python/policyd-spf.conf, который полностью документирован в policyd-spf.conf(5) и /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. Основные параметры конфигурации: HELO_reject и Mail_From_reject, которые настраивают, следует ли отклонять электронные письма (Fail) или принимать с добавлением заголовка (False), если проверки не пройдут. Последнее часто бывает полезно, когда сообщение дополнительно обрабатывается спам-фильтром.

Если результат предназначен для использования opendmarc (Раздел 11.1.7.3, «Интегрированная (Аутентификация сообщений на основе домена, отчетность и соответствие) Domain-based Message Authentication, Reporting and Conformance (DMARC)»), затем Header_Type должен быть установлен на AR.

Обратите внимание, что spamassassin содержит плагин для проверки записи SPF.

11.1.7.2. Integrating DomainKeys (DKIM) Подписание и проверка

Стандарт Domain Keys Identified Mail (DKIM) - это система аутентификации отправителя. MTA (агент транспорта почты), здесь, postfix добавляет цифровую подпись, связанную с именем домена, в заголовок исходящих писем. Получающая сторона может проверить текст сообщения и поля заголовка, проверив подпись по открытому ключу, который извлекается из DNS-записей отправителей.

→ http://dkim.org/

Необходимые инструменты поставляются в комплекте пакетов opendkim и opendkim-tools.

ПРЕДОСТЕРЕЖЕНИЕ Программное обеспечение для списков рассылки и DKIM

Менеджеры списков рассылки часто переписывают некоторые заголовки электронных писем, что приводит к недействительным подписям DKIM. Даже использование relaxed канонизации не всегда предотвращает это. Поэтому администраторы должны уделять пристальное внимание файлам журналов почтовых серверов, чтобы выявить такие проблемы. В противном случае такие электронные письма могут быть помечены как спам и отклонены.

Сначала необходимо создать закрытый ключ с помощью команды opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR должно быть уникальным именем ключа. Это может быть просто "mail" или дата создания, если вы планируете ротацию ключей.

Пример 11.11. Создать закрытый ключ для подписи электронных писем от falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys
# chown opendkim.opendkim /etc/dkimkeys/mail.*

Это создаст файлы /etc/dkimkeys/mail.private и /etc/dkimkeys/mail.txt и установит для них соответствующие права владения. Первый файл содержит приватный (закрытый) ключ, а второй — публичный (открытый) ключ, который необходимо добавить в DNS:

Name: mail._domainkey
Type: TXT
TTL:  3600
Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"

В пакете opendkim в Debian по умолчанию используется размер ключа 2048 бит. К сожалению, некоторые DNS-серверы могут обрабатывать только текстовые записи не длиннее 255 символов, что превышает выбранный размер ключа по умолчанию. В этом случае используйте опцию -b 1024 чтобы выбрать меньший размер ключа. Если opendkim-testkey возвращает результат успешно, то запись успешно настроена. Синтаксис записи объясняется здесь:

→ https://tools.ietf.org/html/rfc6376

→ https://en.wikipedia.org/wiki/DKIM

Чтобы сконфигурировать opendkim, SOCKET и RUNDIRдолжны быть выбраны в /etc/default/opendkim. Заметьте что SOCKET должен быть доступен из postfix в его chroot среде. Дальнейшая настройка осуществляется в /etc/opendkim.conf. Ниже приведен фрагмент конфигурации, который позволяет убедиться, что Domain "falcot.com" и его субдомены (SubDomain) подписаны Selector "mail" и единственным приватным ключом (KeyFile) /etc/dkimkeys/mail.private. "relaxed" Canonicalization как для заголовка, так и для тела письма допускает лёгкие модификации (например, с помощью программного обеспечения списка рассылки). Фильтр работает как при подписании ("s"), так и при проверке ("v") Mode. Если подпись не проходит проверку (On-BadSignature), почта должна быть помещена в карантин ("q").

[...]
Domain                  falcot.com
KeyFile                 /etc/dkimkeys/mail.private
Selector                mail

[...]
Canonicalization        relaxed/relaxed
Mode                    sv
On-BadSignature         q
SubDomains              yes

[...]
Socket                  inet:12345@localhost

[...]
UserID                  opendkim

Также возможно использовать несколько селекторов/ключей (KeyTable), доменов (SigningTable) и указать внутренние или доверенные хосты (InternalHosts, ExternalIgnoreList), которые могут отправлять почту через сервер как один из подписанных доменов без учётных данных.

Следующие директивы в /etc/postfix/main.cf созданы postfix используя это фильтр:

milter_default_action = accept
non_smtpd_milters = inet:localhost:12345
smtpd_milters = inet:localhost:12345

Чтобы разграничить подписание и проверку, иногда полезнее добавить директивы к службам в /etc/postfix/master.cf.

Более подробная информация доступна в каталоге /usr/share/doc/opendkim/ и страницах руководства opendkim(8) и opendkim.conf(5).

Заметьте что spamassassin содержит плагин для проверки записи DKIM.

11.1.7.3. Интегрированная (Аутентификация сообщений на основе домена, отчетность и соответствие) Domain-based Message Authentication, Reporting and Conformance (DMARC)

Стандарт Domain-based Message Authentication, Reporting and Conformance (DMARC) может использоваться для определения записи DNS TXT с именем _dmarc и действия, которое следует предпринять, если электронные письма, содержащие ваш домен в качестве отправляющего хоста, не проходят проверку с использованием DKIM и SPF.

→ https://dmarc.org/overview/

Давайте посмотрим на записи двух крупных провайдеров:

# host -t TXT _dmarc.gmail.com
_dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
# host -t TXT _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"

У Yahoo строгая политика в отношении reject все электронных писем, которые якобы отправлены с учётной записи Yahoo, но с отсутствующими или непройденными проверками DKIM и SPF. Google Mail (Gmail) пропагандирует очень мягкую политику, согласно которой такие сообщения из основного домена по-прежнему должны приниматься (p=none). Для поддоменов они должны быть помечены как спам (sp=quarantine). Адреса, указанные в ключе rua могут использоваться для отправки агрегированных отчетов DMARC. Полный синтаксис описан здесь:

→ https://tools.ietf.org/html/rfc7489

→ https://en.wikipedia.org/wiki/DMARC

Почтовый сервер postfix также может использовать эту информацию. Пакет opendmarc содержит необходимый milter. Подобно opendkim SOCKET и RUNDIR должен быть выбран в /etc/default/opendmarc (для сокетов Unix вы должны убедиться, что они находятся внутри chroot postfix-а, чтобы их можно было найти). Конфигурационный файл /etc/opendmarc.conf содержит подробные комментарии и также объясняется в opendmarc.conf(5). По умолчанию электронные письма, не прошедшие проверку DMARC, не отклоняются, а помечаются путем добавления соответствующего поля заголовка. Чтобы изменить это, используйте RejectFailures true.

milter затем добавляется к smtpd_milters и non_smtpd_milters. Если мы настроили milters opendkim и opendmarc для работы на портах 12345 и 54321, запись в /etc/postfix/main.cf выглядит так:

non_smtpd_milters = inet:localhost:12345,inet:localhost:54321
smtpd_milters = inet:localhost:12345,inet:localhost:54321

milter также может выборочно применяться к сервису в /etc/postfix/master.cf.

11.1.8. Аутентифицированный SMTP

Для отправки электронной почты необходимо, чтобы SMTP-сервер был доступен; для отправки через него электронных писем также требуется указанный SMTP-сервер. Для роуминговых пользователей может потребоваться регулярное изменение конфигурации SMTP-клиента, поскольку SMTP-сервер Falcot отклоняет сообщения, поступающие с IP-адресов, по-видимому, не принадлежащих компании. Существует два решения: либо роуминговый пользователь устанавливает SMTP-сервер на свой компьютер, либо он использует сервер компании с аутентификацией в качестве сотрудника. Первое решение не рекомендуется, поскольку компьютер не будет постоянно подключен и не сможет повторить отправку сообщений в случае возникновения проблем; сосредоточимся на втором решении.

SMTP аутентификация в Postfix полагается на SASL (Simple Authentication and Security Layer). Для этого требуется установка пакетов libsasl2-modules и sasl2-bin, затем регистрация пароля в базе данных SASL для каждого пользователя, которому требуется аутентификация на SMTP-сервере. Это делается с помощью команды saslpasswd2, которая принимает несколько параметров. Опция -u определяет домен аутентификации, который должен соответствовать параметру smtpd_sasl_local_domain в конфигурации Postfix. Опция -c позволяет создать пользователя и -f позволяет указать файл, который будет использоваться, если базу данных SASL необходимо хранить не в умолчальном расположении (/etc/sasldb2).

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean
[... type jean's password twice ...]

Обратите внимание, что база данных SASL была создана в каталоге Postfix. Чтобы обеспечить согласованность, мы также превращаем /etc/sasldb2 в символическую ссылку, указывающую на базу данных, используемую Postfix, командой ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.

Теперь нам нужно настроить Postfix для использования SASL. Сначала необходимо добавить пользователя postfix в группу sasl, чтобы он мог получить доступ к базе данных учетных записей SASL. Для включения SASL также необходимо несколько новых параметров, а параметр smtpd_recipient_restrictions необходимо настроить, чтобы клиенты, прошедшие проверку подлинности SASL, могли свободно отправлять электронные письма.

Пример 11.12. Включение SASL в /etc/postfix/main.cf

# Включить аутентификацию SASL
smtpd_sasl_auth_enable = yes
# Определить SASL домент аутентификации для использования
smtpd_sasl_local_domain = $myhostname
[...]
# Добавить permit_sasl_authenticated перед reject_unauth_destination
# разрешить ретранслировать почту, отправляемую SASL-аутентифицированными пользователями
smtpd_recipient_restrictions =
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_destination,
[...]

It is usually a good idea to not send passwords over an unencrypted connection. Postfix allows using different configurations for each port (service) it runs on. All these can be configured with different rules and directives in the /etc/postfix/master.cf file. To turn off authentication at all for port 25 (smtpd service) add the following directive:

smtp      inet  n       -       y       -       -       smtpd
    [..]
    -o smtpd_sasl_auth_enable=no
    [..]

Если по какой-то причине клиенты используют устаревшую команду AUTH (так делают некоторые очень старые почтовые клиенты), совместимость с ними можно включить с помощью директивы broken_sasl_auth_clients.

EXTRA Аутентифицированный SMTP клиент

Большинство почтовых клиентов могут аутентифицироваться на SMTP-сервере перед отправкой исходящих сообщений, и использование этой функции — это просто вопрос настройки соответствующих параметров. Если используемый клиент не предоставляет эту функцию, обходной путь — использовать локальный сервер Postfix и настроить его для ретрансляции электронной почты через удалённый SMTP-сервер. В этом случае локальный Postfix сам будет клиентом, аутентифицирующимся с помощью SASL. Вот необходимые параметры:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relay_host = [mail.falcot.com]

Файл /etc/postfix/sasl_passwd должен содержать имя пользователя и пароль, которые будут использоваться для аутентификации на сервере mail.falcot.com. Вот пример:

[mail.falcot.com]   joe:LyinIsji

Как и все индексированные файлы Postfix, этот файл необходимо превратить в /etc/postfix/sasl_passwd.db командой postmap.