Модуль прослушивает различные события сервера SMTP и передаёт их в виде отдельных текстовых строк определённого формата на стандартный ввод программам хелперам. Такие программы могут быть реализованы, например, в виде скриптов выполняемых в операционной системе где запущен сервер Manjary. Программа принимает решение о том какая реакция должна быть на полученное событие и записывает соответствующий ответ в виде текстовой строки определённого формата на стандартный вывод. После этого программа переходит к ожиданию следующего события - чтению строк из стандартного ввода.
События поступающие на стандартный ввод хелпера в общем виде имеют формат:
sessionId EVENT DATA
где: sessionId
- уникальный идентификатор
сессии SMTP, строка из нескольких символов, которая следует после
SMTP.SRV
в лог-файле;
EVENT
- тип события; DATA
-
данные, зависят от типа события.
{sessionId
NEWFlags
}
Начало новой сессии. Flags - список флагов разделённых пробелами:
Клиент является сервером пересылающим сообщения нам (релей).
Клиент является доверенным.
Клиент подключился к порту на котором запрещена аутентификация.
Формат ответа: flag1,flag2,...
или flag1,flag2,...:text
, где
flagN:
Продолжить обычную работу.
Отправить клиенту альтернативное приветствие протокола
SMTP
. Приветствие
должно начинаться с числового кода 220 и пробела.
Закрыть соединение.
Установить для клиента флаг "доверенный".
Установить для клиента флаг "аутентифицированный".
sessionId
DESTROY
Завершение сессии. Соединение закрывается. Единственный
предполагаемый ответ - CONTINUE
.
{sessionId
COMMANDSMTP command
}
От клиента получена команда протокола SMTP
.
Формат ответа: flag1,flag2,...
или flag1,flag2,...:text
, где
flagN:
Продолжить обычную работу.
Заменить команду другой.
Послать клиенту ответ протокола SMTP
, должен начинаться с
трёхзначного числового кода. Рассматривается как выполнение
команды хелпером.
Закрыть соединение.
Установить для клиента флаг "доверенный".
Установить для клиента флаг "аутентифицированный".
{sessionId
AUTHMechanism
} {User
} {Result
}
Выполнена процедура аутентификации. Данные события:
Использовавшийся механизм, строка вида
[SSL/]{PLAIN|LOGIN|CRAM-MD5}. Например: механизм CRAM-MD5 при
нешифрованном соединении:
CRAM-MD5
, простой пароль с
шифрованием соединения:
SSL/PLAIN
Запрошенное имя пользователя.
Результат аутентификации:
Success
The user is
disabled
Error
(общая ошибка
работы механизма аутентификации)
Unsupported mechanism for this
user
(попытка аутентификации с
использованием CRAM-MD5, но пароль пользователя хранится в
виде хэша)
Login failed
Формат ответа: flag1,flag2,...
или flag1,flag2,...:text
, где
flagN:
Продолжить обычную работу.
Установить для клиента флаг "доверенный".
Установить для клиента флаг "аутентифицированный".
{sessionId
MAILFROMe-mail
}
Получена и синтаксически разобрана команда MAIL FROM, сервер готов принять этот адрес.
Формат ответа: flag1,flag2,...
или flag1,flag2,...:text
, где
flagN:
Продолжить обычную работу.
Послать клиенту ответ протокола SMTP
, должен начинаться с
трёхзначного числового кода. Рассматривается как сообщение об
ошибке, команда клиента MAIL не принимается.
Закрыть соединение.
Установить для клиента флаг "доверенный".
Установить для клиента флаг "аутентифицированный".
sessionId
DATA
Начало передачи сообщения.
Формат ответа: flag1,flag2,...
или flag1,flag2,...:text
, где
flagN:
Продолжить обычную работу.
Послать клиенту ответ протокола SMTP
, должен начинаться с
трёхзначного числового кода. Рассматривается как сообщение об
ошибке, команда клиента DATA не принимается.
Закрыть соединение.
Установить для клиента флаг "доверенный".
Установить для клиента флаг "аутентифицированный".
{sessionId
DATAENDfile
}
Сообщение полностью получено. Фильтр может изменить его.
Формат ответа: flag1,flag2,...
или flag1,flag2,...:text
, где
flagN:
Продолжить обычную работу.
Послать клиенту ответ протокола SMTP
, должен начинаться с
трёхзначного числового кода. Рассматривается как сообщение об
ошибке, сообщение электронной почты не принимается.
Закрыть соединение.
Установить для клиента флаг "доверенный".
Установить для клиента флаг "аутентифицированный".
[sessionId
HDRFLDfield: value
]
Получено поле заголовка сообщения, в этом случае оно указано в данных в виде "имя: значение", если данных нет, это означает что получен признак конца заголовка.
Ответ: {CONTINUE|REPLACE|INSAFTER|INSBEFORE}[:Field: value]
Продолжить обычную работу.
Заменить поле на другое. Если это ответ на событие получения конца заголовка - новое поле будет добавлено к заголовку.
Вставить поле в заголовок после полученного. Если это ответ на событие получения конца заголовка - новое поле будет добавлено к заголовку.
Вставить поле в заголовок перед полученным. Если это ответ на событие получения конца заголовка - новое поле будет добавлено к заголовку.
Ниже приводятся события получаемые хелпером от начала сессии
SMTP до конца. Строки событий записываемые на стандартный ввод хелпера
начинаются с E:
, этот префикc не является частью
события и приводится для наглядности. Строки ответов хелпера
записываемые на стандартный вывод начинаются с R:
,
этот префикс не является частью ответа. Подразумевается что уникальный
идентификатор сессии a1b2
. В примере хелпер
заменяет стандартное приветствие протокола и добавляет новое поле
заголовка Priority: urgent
.
Пример 4.1. Работа хелпера с сессией SMTP.
E: a1b2 NEW TRUSTED SSL
R: REPLY:220 bar.com ESMTP Manjary. Hello, we trust you.
E: a1b2 COMMAND EHLO [192.168.1.20]
R: CONTINUE
E: a1b2 COMMAND MAIL FROM:<Smith@bar.com> SIZE=5883
R: CONTINUE
E: a1b2 MAILFROM Smith@bar.com
R: CONTINUE
E: a1b2 COMMAND RCPT TO:<Jones@foo.com>
R: CONTINUE
E: a1b2 COMMAND DATA
R: CONTINUE
E: a1b2 DATA
R: CONTINUE
E: a1b2 HDRFLD Date: Sat, 24 May 2023 20:34:51 +1100
R: CONTINUE
E: a1b2 HDRFLD From: Smith <Smith@bar.com>
R: CONTINUE
E: a1b2 HDRFLD To: Jones <Jones@foo.com>
R: CONTINUE
E: a1b2 HDRFLD Subject: The Next Meeting of the Board
R: CONTINUE
E: a1b2 HDRFLD
R: INSAFTER:Priority: urgent
E: a1b2 COMMAND .
R: CONTINUE
E: a1b2 DATAEND D:\Mail\#queue\V5U1N0.eml
R: CONTINUE
E: a1b2 COMMAND QUIT
R: CONTINUE
E: a1b2 DESTROY
R: CONTINUE
В реальной работе до завершения одной сессии могут приходить события другой (с другим уникальным идентификатором), если это не запрещено конфигурацией.