Задержка RCPT TO. Сервер не отвечает на RCPT TO. И почта не отправляется из-за таймаута.

На работе столкнулся с траблом. Не могли отправить письма на один почтовый сервер. Там установлен EXIM. Мы их почту получаем, а они нашу не получают.Причем зависимости не было никакой. Иногда доходит, иногда нет и с каждый днем все чаще не доходит.

Начал пробиваться телнетом к их серваку. После команды RCPT TO их сервез отвечал только через 65 секунд. У нас максимальное время ожидания было установлено по умолчанию 30.

Начали копать логи, заметили что после команды RCPT TO сервер виснет и тупит больше минуты. Часто письма просто не отправляются адресатам. Принимаем почту всю а отправить не можем.

Существует в почтовых серверах проверка на существование обратного адреса, чтобы не слали письма с несуществующих адресов. Механизм проверки выглядит так:

Сервер получает письмо от ящика отправителя, и пробует отправить 2 команды MX серверу домена, который шлет нам письмо.

MAIL FROM: <> (здесь он пустой)
220 OK
RCPT TO: <адресотправителя>
220 OK

То есть, это похоже на процедуру доставки письма, только без команды DATA и передачи тела письма. В нашем случае сервер ее не проходит.

telnet mail.domain.ru 25
Trying 165.245.11.21...
Connected to mail.domain.ru.
Escape character is '^]'.
220 mail.domain.ru, ESMTP
EHLO mx1.domain.ru
250- mail.domain.ru Hello 10.67.12.33 [10.67.12.33]
250-SIZE 15728640
250-PIPELINING
250-AUTH PLAIN LOGIN CRAM-MD5
250 HELP
MAIL FROM: <>
250 OK
RCPT TO: <address@domain.ru>

Команда MAIL FROM проходит нормально и ответ приходит практически сразу. И после отправки команды RCPT должен прийти ответ, но ответа нет. Сервер виснет на последней команде, ждет 30 секунд и отключается по таймату не получив ответа, поэтому письмо отклоняется.

Это очень похоже на работу антиспам системы. Это стандартная функция проверки. Дело в том, что когда спамер соединяется с вашим SMTP он таким образом может перебрать пользователей и каждый раз будет получать ответ от SMTP о наличии или отсутствии данного пользователя. Задержка ответа сильно затруднит ему работу. Просто нужно правильно настроить эту опцию. Так же в этот момент может осуществляться обратное соединение, что бы проверить отправителя.

Также стоит проверить списки RBL провайдеров, возможно какие-то из них уже не существуют. RBL провайдеры предоставляют свободный доступ к базе спамеров, чтобы с большой долей вероятности детектировать спам.

В нашем случае проблема была не из-за несуществующего IPBlockListProvider-a. При попытке проверить IP отправителя по всем базам он тупо подписал на одном из них. И почта отклонялась по таймауту.

У их EXIM был установлен слишком большой таймаут. 65 секунд. Поправили конфиг — почта пошла. В следующей статье опишу, что именно правили.