Как показывает практика, значительную долю нежелательной почты действительно удаётся отсечь с помощью грейлистинга (см. врезку «Немного статистики»). При этом почтовый трафик может ощутимо снизиться, поскольку в отличие от различных статистических и сигнатурных анализаторов предварительный приём спамерского сообщения не осуществляется.

В то же время грейлистинг практически полностью исключает ложные срабатывания, когда добропорядочное письмо блокируется фильтром и не попадает к адресату. Исключение может составить разве что случай, когда почтовый сервер отправителя по тем или иным причинам не вполне следует установленным стандартам. Но это, как говорится, не наши проблемы.

Также отмечу сравнительную нетребовательность к ресурсам вашего сервера. Конечно, всё не так просто, как в случае «чёрных» списков на основе DNS, но по сравнению с тем же SpamAssassin грейлистинг может считаться очень простым и незатратным методом, поскольку требует анализа только конверта сообщения и ведения несложной базы, в которой будут фиксироваться состояния «триплетов» (IP-адрес, почтовый адрес отправителя, почтовый адрес получателя) – занесён ли этот триплет в «белый» список, была ли в недалёком прошлом попытка доставить такое же сообщение и т. д.

Ну и ещё можно отметить «юридическую» чистоту этого метода. Если блокирование почты на основании DNSBL может вступить в противоречие с обязательством провайдера обеспечивать надёжную и бесперебойную работу обслуживаемой сети, а различные анализаторы при известной сноровке можно рассматривать как покушение на конституционное право пользователей на тайну их личной жизни (особенно если копии сообщений, признанных спамом, доставляются администратору или помещаются в общедоступный карантин), то грейлистинг не нарушает ни того ни другого, работая строго в соответствии с техническими требованиями. Поскольку любой сервер может при тех или иных обстоятельствах вернуть временную ошибку, то ничего криминального в этом нет.

Минусы грейлистинга

С другой стороны, грейлистинг при всей своей идеальности обладает и рядом отрицательных моментов. Прежде всего эта технология относится к «невежливым», поскольку вынуждает сервер отправителя тратить свои ресурсы на дополнительное обслуживание искусственно создаваемой очереди. Только представьте себе, что произойдет с сервером типа mail.ru, если каждое исходящее сообщение он будет вынужден ставить в очередь и отсылать повторно?

Далее отправитель, получив временную ошибку, скорее всего попытается отправить сообщение на резервный сервер для вашего домена. Если Backup-сервер (т.е. хост с менее приоритетной MX-записью) у вас есть и он не включён в ваш «белый» список, то львиная доля нагрузки по обслуживанию очереди будет переложена на его плечи (в смысле на дисковую подсистему). И кстати говоря, ваш Backup-сервер наверняка будет скрупулёзно придерживаться протокола, так что любой спамер, додумавшийся использовать резервную MX-запись, может быть уверен, что его сообщение будет доставлено.