Ошибка SMTP сессии на Exim
26 Nov 2012 | Автор: dd |День начался радостно, с того, что по каким то причинам перестала доставляться почта от одного из клиентов, а на почтовом сервере Exim, пошли отлупы в виде сообщения “unexpected disconnection while reading SMTP command from smtp.xxxx.xx”
По сложившейся традиции, вражеский админ ушел в несознанку, постановив, что это проблемы на нашей стороне исходя из того, что у них со всем миром все отлично, так что видимо это затыки спамфильтра на нашей. Так что получить от него более полную информацию по логу с его стороны, не получилось, так что пришлось копаться у себя.
Судя по заголовкам писем, возвращавшихся отправителю с ошибками, разрыв сессии случался на стадии smtp-диалога, на моменте отправки команды “RCPT TO:”, то есть явно до начала работы спамфильтра или антивируса, так что стал отталкиваться от того, что разрыв сесси приходится на какие то проверки в процессе установки сессии.
Скажу сразу, надо было больше положиться на логирование и подключение дополнительных опций в логах и плясать от них, нежели от вариантов ошибок. Но я счел, что ошибка довольно тривиальная и полез в инеты с тем, что сессия рвалась между почтарями Exim и Exchange. И действительно одной из основных причин данной ошибки был озвучен сбой в процессе проверки обратного вызова ident, описываемый в основной конфигурации Exim:
rfc1413_hosts = *
rfc1413_query_timeout = 0s
Надо отметить, что данную проверку уже какое то время поругивают, так как она является не безопасной, и большинство современных почтарей её не поддерживают, но у меня никаких проблем её наличие не вызывало. Также есть истории о том, что ident вызов может не проходить на некоторых фаерволах или рутерах (например на глючных прошивках PIX), так что пришлось поковыряться на клиентском шлюзе Sofaware, но и там все было нормально.
Так что пришлось проверку по ident сначала закоментить, а потом и вообще настроить на исключение, увеличив таймаут до 10 секунд, но это не помогло.
Также не помогло и добавление параметра на увеличение таймаута для входяещего SMTP соединения:
smtp_receive_timeout = 10m
Так что пришлось подключать более широкое логирование и плясать уже оттуда. Оказалось, что эту проблему почему то начали вызывать проверки на дохлых RBL, описанные в acl секторе, так как пока почтовый сервер exim ждал отклика от дохлых RBL, почтовый сервер Exchange отваливался по таймауту. Причем, судя по всему, RBL’ы были мертвы уже какое то время, но проблему они стали вызывать только сегодня.
Ошибка SMTP сессии на Exim,Теги: exim, почтовые системы
