SMTP-шлюз представляет собой обычный SMTP-сервер, реализация SMTP-протокола в нем самая минимальная. Служба включается в мастере конфигурирования программы, он привязывается ко всем IP-адресам всех внешних интерфейсов. Иначе, если внешних сетей в программе не назначено, эта служба будет недоступна. Доступ на TCP-порт SMTP-сервера шлюза во внешнем сетевом экране откроется автоматически.
Для фильтрации сообщений имеется набор правил самого SMTP-шлюза, а также могут подключаться различные модули расширения (плагины). Обработка сообщения правилами производится не только после приема сообщения целиком, но также по каждому событию, связанному с определенными стадиями приема сообщения в рамках SMTP-протокола. Это позволяет настроить процедуру фильтрации таким образом, чтобы сообщения можно было отфильтровать как можно раньше, экономя при этом трафик.
При каждом событии для анализа доступны только те атрибуты сообщений, которые уже имеются (приняты):
• | IP-адрес и DNS-имя хоста отправителя. |
• | E-mail адрес отправителя. |
• | E-mail адрес получателя. |
• | Тема сообщения. |
• | Внутренние заголовки сообщения. |
• | IP-адреса в заголовках. Можно использовать для анализа трассировки пути доставки сообщений. |
В правилах могут проверяться только эти атрибуты, используется синтаксис регулярных выражений. Анализ всего сообщения целиком доступен только в модулях расширений.
Предусмотрены следующие события, по которым производятся действия обработки сообщений:
• | Connect: событие в момент попытки установления соединения с SMTP-сервером. Доступны только атрибуты IP-адреса и имени хоста. По этому событию можно сразу отсечь попытку соединения с определенных хостов ("черные списки") или наоборот - разрешить прием любой почты ("белые списки"). |
• | HELO: по приему соответствующей SMTP-команды (HELO или EHLO). |
• | MailFrom: прием адреса отправителя. По данному событию можно произвести анализ этого адреса в правилах. Также имеется функция анализа валидности почтового домена адреса отправителя на предмет наличия DNS MX-записи. |
• | RcptTo: прием адреса получателя. По событию можно произвести анализ этого адреса в правилах. Если получателей несколько, то это событие вызывается по каждому адресу получателя отдельно. На данной стадии SMTP-шлюз также производит поиск клиента программы по его e-mail адресам параметром авторизации, и, если прием почты для этого получателя запрещен, SMTP-клиенту возвращается ответ с ошибкой. SMTP-сессия может и не закрываться, SMTP-клиент в силе продолжить отправку сообщения для другого получателя. |
• | Headers: произведен прием заголовков сообщения, доступны атрибуты заголовков. Тема сообщения находится в заголовках, поэтому также доступна для анализа. Доступен и список IP-адресов заголовков. |
• | Complete: принято все сообщение. Доступны все атрибуты. По этому событию также производится антивирусная проверка сообщения. |
Операцию фильтрации сообщения по данным заголовков можно производить по событию их приема. Но следует иметь в виду, что SMTP-клиент на этой стадии отправки сообщения, скорее всего, анализировать код возврата не будет, и прекращение приема данных тела сообщения воспримет как ошибку связи, а через некоторое время предпримет попытку повторной отправки. Поэтому такую фильтрацию лучше всего делать по приему сообщения целиком (событие Complete).
В SMTP-шлюзе имеется механизм добавления (отнимания) так называемого весового коэффициента сообщения, что позволяет реализовать его обработку по совокупности разных признаков. Если в самом конце приема и анализа сообщения этот вес превысит определенный заданный порог, то сообщение может быть отфильтровано.
Кроме такого радикально действия - фильтрации (блокировки) ,- может быть сделана пометка сообщения в теме или его заголовках. Эти признаки в дальнейшем могут использоваться для фильтрации сообщений в почтовом сервере организации или непосредственно в клиентской почтовой программе. Пометку в теме использует и клиентская почтовая программа для распределения принятых сообщений в разных папках. Помечаться сообщение может при превышении его веса заданным порогом, а также отдельными правилами.
Для анализа работы SMTP-шлюза, отладки правил и поиска потерянных сообщений ведутся логи в нескольких журналах:
• | Журнал трассировки: может быть отдельно включена трассировка SMTP-протокола и применений правил. Используется для отладки. |
• | Журнал блокировок сообщений: сюда заносятся все факты блокировок и их причины. Используется для поиска потерянной почты. |
• | Журнал антивирусной проверки: общий для всех служб программы, применяющих антивирусную проверку трафика - HTTP-прокси и SMTP-шлюз. |
Тарификация почты и анализ адресов получателей
Есть два режима работы с получателями - прием только для известных адресатов или прием для любых получателей из заданного списка доменов. Таким образом, произвести отправку сообщения через SMTP-шлюз на произвольные адреса принципиально невозможно - функция пересылки (relay) всегда ограничена допустимыми рамками.
В первом случае все e-mail адреса получателей должны быть прописаны у клиентов программы, и весь входящий почтовый трафик будет тарифицироваться. Во втором случае стоит дополнительно прописать все почтовые домены организации, и тарифицироваться будет только та почта, получатели которой прописаны в программе. Второй вариант можно рекомендовать на начальном этапе внедрения SMTP-шлюза, когда еще не все e-mail адреса прописаны в программе.
Использование первого варианта в большой организации позволяет сильно экономить трафик. Опыт применения шлюза показывает, что, как правило, имеется очень большой почтовый трафик на несуществующих получателей: почтовые подписки уволенных сотрудников, рассылки по случайно сгенерированным адресам домена и т.д.
Если у сообщения несколько получателей, то трафик за сообщение может быть засчитан всем полностью или разделен на них поровну. Для этого имеется соответствующая настройка.
Плюс существует несколько настроек, позволяющих разрешить или запретить прием почты для клиентов, отключенных по разным критериям.
Текущая страница справки: http://help.smart-soft.ru/doc20/index.html?howworksmtpgate.htm