n  http://www.opennet.ru/openforum/vsluhforumID1/57895.html;

n  http://www.mta.org.ua/sendmail/stuff/www.cs.niu.edu/~rickert/cf/bad-ehlo.html;

n  http://www.mta.org.ua/sendmail/stuff/www.cs.niu.edu/~rickert/cf/hack/block_bad_helo.m4;

n  http://www.vttoth.com/heloehlo.htm.

Наконец, можно (целиком положившись на разработчиков Sendmail) добавить в mc-файл опцию FEATURE(`block_bad_helo'). Любопытных отсылаю к файлу cf/m4/proto.m4, начиная со строки «ifdef(`_BLOCK_BAD_HELO_', `dnl», где можно посмотреть, какие именно правила будут применяться.

Однако, на мой взгляд, проверку по HELO лучше использовать исключительно в комплексных системах типа Spamassassin как один из критериев «спамности». Но эта тема уже далеко выходит за рамки статьи.

Стандарт есть стандарт

Согласно RFC822 и RFC1123 каждый почтовый сервер должен безоговорочно принимать почту на адрес postmaster@<domain.tld>. RFC2142 добавляет к этому списку также адрес abuse@<domain.tld>. Это обусловлено тем, что у отправителя всегда должна быть возможность сообщить вам о проблеме. В нашем примере это требование стандарта не выполняется, т.к. в случае «неправильного» имени хоста наш сервер сразу разорвёт соединение, не спросив даже имени отправителя (MAIL FROM), не говоря уже о том, чтобы узнать, кому тот хотел написать письмо (RCPT TO).

Как было показано, проверки check_relay выполняются до проверок check_mail и check_rcpt. Однако этот порядок можно изменить. Для этого в mc-файл нужно добавить следующую директиву:

FEATURE(`delay_checks', `friend')

Это, во-первых, отложит проверки check_relay и check_mail до того момента, пока не пройдёт check_rcpt. Во-вторых, аргумент «friend», переданный директиве, позволяет задать в базе access правило SPAMFRIEND для нужных адресов:

To:postmaster@   SPAMFRIEND

To:abuse@        SPAMFRIEND

Пересобрав базу access (командой make в каталоге /etc/mail), вы обеспечите безоговорочное прохождение сообщений на указанные адреса, и лишь после этого будут выполняться наши проверки check_relay. Кстати, в лог-файл информация о блокировках отныне будет заноситься с пометкой «ruleset=check_rcpt», поскольку теперь наборов правил check_relay и check_mail в sendmail.cf нет – вместо них при использовании вышеуказанной директивы появляются «нестандартные» checkrelay и checkmail соответственно, которые вызываются из check_rcpt. Побочным эффектом этого будет то, что в daily-сообщениях везде будет фигурировать ваш домен: