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

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

Но и это не все! Кроме того, понадобится соответствующая настройка клиентских компьютеров. Если все письма после контентной фильтрации будут смешаны в одной папке «Входящие сообщения», тогда оператору придется самостоятельно принимать решение о чтении или игнорировании каждого сообщения на основании рекомендации фильтра. Значит, или почтовый клиент на компьютере получателя должен поддерживать сортировку по некоторому ключевому признаку на спам и рациональную почту, или такая сортировка должна производиться на стороне почтового сервера, а клиентская программа должна использовать протоколы для удаленной работы с сообщениями, хранящимися на стороне сервера, например IMAP. Хотя в тексте используется союз «или», но на практике сортировка на стороне клиента не имеет смысла, так как серверные компоненты системы контентной фильтрации лишаются простой возможности получения от пользователя подтверждения или опровержения правильности применяемых политик исходя из перемещений опротестованных сообщений по почтовым папкам. Например, если некоторое нежелательное сообщение спам-фильтром пропущено, то будучи помещенным в специально выделенную папку, оно сканируется повторно, и его дайджест включается в поисковую базу. И наоборот, изъятое из папки со спамом деловое сообщение сканируется, и адрес его отправителя помещается в «белый список». Конечно, подобный функционал можно решить за счет внутренних пересылок (форвардов) на служебные адреса, но такое действие будет удачным лишь в случае корректной пересылки самим почтовым клиентом. И все равно таким путем не решается главный вопрос – статистический анализ спама после его нахождения в клиентском карантине после изъятия ошибочных сообщений и размещения в нем пропущенных и прочее.