SendMailApp={SMTP[SmtpSend]} -ln 200 -r 1 -helo {Server[HostName]} -o {Dirs[Temp]}\smtpsend-{RANDOM-ID}.log -f {SMTP[Out]}\ {SMTP[Return]}
{SMTP[DNSServer]} по дефолту.
Прописывая IP в DNSServer результата не дает.
Что не так?
Есть в очереди несколько писем в разные почтовые домены. SMTPSEND усердно пытается их отправить. Смотрим лог: ошибка 10061. Ручками в nslookup пробиваем mx записи по этим доменам, все порядке, в DNS запись есть, SMTPSEND тут же начинает отправку без проблем.
Прописывая IP в DNSServer результата не дает.
Что не так?
пробиваю в nslookup MX запись для vkmz.ru тут же письмо уходит
параметр -s пробовал, результат то же
Лог успешной отправки хорошо бы посмотреть.
вот лог неудачи:
Это DNS ваш или провайдерский?
На личном опыте пришёл к выводу, что надо ставить локальный кэширующий DNS, назначив ему десяток надёжных проверенных форвардеров.
Кстати, в последних логах отрезано начало с IP выбранного DNS-сервера. Поскольку вы его всё равно редактируете, то верю на слово, что сервер один и тот же. Подтвердите мою веру.
Версия: SMTPSEND v4.38 for Eserv © 1997-2008 A.Cherezov Etype Co.
Описание проблемы.
Если домен получателя (пример: sandy.ru) не соответствует MAIL EXCHANGER'у (relay1.sandy.ru, relay2.sandy.ru), т.е. "A" и "MX" записи для домена ссылаются на разные адреса, то попытки отправить почту обычно заканчиваются какими-либо из следующих winsock ошибок: 10051, 10060, 11004.
Временное используемое решение.
Для того чтобы "протолкнуть" такую почту, приходится выполнять в nslookup следующие шаги: set type=mx sandy.ru
В результате мы получаем подробный положительный ответ. Почта на этот домен начинает уходить без проблем. DNS информация кешируется провайдерским DNS на указанный ttl в DNS ответе. Однако, временное решение перестает удовлетворять, когда письма на такие домены, достаточно много и часто отправляются. По понятным причинам Администратор не может весь день сидеть и следить за логами.
Исследование ситуации
Как я уже помечал, в самом Eserv я практически начинающий, поэтому исследовал проблему с другой стороны. Все действия и домены реальны.
Итак у нас в очереди письмо на домен @sandy.ru. С помощью анализатора сетевых пакетов CommView я проследил процесс разрешения имени для отправки почты на указанный выше домен. Для этого SMTPSEND предпринял 8 попыток. Я буду указывать только необходимые (по моему мнению) поля запросов/ответов. В качестве DNS серверов используются провайдерские 212.19.149.53 и 212.19.149.54.
1 запрос
Question Section record:0x1
Name: sandy.ru
Type: 0x000F(15) — MX
Class: 0x00FF(255) — *
1 ответ
Result Code:0x02(2) — Server Failure
2 запрос
Question Section record:0x1
Name: sandy.ru
Type: 0x0001(1) — A
Class: 0x00FF(255) — *
2 ответ
Result Code:0x02(2) — Server Failure
Далее 3,4,5 запросы и ответы на них идентичны 1-му.
6 запрос и ответ идентичны первому но послан уже на второй DNS (54)
7 запрос и ответ идентичны первому и посланы на первый DNS (53)
8 запрос
Question Section record:0x1
Name: sandy.ru
Type: 0x0001(1) — A
Class: 0x001(1) — IN
8 ответ
Answer Section record:0x1
Name: sandy.ru
Type: 0x0001(1) — A
Class: 0x001(1) — IN
TTL: 7200 — 2 Hour
IP address: 195.122.226.36
Процесс разрешения имени закончен. Идет попытка отправки почты на 195.122.226.36, в логе ошибка 10060, т.к. указанный хост не является mail exchanger'ом для домена sandy.ru
Далее пытаемся разрешить MX запись через nslookup. Команды:
set type=mx sandy.ru
Логи CommView:
1 запрос
Question Section record:0x1
Name: sandy.ru
Type: 0x000F(15) — MX
Class: 0x001(1) — IN
1 ответ
Answer Section record:0x1
Name: sandy.ru
Type: 0x000F(15) — MX
Class: 0x001(1) — IN
TTL: 7200 — 2 Hour
Preference: 0x000A(10)
Exchange: relay1.sandy.ru
record:0x2
Name: sandy.ru
Type: 0x000F(15) — MX
Class: 0x001(1) — IN
TTL: 7200 — 2 Hour
Preference: 0x0014(20)
Exchange: relay2.sandy.ru
После этой операции SMTPSEND успешно получает ответ на 1 запрос указанный выше, далее он разрешает имя relay1.sandy.ru и начинается отправка почты.
Субъективные выводы
DNS сервер отказался в начале обрабатывать запросы с типом MX и A, поле Class в которых равно "0x00FF(255)" или по другому "*". Читая
255
0x00FF — QCLASS Any [RFC 1035].
Читаем
QCLASS fields appear in the question section of a query. QCLASS values are a superset of CLASS values; every CLASS is a valid QCLASS. In addition to CLASS values, the following QCLASSes are defined:
- 255 any class
Получается на первый взгляд, что с одной стороны запрос с классом 255 валидный, с другой стороны DNS сервер сразу его не принимает. nslookup же для разрешения MX записи использует класс IN (INTERNET), что как показала практика успешно проходит.Только после того как провайдерский DNS закеширует ответ на запрос type=MX, class=IN, он начинает отвечать на запросы типа type=MX, class=*.
Возможно решение данной проблемы SMTPSEND — это сменить либо добавить способ разрешения MX записи так, чтобы запросы шли с классом IN.
PS
Если бы таких случаев было еденицы, то вопрос бы даже не поднимался, но их количество увеличивается, начальство соответственно недовольно, и мы как обычно крайние. Попрошу что-нибудь предпринять для решения данной проблемы.
А фикс, конечно же, будет.
Хорошо, попробуем покрутить класс запроса, вышлю вам тестовую версию сегодня чуть позже. А пока поставьте -sm для отправки через провайдера (того, чей DNS такой привередливый).
(и с другими изменениями, которые были после вашей 4.38 )
В течении дня пользователи с такой проблемой больше не обращались.
Если возникнут проблемы, обязательно напишем, спасибо за быстрое исправление