Какой метод вы используете для тестирования или оценки потенциальных новых систем фильтрации электронной почты, прежде чем устанавливать их в производственной сети?
Меня особенно интересуют методы, которые подходят для малых / средних организаций с одним почтовым сервером без ресурсов для создания дубликата их почтовой системы.
Наша компания очень хорошо соответствует вашим критериям. Примерно за месяц до тестирования нового спам-фильтра я собирал весь спам, который получал наша система, прося пользователей пересылать его в специальную учетную запись, а не просто удалять. Спам, обнаруженный нашей сторонней службой фильтрации, также был перенаправлен в учетную запись спама. Затем этот спам повторно отправлялся через новый фильтр во временную фиктивную учетную запись, чтобы посмотреть, как он работает. Поскольку все это было отправлено одной большой партией, это также проверило нагрузочную способность фильтра.
В результате теста были внесены некоторые корректировки, и такой же спам также был загружен в обучающую систему. Пользователи по-прежнему присылают мне любой спам, который проходит, но со временем его количество уменьшилось до точки, когда пользователи жалуются, если получают всего один или два спама в неделю.
Вы можете проверить это, отправив письмо с помощью GTUBE (общий тест для нежелательной массовой рассылки).
Просто создайте письмо, содержащее это:
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
Например, это отлично работает со spamassassin. Вы можете найти другие GTUBE для конкретных антиспамов
Тестирование продукта для фильтрации электронной почты кажется намного сложнее, чем кажется на первый взгляд. Размышляя над этим, я изложил свои идеи и разбил их на конкретные проблемные области.
Первая часть тестирования связана с доставкой макета письма в систему фильтрации. Потенциально система фильтрации может учитывать любое из следующего (и, возможно, многое другое, о чем я забываю):
Имитация доставки сообщений в инструмент фильтрации становится менее репрезентативной, если любой из этих факторов не совпадает с тем, что произошло бы во время «реальной» доставки. Отправка перехваченной входящей электронной почты на установку фильтрации способом, который не имитирует исходный IP-адрес отправляющего сервера, например, препятствует способности продукта фильтрации воздействовать на этот фактор (запускать его с помощью DNSBL и т. Д.). Точно так же отправка отложенных сообщений на фильтрацию (скажем, у вас есть «шаблонный» корпус сообщений для тестирования) создаст ложное впечатление о поведении, потому что атрибуты DNS отправителя и любых сторонних баз данных или подписей могли измениться с тех пор. время первоначальной отправки сообщения (отправитель изменил свои записи SPF, чтобы предотвратить ложные срабатывания, сторонняя служба занесла отправителя в черный список и т. д.).
Я бы сказал, что невозможно полностью смоделировать реальность в том, что касается доставки. Подобраться к нему будет довольно сложно, если вы намереваетесь имитировать IP-адрес отправляющего сервера (и я не знаю ни одного "готового" решения, которое делает это ... и, получив довольно хорошие результаты от DNSBL, я бы быть обеспокоенным не имитация IP-адреса отправляющего сервера.) В конечном итоге вам просто нужно подойти настолько близко, насколько вы можете себе позволить.
Вам нужно где-то сохранить отфильтрованное письмо, если вы собираетесь анализировать результаты. Без какого-либо хранилища нет хорошего способа просмотреть результаты. Конечно, программное обеспечение для фильтрации генерирует статистику, но, несомненно, мне было бы лучше, если бы я мог видеть отфильтрованные сообщения.
Некоторые фильтрующие продукты имеют встроенную возможность хранения (например, MailMarshal). Другие продукты предполагают наличие системы электронной почты для доставки и не имеют возможности хранения. Чтобы протестировать эти продукты и не нарушить работу вашей производственной системы электронной почты, вам придется создать некую вторичную инфраструктуру электронной почты для хранения результатов тестовой фильтрации.
Если расходы на лицензирование вызывают беспокойство, вы можете использовать бесплатные инструменты с открытым исходным кодом, чтобы избежать расходов на лицензирование. Это может потребовать обучения тестирующему персоналу.
Более запутанные системы электронной почты типа «групповое ПО» могут представлять проблему при моделировании из-за их зависимости от других сервисов. Exchange Server потребует от вас создания макета инфраструктуры Active Directory для размещения почтовых ящиков. Другие почтовые системы типа «групповое ПО» (Notes, Groupwise и т. Д.) Будут иметь свои собственные связанные степени сложности при создании параллельных инфраструктур.
Помимо доставки макетов и сохранения результатов, вам также необходимо провести человеческий анализ точности фильтрации (пометка как спам, удаление, отправка в папку «Нежелательная почта» и т. Д.). Это, вероятно, идет без слов, но человеку необходимо проверить результаты фильтрации, поскольку весь смысл этого упражнения - проверить способность компьютера фильтровать результаты. (Я знаю, что это было без слов ... но я просто слышу, как кто-то говорит: «Но подождите! Мы напишем сценарий, чтобы проверить точность ...»)
На мой взгляд, фильтрующий анализ проблематичен прежде всего с точки зрения масштаба. Для любой большой группы конечных пользователей анализ фильтрации будет недоступен для отдельного человека или небольшой группы тестировщиков (или, что более вероятно, они просто «выборочно проверит» и надеются на лучшее). Более того, у тестировщика может быть иное представление о том, что следует считать "спамом", чем у реального принимающего пользователя (который действительно делает хотят получать эти дурацкие рекламные письма от компании по аренде автомобилей или «словарный запас дня»). Идентифицировать явно неудачные сообщения, вероятно, довольно просто (поронографические сообщения электронной почты в папке «Входящие», сообщения от известных клиентов в папке «Нежелательная почта» и т. Д.), Но, безусловно, существует вероятность тонкости.
Я не думаю, что существует 100% замена реальности - вам просто нужно подойти ближе и надеяться, что ваша схема тестирования достаточно точно отражает реальность, чтобы дать вам точную оценку производительности фильтра.
Сначала проверьте ретрансляцию, чтобы убедиться, что вы не откроете новый ящик для спама в Интернете. Вы можете сделать это с помощью онлайн-инструментов, подобных представленным здесь: http://spamlinks.net/prevent-secure-relay-test.htm или некоторые инструменты из несвободных http://www.dnsstuff.com/.