Почтовый пакет TPmail для Unix систем

Выбор языка

[анг] [рус]

Модуль milter_connect. Описание и работа с ним.

Модуль milter-connect
Список возможностей milter-connect
Ключи модуля milter-connect
Конфигурационный файл для milter-connect
Включение базовых возможностей в конфигурационном файле
Статические белые и черные списки
Алгоритм LMTA
Алгоритм RHTA
Механизм исключений в виде бюджетов (accounts)
Автоматические динамические белые/черные листы (auto dynamic white/black lists)
Динамические серые листы (grey lists)
Динамические белые листы с проверкой (checked white lists)
Списки локальных получателей (local recipients list)
Порядок просмотра различных списков при работе с конвертом сообщения
Регулярные и простые выражения
Пример конфигурационного файла
Примеры контроля соединений
Примеры для бюджетов (accounts)
Программа диагностики mc_client

Общие замечания о milter модулях смотри в разделе о модуле milter-agent.
Модуль milter-connect предназначен для эффективного контроля за соединениями до начала приема сообщения. Модуль включает в себя встроенный антиспам фильтр на базе алгоритмов LMTA и RHTA. Модуль milter-connect предоставляет возможности управления статическими белыми-черными списками и автоматическими динамическими списками, использующми результаты работы эвристического алгоритма LMTA. Модуль позволяет расширить возможности программы sendmail, добавляя разнообразные методы фильтрации соединений и приема/отправки почтовых сообщений. Встроенный антиспам фильтр является эффективным и производительным в сравнении с традиционными системами контентной фильтрации почты и не использует вообще глобальных серверов черных списков.

Модуль milter-connect обладает следующими возможностями для контроля сообщений (соединений):

Динамическая конфигурация. Модуль автоматически загружает новую конфигурацию, если в ней не найдено синтаксических ошибок.
Загрузка по требованию. Конфигурация может быть загружена по внешнему сигналу (USR1).
Синтаксис конфигурационного файла прост и прозрачен для понимания и использования.
Поддержка регулярных выражений для списков (IEEE Std. 1003.2).
Выдача текущей конфигурации и состояния модуля.
Не останавливать обработку в случае фатальных ошибок - переполнение дисков и т.д.
Детализация событий в журнале по уровням.
Списки локальных получателей для вариантов прозрачного прхождения почты (local recipients list).
"Черные" списки отказа по приему (block black lists).
"Белые" списки для приема без проверки (accept white lists).
"Серые" списки для отложенного приема (reject/accept grey lists based on LMTA).
Динамические "белые/черые" списки (по отправителю и получателю).
Эвристический алгоритм проверки легитимности отправителя (LMTA - Legacy Mail Testing Algorithm).
Алгоритм проверки служебного заголовка письма (RHTA - Received Header Testing Algorithm).
Добавление результатов проверки по алгоритмам в заголовок письма.
Отказ в приеме по алгоритму LMTA (без приема сообщения).
Кэширование результатов проверки по алгоритму LMTA с целью снижения нагрузки на DNS серверы.
Белые и черные списки используются до стадии начала приема сообщения с использованием различных сочетаний имен, адресов и узлов.

Программа milter_connect поддерживает следующие опции командной строки
(они также описаны в стандартном руководстве man для milter_connect):

Опция	Назначение
-h	печатать краткую помощь
-V	печатать версию
-v	более детальный вывод информации
-c config	использовать данный файл как конфигурационный (по умолчанию=/etc/mail/milter-connect.conf)
-p pipe	локальный сокет (Unix domain socket) для обмена данными с sendmail (по умолчанию=unix:/var/spool/milter-connect/sock)
-i socket	локальный сокет (Unix domain socket) для обмена данными с пользователем (по умолчанию=unix:/var/spool/milter-connect/cmd)
-t timeout	таймаут операций для сокета sendmail (по умолчанию=0)
-u user	имя пользователя, с правами которого работает milter-connect (по умолчанию=_milter-connect)
-l vlevel	уровень отладочной печати (по умолчанию=0)
-d mode	режим работы (0=демон,>0=терминал отладки)
-A	использовать блокировку для доступа к конфигурации
-C	динамический контроль за изменением конфигурации
-E	останов при любой ошибке
-B	разрешить черные списки
-W	разрешить белые списки
-X	включить поддержку регулярных выражений (POSIX.2)
-H	разрешить добавление служебных заголовков в сообщение
-L	включить кэширование результатов алгоритма LMTA
-E	разрешить отказ в приеме по алгоритму LMTA
-R	разрешить работу алгоритма LMTA
-T	включить вывод для проверки LMTA в журнал
-Z	разрешить работу алгоритма RHTA
-z	разрешить отказ по алгоритму RHTA
-Y	включить профилирование алгоритмов LMTA/RHTA
-r	включить вывод RHTA для информации в заголовк письма
-S	включить вывод статистики по заголовкам (RHTA) в журнал
-P	разрешить вывод служебных заголовков с результатами проверки по алгоритмам в сообщение
-Q	использовать последнего в списке получателей при обработке сообщения (по умолчанию=первый из списка)
-a	проверять аутентифицированных пользователей (SASL и другие протоколы)
-1	упрощенная конфигурация с LMTA (опции -HYPUMSXWBRL)
-2	упрощенная конфигурация с RHTA (опции -HYPUMSZrey)
-O	Разрешить динамические белые списки
-e	разрешить вывод найденных ошибок в заголовок (RHTA)
-M	разрешить запись в заголовок временной отметки и имени хоста
-U	разрешить запись о спаме в теме письма
-y	разрешить запись других флагов RHTA в заголовок
-w	извлечь информацию из конфигурации sendmail для динамических белых листов
-x	извлечь информацию из локальной конфигурации хоста для динамических белых листов

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

Пример 1. Запуск модуля milter-connect.
# /usr/local/libexec/milter_connect -c /etc/mail/milter/milter-connect.conf -u mailnull -vrAHCTSRWBXZPYL -l 1

Включение базовых возможностей в конфигурационном файле.
Всегда используйте программу mc_client для проверки корректного включения опций!

[General_Parameters]
### Reject algorithm print mode (only print requests) (LMTA)
### Тестовая запись параметров для вызова LMTA (нужна для разработчиков)
test_rej_algorithm = 1
### Reject algorithm (run but no real action on reject) (LMTA)
### Обязательно для запуска LMTA, но без отказа
run_rej_algorithm = 1
### Reject algorithm (run and reject as all in real life!) (LMTA)
### Разрешть отказ по LMTA (обязательно run_rej_algorithm=1)
enable_reject = 1
### Enable LMTA to cache results to reduce DNS and network loading
### Кэшировать результаты LMTA
enable_lmta_cache = 1
### Print execution time profiling
### Печатать время исполнения
time_profiling = 1

### Add message headers but not reject message
### Добавить сообщения в служебный заголовок
enable_spam_info_header = 1
enable_spam_info_subject = 1
enable_spam_info_timestamp = 1

### Enable algorithm (RHTA) to work
### Разрешить RHTA (обязательно в 1)
enable_algo2 = 1
### Reject all if not accepted by algorithm (RHTA)
### Разрешить отказ по RHTA (не рекомендуется!)
##reject_all_by_algo2 = 1
### add message header about RHTA results
### Добавить заголовок с RHTA результатом
enable_spam_rhta_info = 1
### add message header about RHTA detected errors
### Добавить RHTA расширенную диагностику
rhta_errors_to_header = 1
### Print meaning of flags from algorithm (RHTA)
### Печать значение флагов для RHTA результатов
print_flags_algo2 = 1

### Enable auto white/black list collection to reduce user's questions
### Разрешить автоматические динамические белые/черные листы
enable_auto_collect_lists = 1
### Auto_list bw state file (/var/spool/milter-connect/auto_list.state)
### Файл состояния для авто б/ч списка
auto_list_state_file = "/var/spool/milter-connect/auto_list.state"
### Auto_list cache state file (/var/spool/milter-connect/auto_cache.state)
### Файл состояния для авто б/ч кэша
auto_cache_state_file = "/var/spool/milter-connect/auto_cache.state"

### Enable grey_lists to enable pass for some people on accounts (based on LMTA)
### Разрешить серые листы для accounts
enable_grey_lists_cache = 1
### Enable random reject after grey lists passing
### Разрешить случайный отказ после приема (серые листы)
enable_grey_lists_random_reject = 1
### Enable random delay [min..max] instead fixed
### Разрешить случайное время задержки вместо фиксированного времени
enable_grey_lists_random_delay = 1

### Enable local recipients check against database ### Разрешить проверку локальных получателей по базе enable_local_recipients_check = 1 ### Enable local recipients reject if not found in database ### Разрешить отказ в приеме при проверке локального получателя ### если последний не найден в базе enable_local_recipients_reject = 1
### Enable black lists (local)
### Разрешить локальные черные листы
enable_local_black_lists = 1
### Enable white lists (local)
### Разрешить локальные белые листы
enable_local_white_lists = 1

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

Алгоритмы LMTA и RHTA были созданы сравнительно недавно как средства нового поколения борьбы с нежелательной корреспонденцией (спам и др.). Оба алгоритма базируются на принципе: "мысли глобально - действуй локально".

Алгоритм LMTA является пока одним из немногих эффективным алгоритмом, отсекающим нежелательную корреспонденцию (далее просто спам) без фильтрации контента (содержимого письма). Алгоритм LMTA получает на входе четыре параметра (в простейшем варианте достаточно всего двух): IP адрес узла-отправителя, почтовый адрес отправителя (из конверта), доменное имя узла-отправителя, имя получаемое на стадии helo протокола SMTP. Используя эти параметры алгоритм пытается определить, откуда в реальности посылается сообщение. Эффективность алгоритма на разных видах трафика будет от 50 до 99 процентов. Впрочем, в отличие от других систем, почтовый пакет TPmail имеет модуль статистики sma_stat, который позволяет администраторам самим увидеть реальные результаты. Заметим главное, что алгоритм LMTA позволяет отказывать в приеме сообщения еще на стадии проверки конверта, т.е. до приема тела сообщения. Если мы не принимаем реально сообщения, то не тратим время и силы на дальнейшую обработку спамерских писем - это особенно выгодно когда подобных писем тысячи и более. Однако алгоритм LMTA в ряде случаев оказывается слишком сильным оружием, например, когда пользователь отправляет письмо с адресом публичного почтового сервиса, но из адресного пространства другого Интернет провайдера. В таких случаях помогут статические белые листы. Если же организации нужно принимать всю почту, то можно отключить для всех или определенных пользователей опцию по отказу приема сообщений с использованием алгоритма LMTA, однако при этом можно разрешить запись в служебный заголовок сообщения информацию о результатах проверки с алгоритмом LMTA. Эту информацию можно использовать позже, например, в фильтрах пользовательских почтовых программ.

Алгоритм RHTA проверяет корректность служебного заголовка на соответствие стандартам RFC 2821 и 2822. Далее алгоритм выдает свои результаты по проверке, в том числе, и в детальном текстовом виде с указаниями на ошибки. В алгоритм встроено распознавание писем от ряда популярных почтовых серверов как Microsoft Exchange, IBM/Lotus Domino, и ряда других, которые, к сожалению, имеют либо не совсем верную реализацию стандартов, либо неверно настраиваются администраторами этих почтовых систем. Письма с подобных серверов приходится принимать регулярно, поэтому алгоритм RHTA будет постоянно указывать на эти ошибки. Однако в отличие от алгоритма LMTA здесь не используется автоматический отказ от приема сообщения, поэтому администратор может добавить соответствующий фильтр в milter-agent для блокировки писем, содержащих отказ по алгоритму RHTA. Пример такого фильтра есть в поставке модуля milter-agent. В общем случае рекомедуется возложить такую проверку на пользовательские почтовые программы. Алгоритм RHTA требует твердого соблюдения буквы и духа почтовых стандартов RFC.

Для тех особых случаев, когда некоторым пользователям должны быть разрешены исключения из установленных правил существует механизм локальных исключений - бюджеты (accounts). Действие бюджетов позволяет использовать другую политику для выбранных пользователей. Например, если LMTA разрешен к проверке и отказу глобально, то бюджет пользователя разрешает не проверять или не отказывать в приеме после проверки. Справедливо и наоборот, можно проверить на группе пользователей результаты работы с алгоритмом LMTA с отказом по приему, а для остальных пользователей пока еще анти-спам фильтр отключен. Бюджеты используются только для получения почты.
В бюджетах пользователей (accounts) можно включать/отключать следующие опции:
- запуск алгоритма LMTA;
- отказ по алгоритму LMTA (если разрешен запуск);
- исключаться из глобальных белых/черных списках;
- добавлять информацию о результатах проверки LMTA и RHTA как служебные поля или изменять тему сообщения;
- использовать списки отложенного приема ("серые" листы - grey lists) на базе алгоритма LMTA;

Автоматические динамические белые/черные листы предназначены для ситуаций, когда по тем или иным причинам невозможно использовать статические списки и для первоначального сбора статистики о потенциальных кандидатах для занесения в статический листы. Автоматические списки используют две таблицы: кэш (auto cache) и основную (auto list). Для хранения промежуточного состояния между загрузками используется файл состояния для каждого из списков. Поясним принцип работы автоматического списка на примере. Предложим, что включен отказ по алгоритму LMTA как глобальная установка. Должны быть включены опции автоматических списков и дополнительно описаны локальные домены (для внутренних отправителей). Доменом считается все справа после символа @. Письмо снаружи не проходит по LMTA (например, его шлют из штата Техас с украинским доменом в качестве адреса-отправителя). В этом случае, если не действовали какие-то другие правила, то информация о соединении попадает в кэш. В течение суток (это время по умолчанию) если внутренний пользователь напишет данному лицу, то следующее письмо от указанного внешнего абонента будет принято через динамический белый лист. То же самое случилось бы, если б вначале написал локальный пользователь, а затем ответил бы внешний абонент. Теперь если эта пара будет продолжать пересываться, то каждое следующее письмо с любой стороны увеличивает время жизни в автоматическом списке на одни сутки (значение по умолчанию), не больше чем на месяц.

Листы отложенного приема или "серые" листы отличаются от подобных реализциий в других системах. Во-первых, они действуют только для бюджетов пользователей (accounts), а во-вторых, отказ от приема не является произвольным (он базируется на результатах работы алгоритма LMTA). Это позволяет избежать бессмысленных тотальных отказов как это происходит в других системах, что добавляет еще большую нагрузку на отправляющие почтовые серверы. Поскольку эти листы реализованы только для бюджетов, то это позволяет использовать их выборочно. Метод "серых" списков не является технически сильным приемом, он эффективен лишь в силу известных причин.
В текущей реализации серых листов есть две дополнительных опции в политике серых листов:
(1) случайный отказ (random_reject) - это вероятностный отказ при прихождении по истечении начального периода отказа;
(2) плавающее окно начального периода отказ (random_delay) - выбор начального периода из интервала;

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

Порядок просмотра различных списков при работе с конвертом сообщения

Во время обработки конверта сообщения списки просматриваются в следующем порядке:
(1) динамические белые-черные списки (white/black dynamic_lists);
(2) статические белые списки (static white lists);
(3) статические черные списки (static black lists);
(4a) проверка бюджетов (accounts) - если LMTA не разрешен для бюджета, то перейти к следующей стадии приема сообщения;
(4b) проверка на присутствие в локальных белых или черных списках для бюджета;
(5) получение результатов работы алгоритма LMTA;
(6) проверка бюджетов (отказ по LMTA если разрешено в бюджете, серые списки с временным отказом);
(7) если разрешен глобальный отказ по LMTA, то отказать в приеме при отрицательном ответе из алгоритма LMTA;
(8) проверка по списку локальных получателей, если такая проверка была разрешена;
Подняв уровень детализации вывода для модуля, можно увидеть порядок прохождения листов при обработке конверта сообщения.

Регулярные выражения допускаются в большинстве списков.
Для краткой справки по регулярным выражениям можно посмотреть re_format(7) и regex(3).
Вы можете использовать простые выражения вместо регулярных. Простые выражения
требуют точного совпадения с начала буфера. В них допускается перечисление через пробел.
В отличие от простых выражений при использовании регулярных выражений ищется совпадение
с образцом во всем буфере, необязательно с начала буфера. Следующие выражения будут эквивалентны:
(1) "user1@domain.com" (простое) и "^user1@domain.com$" (регулярное);
(2) "user1@domain.com user2@host.domain.net" (простое) и "^(user1@domain.com|user2@host.domain.net)$" (регулярное);
Для удобства администраторов в состав модуля включена программа check_regex для проверки регулярных выражений.

Пример конфигурационного файла (входит в комплект поставки): milter-connect.conf.sample

Примеры контроля соединений (белые и черные списки).

Пример 1. Не принимать соединения с узла (статический черный список).
[Filter]
reject_stage = connect
reject_message = "Prohibited by administrative policy."
reject_hostaddr = "192.168.0.2"

Пример 2. Разрешить переписку до указаной даты (статический белый лист с конечным времени жизни).
[Filter]
accept_stage = envrcpt
accept_hostname = "host1.domain.ru"
accept_date = "31122003"
accept_envfrom = "user1@host1.domain1.ru user2@host1.domain.ru"
accept_envrcpt = "user3@host3.domain3.ru"

Пример 3. Запретить пересылку между пользователями (статический черный список).
[Filter]
reject_stage = envrcpt
reject_envfrom = "user1@host2.domain.ru user2@host2.domain.ru"
reject_envrcpt = "user1@host3.domain.ru"
reject_message = "Non-legacy mail not accepted"

Пример 4. Разрешить прием между пользователями (статический белый список).
[Filter]
accept_stage = envrcpt
accept_envfrom = "(user1|user2)@host2\.domain\.ru"
accept_envrcpt = "user1@(()|.*\.)host3\.domain\.ru"

Пример 5. Разрешить прием всей почты от данного пользователя (статический белый список).
[Filter]
accept_stage = envrcpt
accept_envfrom = "user2@foreigndomain.com"
accept_envrcpt = ".*"

Пример 6. Разрешить прием почты для данного пользователя (статический белый список).
[Filter]
accept_stage = envrcpt
accept_envfrom = ".*"
accept_envrcpt = "user1@mydomain.ru"

Пример 7. Запретить прием всей почты от данного пользователя (статический черный список).
[Filter]
reject_stage = envrcpt
reject_envfrom = "user2@foreigndomain.com"
reject_envrcpt = ".*"

Пример 8. Запретить прием почты для данного пользователя (статический черный список).
[Filter]
reject_stage = envrcpt
reject_envfrom = ".*"
reject_envrcpt = "user1@mydomain.ru"

Пример 9. Разрешить переписку между данными пользователями (статический белый список).
[Filter]
accept_stage = envrcpt
accept_envfrom = "(user1@mydomain.ru|user2@foreign.com)"
accept_envrcpt = "(user2@foreign.com|user1@mydomain.ru)"

Пример 10. Запретить переписку между данными пользователями (статический черный список).
[Filter]
reject_stage = envrcpt
reject_envfrom = "(user1@mydomain.ru|user2@foreign.com)"
reject_envrcpt = "(user2@foreign.com|user1@mydomain.ru)"

Пример 11. Начальные установки для локальных машин (статический белый список).
# Accepted hosts
##Added: 16.09.2004
[Filter]
accept_stage = envrcpt
accept_hostaddr = "192.168.0.1 - 192.168.0.14"
accept_envfrom = "@(()|.*\.)ho(me|ney)\.ru"
accept_envrcpt = ".*"

# Local hosts
##Added: 16.09.2004
[Filter]
accept_stage = envrcpt
accept_hostaddr = "127.0.0.1"
accept_envrcpt = ".*"

# PROHIBITED FORGED SENDERS OF OUR DOMAINS
##Added: 16.09.2004
[Filter]
reject_stage = envrcpt
reject_message = "Rejected forged senders of our domains"
reject_envfrom = "@(()|.*\.)ho(me|ney)\.ru"
reject_envrcpt = "@(()|.*\.)ho(me|ney)\.ru"

Пример 12. Разрешить прием всей почты от аутентифицируемых пользователей (статический белый список).
[Filter]
accept_stage = envrcpt
accept_envfrom = "@ourdomain\.ru"
accept_envrcpt = ".*"
auth_user_credentials = ".*"
auth_nonauth_users_also = 0
#auth_user_credentials = "(user1|user2|user3)"
#auth_user_alt_names = ".*"

Примеры для бюджетов (accounts)

Пример 1. Разрешить прием всей почты для данного пользователя (аналогично белому статическому листу).
[Account]
account_recipient_name = "user1@mydomain.ru"
account_global_run_reject_algorithm = 0
account_global_enable_reject = 0
account_local_spam_info_header = 0

Пример 2. Разрешить проверку по алгоритму LMTA без отказа в приеме, с маркировкой письма.
[Account]
account_recipient_name = "user@domain.ru"
account_global_run_reject_algorithm = 1
account_global_enable_reject = 0
account_local_spam_info_header = 1

Пример 3. Разрешить проверку по алгоритму LMTA с возможным отказом в приеме, с маркировкой письма.
[Account]
account_recipient_name = "(user1|user2)@domain\.ru"
account_global_run_reject_algorithm = 1
account_global_enable_reject = 1
account_local_spam_info_header = 1

Пример 4. Разрешить все проверки по алгоритму LMTA с возможным отказом и с полной маркировкой письма.
[Account]
account_recipient_name = "(user1|user2)@domain\.ru"
account_global_run_reject_algorithm = 1
account_global_enable_reject = 1
account_local_spam_info_header = 1
account_local_spam_info_subject = 1
account_global_enable_grey_lists = 1
###account_global_enable_checked_lists = 1

Пример 5. Аналогичен примеру 4, только использует все возможности серых листов.
[Account]
account_recipient_name = "user3@host.domain.net"
account_global_run_reject_algorithm = 1
account_global_enable_reject = 1
account_local_spam_info_header = 1
account_local_spam_info_subject = 0
account_global_enable_grey_lists = 1
account_grey_lists_enable_random_reject = 1
account_grey_lists_enable_random_delay = 1
#account_grey_lists_cache_rec_ttl = 3600
#account_grey_lists_initial_reject_time = 900
#account_grey_lists_init_reject_time_min = 900
account_grey_lists_init_reject_time_max = 1500

Пример 6. Использовать локальные листы для бюджета.
[Account]
account_recipient_name = "user@host.domain.net"
account_local_black_lists = 1
account_local_white_lists = 1
[Filter]
local_lists_account_name = "user@host.domain.net"
accept_stage = envrcpt
accept_envfrom = "@domain2.net"
accept_envrcpt = "user@host.domain.net"

Программа mc_client взаимодействует с загруженным модулем milter-connect через локальный сокет (Unix domain socket). Для краткой помощи можно вызвать mc_client без параметров.

Пример использования 1. Вернуть текущие глобальные настройки milter-quota.
# mc_client /var/spool/milter-connect/cmd 1

Пример использования 2. Вернуть текущее состояние LMTA кэша в milter-connect.
# mc_client /var/spool/milter-connect/cmd 5

Last modified: $Date: 2009-05-12 23:06:57+04 $

Почтовый пакет TPmail для Unix систем

Выбор языка

Начало

Документация

Поддержка

Новости

Ресурсы

Контакты

Модуль milter_connect. Описание и работа с ним.

Оглавление

Порядок просмотра различных списков при работе с конвертом сообщения