Всё о о Microsoft Exchange Server и электронной почте.

504 Need to authenticate first

Сегодня получил письмо от коллеги, он продолжает биться с ветряными мельницами в виде сообщений в application log.

Event Type: Error
Event Source: MSExchangeTransport
Event Category: SMTP Protocol
Event ID: 7010
Date: 11/1/2006
Time: 9:03:04 AM
User: N/A
Computer: Server
Description:
This is an SMTP protocol log for virtual server ID 1, connection #22534. The client at «203.153.216.11» sent a «xexch50» command, and the SMTP server responded with «504 Need to authenticate first «. The full command sent was «xexch50 2096 2». This will probably cause the connection to fail.

На самом деле правду говорят, что меньше знаешь — лучше спишь. Если увеличить детализацию любых логов, то видно, что серверы выполняют рад операций, вызывающих ошибки. Но на это не стоит обращать внимания. Это как раз тот случай.

Проблема заключается в том, что получающий сервер Exchange, стоящий в Internet, отвечает на EHLO вот так:

220 mxs2.inserv.kz Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Wed, 1 Nov 2006 12:32:43 +0500
EHLO myserv01.mydomain.ru
250- mxs2.inserv.kz Hello [61.122.296.161]
250-TURN
250-SIZE 5388608
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-TLS
250-STARTTLS
250-X-EXPS GSSAPI NTLM
250-AUTH GSSAPI NTLM
250-X-LINK2STATE
250-XEXCH50
250 OK

Это на самом деле не правильно, т.к. мы видим команды, используемые только Exchange серверами, например: 250-X-LINK2STATE, 250-XEXCH50 и т.д.
Отправляющий Exchange сервер считает, что он соединился с Exchange сервером и пытается работать с принимающим сервером, как с Exchange. Но сервера из разных организаций и соединение между ними анонимное. Поэтому команда XEXCH50 не может использоваться.

К примеру mail.ru отвечает вот как:

220 Mail.Ru ESMTP
EHLO myserv01.mydomain.ru
250-mx21.mail.ru ready to serve
250-SIZE 10485760
250 8BITMIME
250 OK

И этого вполне достаточно для работы в Интернет, но сейчас не об этом.

Итак, рассмотрим лог SMTP и обмен между серверами при подобной ошибке.

Я немного модифицировал стандартный SMTP log. Эта сессия моего сервера Exchange 2003 myserv01.mydomain.ru к внешнему серверу Exchange 2003 в Интернет mxs2.inserv.kz.( Все команды в нормальном логе начинаются с «Outbound»). Эта сессия является анонимной по отношению к получающему серверу.

R: mxs2.inserv.kz +Microsoft+ESMTP+MAIL+Service,+Version:+6.0.3790.1830+ready
C: EHLO — myserv01.mydomain.ru
R: 250- mxs2.inserv.kz +Hello+[61.122.296.161]C:MAIL — FROM:<Pavel.Nagaev@mydomain.ru>+SIZE=32758
R: 250+2.1.0+Pavel.Nagaev@mydomain.ru….Sender+OK
C:RCPT — TO:<mycolleague@inserv.kz>
R:250+2.1.5+mycolleague@inserv.kz
C:XEXCH50 — 2580+2
R:504+Need+to+authenticate+first 0 0 30 0 875 — — — —

[Поскольку при EHLO сервер ответил 250-XEXCH50, мой сервер пытается работать с получающим сервером, как с Exchange сервером. А т.к. сервера не аутентифицированы по отношению друг к другу, то возникает ошибка 504+Need+to+authenticate+first. Что вполне логично. Дальше передача проходит нормально.]

C:BDAT — 32758+LAST
R:250+2.6.0++<A2B538EA6614BC4A86FAC44157707DFA5FE56B@myserv01.mydomain.ru>+Queued+mail+for+delivery 0 0 96 0 1812 — — — —
C:QUIT –
R:221+2.0.0+ mxs2.inserv.kz +Service+closing+transmission+channel

Что же делать c этой ошибкой?

Микрософт предлагает вот что http://support.microsoft.com/kb/843106 . Но это при условии, что оба сервера работают в вашей сети. Если это Интернет сервера, то не стоит делать то, что написано в статье.

Что означает XEXCH5, написано в этой статье http://support.microsoft.com/kb/812455/.

Чтобы такой ошибки не возникало у других пользователей Интернет, закройте XEXCH50 на вашем ISA сервере. Можно сделать еще на вашем SMTP сервере http://support.microsoft.com/kb/257569/en-us, но я не рекомендую, т.к. полезут другие ошибки.

Чтобы подобной ошибки не возникало в ваших логах, нужно на SMTP коннекторе, отсылающим почту в Интернет включить опцию Send HELO instead of EHLO.

И пусть к нам всем придет радость и счастье 🙂

Похожие посты:

  • Pavel Nagaev

    Есть на русском статья http://support.microsoft.com/kb/843106/ru

  • tr0ble

    Большое при большое уважение автору этой статьи. Полезная информация + полезные ссылки. Мне как начинающему разбираться с exchange побольше бы таких статей встречать.

  • unit

    Спасибо, Павел.
    Хочу заметить, что эта ошибка не так безобидна, как Вы говорите. В моём, на пример, случае, вместе с этой ошибой в логах на сервере, пользователи получают NDR типа «Отсутствуют разрешения для отправки сообщений данному получателю». Т.е. почта между доменами не ходит.
    Не понял вот это:
    «закройте XEXCH50 на вашем ISA сервере»
    разве можно фильтровать работу расширений SMTP?
    Если возможно, подскажите, как именно на ISA можно это сделать?

  • http://www.exchangerus.ru Pavel Nagaev

    Да можно, почему нет.

    http://technet.microsoft.com/en-us/library/bb851508(EXCHG.80).aspx

  • unit

    Павел, простите за нубство, но что именно должен делать этот фильтр? (да-да, я помню, что Ваш блог об Exchange, а не об ISA=))  В гайде Шиндера по ISA сказано: «Если команда, посылаемая по SMTP-каналу, не указана в данном списке (спск. команд smtp-фильтра), она отвергается.»  Во встроенной справке ISA: «Если клиент использует команду, которая не распознается фильтром SMTP, данное сообщение не подвергается фильтрации.» Я что-то запутался слегка..
    И там же, далее  «Допускается добавление только простых SMTP-команд«. XEXCH50 таковой не является, как я понимаю.
    По вашей ссылке читаю: «фильтр SMTP <…> необходимо настроить так, чтобы он не объявлял в Интернет расширения, свойственные внутренней сети, такие как X-AnonymousTLS и X-EXPs.» (об XEXCH50 ничего не говорится, но, похоже, это расширение того же вида, иначе зачем бы Вы отпраляли по этой ссылке, верно?). Ок, «необходимо настроить». Ну да, за тем и пришли..
    Встроенная справка ISA: «Фильтром SMTP фильтруются только команды для входящего трафика
    В общем то ли я туплю, и попускаю что-то очевидное, то ли авторам всех этих реккомендаций, справок и гайдов нужно устроить очную ставку.

  • http://www.exchangerus.ru Pavel Nagaev

    «авторам всех этих рекомендаций, справок и гайдов нужно устроить очную ставку.» — золотые слова. Я как-то публиковал Exchange 2007 через ИСУ. Взял инструкцию с  известного сайта и что, думаете заработало? Хрена. Ну да ладно.

    По поводу того, как точно работают фильтры на ИСЕ точно не скажу, т.к. не проверял. Но всегда считал, что команды не указанные в фильтре просто не будут пропускаться исой.  Циска, например, их просто звездами забивает. 

    Хотите — завтра проверю.
    кстати, «Ваш блог об Exchange, а не об ISA»  Почтовый админ должен ису знать, как отче наш.

    Я имел ввиду, что ваш сервер не должен приходящим из Инет серверов, выплевывать ничего лишнего, типа XEXCH50

    А чтобы не было проблем с исходящими, как вариант —
    Send HELO instead of EHLO



  • unit

    Короткое резюме по проблеме:
    1. “Если команда, посылаемая по SMTP-каналу, не указана в данном списке (спск. команд smtp-фильтра), она отвергается.”  — FALSE
    2.“Если клиент использует команду, которая не распознается фильтром SMTP, данное сообщение не подвергается фильтрации.”  — TRUE
    3. “Фильтром SMTP фильтруются только команды для входящего трафика.” — TRUE
    4. Если добавить в smtp фильтр на ISA отсутствующее по дефолту расширение и задизаблить его, то отклоняется вся сессия целиком, при этом почта на удалённом эксче висит в очереди.
    5. Редакция реестра по вот этой реккомендации (подавление отправки XEXCH50 наружу): http://support.microsoft.com/kb/818222  ниикчему не приводит.
    Мой сервак по прежнему отвечает на EHLO спсиком расширений вместе с XEXCH50.
    Так что пока единственным доступным способом отправки почты наружу остаётся отправка HELO instead of EHLO.
    Проблема же недоставки почты из удалённых доменов из-за обсуждаемой проблемы остаётся открытой.
    Отказ от ESMTP не критичен, Вы считаете? 

  • Novichkov Pavel

    Павел, спасибо за статью. Очень доходчиво изложено.
    Однако проблема с 504 Need to authenticate first далеко не безобидна. Особенно когда она возникает при общении двух Exchange в одной организации. Это ведет к срыву репликации Public Folders.
    Т.е. инициирующий репликацию сервер посылает сообщения, но до получателя они не доходят, а если точнее доходят но не принимаются в хранилище Public Folders. Как следствие невозможно поднять новый Exchange на замену первого в организации.
    Может есть какие-то идеи где искать грабли?

    Спасибо.

  • http://www.exchangerus.ru Pavel Nagaev

    Честно говоря не знаю, нужно покопать в этом направлении. У меня тоже такая проблема между двумя серверами есть, но она в моем случае не критична. А в связи с тем, что сейчас идет переход на E2007, то я эту проблему у себя решать не буду. Сорри.

  • Novichkov Pavel

    Павел, спасибо за ответ.
    Если интересно, проблему  решил. Правда, как мне думается, не очень правильным с точки зрения секурности методом.
    На проблемном сервере в ветку HKLM/CurrentControlSet/Services/SMTPSVC/XEXCH50/
    добавил DWORD Exch50AuthCheckEnabled
    значение 0.
    Это значит что он не будет проверять подлинность отправителя команды XEXCH50.
    Думаю для секурности стоит закрыть эту команду на ISA…

  • http://www.exchangerus.ru Pavel Nagaev

    Ну и хорошо 🙂