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

То есть, чтобы грейлистинг работал, все Backup-серверы тоже должны использовать эту технологию. А следовательно, нагрузка на отправителя возрастёт ещё больше, поскольку он будет не только держать сообщение в очереди, но и безнадёжно «ломиться» на несколько хостов, вместо того чтобы «успокоиться» после одной неудачной попытки.

Рассмотренный выше milter-greylist позволяет настроить синхронизацию между различными MX-хостами (см. комментарии к опциям peer и syncaddr в конфигурационном файле, а также man greylist). Благодаря этому все настроенные таким образом почтовые серверы будут использовать общую базу. То есть отправитель, обратившийся на резервный хост после неудачной попытки пробиться на основной, уже будет известен Backup-серверу, и соответственно его обработают успешно.

Правда, опять-таки сработает это лишь в том случае, если повторная попытка будет выполняться не сразу, а спустя некоторое время. Ну и к сожалению, не каждый администратор имеет полный доступ к настройке машин, определённых как Backup-серверы для его домена.

Ещё одна проблема связана с серверами, на которых эксплуатируется «конкурирующая» система борьбы со спамом – так называемый обратный звонок (callback). Суть этого метода заключается в следующем: при получении входящего соединения сервер на стадии RCPT TO приостанавливает сессию и имитирует рабочую сессию с сервером, указанным в команде MAIL FROM. Если эта попытка из-за несуществующего адреса отправителя или по другим причинам завершается неудачей, то и приостановленное соединение разрывается без дальнейшей обработки.

Нетрудно догадаться, что если вы будете использовать грейлистинг, то у вас наверняка возникнут проблемы с отправкой почты на серверы, где настроен callback: в ответ на ваше подключение удалённый сервер попытается установить с вами «встречное» соединение, а вы его отправите «попробовать немного позже». Кому от этого будет хуже – неизвестно.

В нашем «наглядном пособии» – milter-greylist – эта проблема тоже известна, и для её решения предусмотрен ещё один параметр – delayedreject. При его активации milter-greylist будет возвращать ошибку 4xx не после команды RCPT TO, как это предусмотрено по умолчанию, а после получения команды DATA. Это вынуждает удалённый сервер надеяться на успех чуть дольше, но зато не создаёт препятствий для «обратного звонка», который, как правило, завершается после ответа сервера на команду RCPT TO.