none
Отправка почты "в наруж" RRS feed

  • Общие обсуждения

  • Проблема в следующем:
    При отправке почты в некоторые домены приходит сообщение о невозможности доставки по следующей причине:
    Ошибка связи с сервером электронной почты получателя по протоколу SMTP. Обратитесь к системному администратору.
                <MX.xyz.ru #5.5.0 smtp;573 user.name@xyz.com.ru unknown user account>
    C чем такое может быть связано и как с этим бороться...

    6 марта 2007 г. 13:35

Все ответы

  • <MX.xyz.ru #5.5.0 smtp;573 user.name@xyz.com.ru unknown user account>

    Наверное вы не правильно указываете адрес получателя, <
    unknown user account> говорит только об этом.

    6 марта 2007 г. 13:50
  • Неее... Адрес user.name@xyz.com.ru -- адрес отправителя. Локальный домен и почтовый -- разные. Причём такие NDRы приходя  только при отправке писем в несколько "избранных" доменов...
    6 марта 2007 г. 14:33
  • А пользователь user.name@xyz.com.ru, точно имеет возможность получать корреспонденцию извне?

    Можно провести эксперимент. На сайте http://tests.nettools.ru/  , в поле E_Mail Valid: введите user.name@xyz.com.ru.

     

    6 марта 2007 г. 14:57
  • Вы не могли бы подробнее пояснить это:

     Kazemeir написано:
    Адрес user.name@xyz.com.ru -- адрес отправителя. Локальный домен и почтовый -- разные.

    6 марта 2007 г. 19:19
  • Очень похоже на срабатывание системы защиты (RBL, antispam) на целевом сервере.
    7 марта 2007 г. 3:39
    Модератор
  • sie, когда отрабатывает RBL, то обычно до проверки пользователя не доходит, отшибает на уровне соединения и в ответ идет ссылка на сайт, где отправитель может свой IP проверить.

    antispam конечно возможен, но это плохая практика. Подмена причин ошибок.

    #5.5.0 smtp;573 user.name@xyz.com.ru unknown user account

    Я думаю, что проблема действительно в ошибочном имени пользователя. Ибо сервер почту для этого домена принимает, а вот имени пользователя такого нет.

    Поэтому правильно написал Well-wisher, нужно использовать внешние сайты, типа nettools.ru для выяснения существования пользователя. Главное, что это будет посторонняя система.

     Пришлите мне адрес,  я Вам скажу, рабочий он или нет.

     

    7 марта 2007 г. 5:15
    Модератор
  • Всем большое спасибо! =)
    Однако проблема так и остаётся не решённой... Адрес рабочий, т.к. почта от/к нему ходит, а подобные NDRы приходят только при отправке писем на адреса в двух доменах. Да и nettools.ru сообщил что он рабочий.

    7 марта 2007 г. 7:07
  • Насколько я понимаю @xyz.com.ru - домен отправителя. И сервер получателя в ответ на mail from говорит user unknown. Может быть сервер почему то считает себя ответственным за домен @xyz.com.ru ?
    7 марта 2007 г. 7:22
  • Хмммм.... На сколько я понял вы имели ввиду что сервер получателя считет себя ответственным за домен @xyz.com.ru ?
    7 марта 2007 г. 7:29
  • Вы можете показать log такого smtp сеанса? Да и заголовки самого письма посмотреть было-бы неплохо. Потому как информации не хватает, пока  зацепиться не за что
    7 марта 2007 г. 7:38
  • смоделируйте передачу в telnet сессии

    у вас FQDN = MX записи ? ваш сервер напрямую шлет письма  минуя смарт хост(ы)  ?

    7 марта 2007 г. 12:23
  •  Pavel Nagaev написано:

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

    antispam конечно возможен, но это плохая практика. Подмена причин ошибок.

    все конечно хорошо , если только на том конце провода не сидят параноики и проверяют не только соотвествие домена , но и посылают обратный запрос на проверку существующего п\я с данным адресом (VRFY) -)

    7 марта 2007 г. 12:26
  •  Well-wisher написано:
    Вы можете показать log такого smtp сеанса? Да и заголовки самого письма посмотреть было-бы неплохо. Потому как информации не хватает, пока  зацепиться не за что

    Дополная список информации, для полноценного анализа нужны (можно "замаскараденные"):

    1. Кусок SMTP лога от Connecting до Disconnecting.

    2. Адреса отправителя и получателя.

    3. FQDN сервера отправителя, A/PTR/MX записи домена отправителя.

    Хотя наиболее вероятным выглядит именно проверка адреса отправителя сервером получателя = админ-параноик, как упомянул Sergey Krylov.

    8 марта 2007 г. 12:37
  •  BorisSl написано:
     

    Хотя наиболее вероятным выглядит именно проверка адреса отправителя сервером получателя = админ-параноик, как упомянул Sergey Krylov.

    Однако автор говорит что почтовый адрес отправителя рабочий, то есть почта на него приходит

    8 марта 2007 г. 21:34
  •  Pavel Dugaev написано:

     BorisSl написано:
     

    Хотя наиболее вероятным выглядит именно проверка адреса отправителя сервером получателя = админ-параноик, как упомянул Sergey Krylov.

    Однако автор говорит что почтовый адрес отправителя рабочий, то есть почта на него приходит

    рабочий то  он рабочий - только VRFY команда отключена ( если такова проверка делается принимающей стороной)

    9 марта 2007 г. 12:56
  •  Sergey Krylov написано:
     Pavel Dugaev написано:

     BorisSl написано:
     

    Хотя наиболее вероятным выглядит именно проверка адреса отправителя сервером получателя = админ-параноик, как упомянул Sergey Krylov.

    Однако автор говорит что почтовый адрес отправителя рабочий, то есть почта на него приходит

    рабочий то  он рабочий - только VRFY команда отключена ( если такова проверка делается принимающей стороной)

    VRFY может еще рубиться на firewall, на PIX, например, это конфигурация по умолчанию.

    Все-таки, во избежания гадания на кофейной гуще лучше бы увидеть кусок SMTP лога от connecting до disconnecting. Сразу будет ясно кто, кого и чего спрашивает, и что получает в ответ...

    Уважаемый Kazimeir,

    SMTP лог включается в свойствах Virtual SMTP server. Если Вы сможете записать и прислать сюда кусок этого лога для конкретной сессии, причина ошибок будет видна сразу.

    12 марта 2007 г. 17:34
  • Если имеет место быть проблема с VRFY, тогда Firewall или ещё что,  уже не важно. Как  сказал Sergey Krylov - "...VRFY команда отключена..."

    XIMS: VRFY Command Does Not Work in Exchange 2000 or in Exchange 2003  http://support.microsoft.com/kb/289521

    Похоже автор потерял интерес к теме, или решил проблему и молчит, как партизан :).

    12 марта 2007 г. 20:13