Как вы тестируете новую систему фильтрации электронной почты?
Какой метод вы используете для тестирования или оценки потенциальных новых систем фильтрации электронной почты, прежде чем устанавливать его в своей производственной сети?
Я особенно заинтересован в методах, которые подходят для небольших / средних организаций с одним почтовым сервером без ресурсов для создания дубликата их системы электронной почты.
4 ответа
Тестирование продукта для фильтрации электронной почты кажется намного сложнее, чем кажется на первый взгляд. Размышляя об этом, я изложил свои идеи и разбил их на конкретные проблемные области.
Доставка
Первая часть тестирования связана с макетированием доставки электронной почты в систему фильтрации. Потенциально, система фильтрации может принимать во внимание любое из следующего (и, возможно, больше вещей, которые я забыл):
- Конкретные детали протокола SMTP (отправитель сделал HELO, EHLO и что с именем или IP и т. Д.)
- Атрибуты DNS отправляющего домена (разрешает ли он, записи SPF, записи ключей домена)
- Доступность MX отправителя (для проверки обратного пути)
- Исходный IP-адрес сервера, доставляющего сообщение
- Содержание сообщения
- "Мнение", которое сторонние базы данных или "подписи" дают о любом из вышеперечисленных (DNSBL, проприетарные базы данных "репутации" и т. Д.)
Макетирование доставки сообщений фильтрующему инструменту становится менее представительным для реальности, если какой-либо из этих факторов не совпадает с тем, что происходит во время "реальной" доставки. Sending captured incoming email to a filtering rig in a manner that doesn't simulate the source IP address of the sending server, for example, impedes that filtering product's ability to act on that factor (running it by a DNSBL, etc). Likewise, sending delayed messages to a filtering (say you have a "canned" corpus of messages to test with) will give a false impression of behavior because the attributes of the sender's DNS and of any third-party databases or signatures may have changed since the time the message was originally sent (sender altered their SPF records to prevent false positives, a third-party service "blacklisted" the sender, etc).
I'd argue that it's impossible to completely mock-up reality, as it comes to delivery. Getting close going to be fairly difficult if you intend to simulate the sending server's IP address (and I'm not aware of any "off the shelf" solution that does that... and having gotten fairly good results from DNSBLs, I'd be concerned about not simulating the sending server's IP address.) Ultimately, you'll just have to get as close as you can afford.
Место хранения
You've got to stored the filtered email somewhere if you intend to analyze the results. Without storage of some kind there's no good way to actually view the results. Sure, the filtering software generates statistics, but it would certainly improve my comfort-level if I could see the filtered messages.
Some filtering products have a storage capability built-in (like MailMarshal, for example). Other products expect to have an email system to deliver into and don't have any storage capability. To test those products, and so as not to disrupt your production email system, you'll have to create up some kind of secondary email infrastructure to store the test filtering results.
If licensing expense is a concern, you can use free and open source tools to prevent incurring licensing expense. That may present a learning curve for the testing personnel.
More convoluted "groupware"-type email systems may present a challenge in mocking-up because of their dependencies on other services. Exchange Server will require you to mock-up an Active Directory infrastructure to host the mailboxes. Other "groupware"-type email systems (Notes, Groupwise, etc) will have their own associated degrees of difficulty in creating parallel infrastructures.
Анализ
On top of mocking-up delivery and storing the results you also need to have human analysis of the accuracy of filtering (flagging as spam, deleting, filing to a "Junk E-mail" folder, etc). It probably goes w/o saying, but a human needs to verify the results of filtering since the whole point of this exercise is to test the computer's ability to filter results. (I know, that went w/o saying... but I can just hear somebody saying "But wait! We'll write a script to test the accuracy...")
Фильтрационный анализ проблематичен, на мой взгляд, в масштабах. Для любой большой группы конечных пользователей фильтрационный анализ выходит за рамки возможностей отдельного или небольшой группы тестировщиков (или, что более вероятно, они просто "проверят выборочно" и надеются на лучшее). Более того, тестер может иметь другое представление о том, что следует считать "спамом", чем реальный принимающий пользователь (который действительно хочет получать эти глупые рекламные электронные письма от своей компании по прокату автомобилей или "словарное слово дня"). Выявление явно неуспешных сообщений, вероятно, довольно легко (поронографические электронные письма в папке "Входящие", сообщения от известных клиентов в папке "Нежелательная почта" и т. Д.), Но, безусловно, существует вероятность тонкости.
Я не думаю, что существует 100% замена реальности - вам просто нужно приблизиться и надеяться, что ваша тестовая установка достаточно близко отражает реальность, чтобы дать вам точную оценку производительности фильтра.
Наша компания очень хорошо соответствует вашим критериям. Примерно за месяц до тестирования нового спам-фильтра я собирал весь спам, который получала наша система, предлагая пользователям переадресовать его на специальный аккаунт, а не просто удалять. Спам, обнаруженный нашей сторонней службой фильтрации, также был перенаправлен на учетную запись спама. Затем этот спам был повторно отправлен через новый фильтр на временную фиктивную учетную запись, чтобы посмотреть, как он работает. Поскольку все это было отправлено в одной большой партии, это также проверило пропускную способность фильтра.
В результате теста были внесены некоторые коррективы, и тот же спам был также введен в систему обучения. Пользователи по-прежнему присылают мне любой спам, который проходит через них, но со временем их количество уменьшилось до такой степени, что пользователи жалуются, если получают только один или два спама в неделю.
Вы можете проверить, отправив письмо с помощью GTUBE (Общий тест для нежелательной массовой рассылки).
Просто создайте письмо, содержащее это:
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
Это работает нормально со spamassassin, например. Вы можете найти другие GTUBE для конкретных антиспам
Сначала проверьте ретрансляцию, чтобы убедиться, что вы не откроете новый спам-бокс в Интернете. Вы можете сделать это, используя онлайн-инструменты, подобные тем, которые представлены здесь: http://spamlinks.net/prevent-secure-relay-test.htm или некоторые инструменты из платного http://www.dnsstuff.com/.