Наилучший момент для фильтрации содержимого
Стандарты RFC говорят о том, что почтовый сервер должен решить, принять или отвергнуть сообщение, не позднее, чем на этапе команды DATA в диалоге SMTP. К сожалению, такое требование оставляет почтовому серверу мало времени на анализ содержимого сообщения, т. к. в почтовых клиентах реализован достаточно короткий тайм-аут с тем, чтобы не «зависнуть» в общении с неисправным почтовым сервером. Например, тайм-аут для SMTP-клиента Postfix определяется параметром smtp_data_done_timeout, который весьма толерантен и по умолчанию установлен в 600 секунд.
Если почтовый сервер завершает просмотр содержимого до истечения клиентского тайм-аута, все работает отлично, т. к. у сервера есть время на уведомление клиента о своем решении в отношении приема сообщения. Однако если сервер работает слишком медленно, то клиент заканчивает соединение и повторяет попытку позже, при этом шансы на успех при следующей попытке невелики.
Имеющийся в Postfix механизм contentfilter позволяет избежать таких проблем благодаря специальной организации исследования содержимого:
1. Почтовый клиент отправляет содержимое на этапе DATA.
2. Сервер Postfix принимает сообщение и ставит его в очередь. Клиент предполагает, что передача была успешной.
3. Диспетчер очередей анализирует почту и составляет расписание доставки согласно записям content_filter.
4. Postfix передает сообщение внешнему приложению.
5. Внешнее приложение берет на себя доставку сообщения. Оно может выполнить для сообщения одно из следующих действий:
• Принять сообщение и передать его обратно Postfix для доставки.
• Принять сообщение и передать его другому приложению или серверу.
• Удалить или вернуть сообщение.
Второй фильтр (smtpd_proxy_filter) обращается с сообщениями по-другому:
1. Почтовый клиент отправляет содержимое на этапе DATA.
2. Postfix-демон smtpd передает команды SMTP и содержимое сообщения внешнему приложению.
3. Внешнее приложение отправляет SMTP-ответы обратно демону smtpd, а тот передает их почтовому клиенту.
У этого фильтра могут возникнуть проблемы из-за тайм-аутов почтового клиента, кроме того, он не масштабируется для большого количества одновременных соединений с клиентами. Дело в том, что в smtpd_ proxy_filter отсутствует механизм очередей для планирования фильтрации содержимого. А без такого механизма внешнему приложению приходится начинать работу сразу же при получении Postfix каждого нового сообщения. В результате может наблюдаться значительное замедление работы, если внешнее приложение не сможет работать в темпе поступления сообщений. Такая проблема может возникнуть с приложениями, выявляющими спам или проверяющими наличие вирусов, которым часто приходится выполнять требующие больших затрат времени операции распаковки и раскодирования вложений.
Оба подхода имеют свои недостатки:
• content_filter генерирует дополнительный трафик, т. к. Postfix первоначально принимает сообщения перед обработкой. Это может впоследствии привести к необходимости возврата, если фильтрующее приложение решит, что сообщение должно быть отклонено.
• smtpd_proxy_filter сразу же отвергает нежелательное содержимое, но он плохо масштабируется и может оказаться недостаточно производительным.