Регистрация...

Eserv Forum / E4 / Mail / Сколько времени будет SMTPсервер пытаться отправить письмо по "неправильному" адресу?

wikipost // (v1)
Продукты и услуги Скачать Документация Купить Поддержка Форумы Партнёрам Статьи О компании
Наш пользователь отправил письмо по несуществующему адресу — неправильное окончание, после @. В журнале пишется
<s:ior>Error: 10060 </s:ior>
Попытки отправить происходят каждые 5 мин в течение суток. Письмо продолжает лежать в \DATA\mail\retry_outbound . Надо что-то делать ручками, или само пройдет? Сам пользователь уже получил письмо о невозможности доставить и исправил адрес на правильный. Так что здесь все в порядке.
 
Комментарии к этой версии (03.11.2010 10:43) [~matveeva] 81b0a526
АвторДатаТекстtags
pig03.11.2010 11:38
Раз письмо уже попало в retry, то стучаться оно будет не раз в пять минут, а на порядок реже, а через несколько дней (где-то в настройках обозначено, может быть, прямо в командной строке агента) вернётся окончательно. Но раз дело в уже исправленной ошибке пользователя, лучше его тогда убить, не дожидаясь.
wikipost
matveeva03.11.2010 11:54
pig пишет: то стучаться оно будет не раз в пять минут, а на порядок реже,
Не, сейчас каждые 5 мин. А вначале, как только отправили, — каждые 3 мин.
pig пишет: где-то в настройках обозначено, может быть, прямо в командной строке агента)
Это вот здесь где-то?
[Delivery] LocalBoxes=1 ForwardSpam=0 SmtpSend="..\acSMTP\smtpsend4.exe -dw -sm {Relay[Host]} -p {Relay[Port]} -ln 200 -r 2 -helo {Server[HostName]} -rd {SMTP[Out]}\127.0.0.1\{SMTP[Port]} -ra {Server[AdminEmail]} -rf {SMTP[Retry]}\" SmtpSendOutbound="..\acSMTP\smtpsend4.exe -dw -ln 200 -r 2 -helo {Server[HostName]} -rd {SMTP[Out]}\127.0.0.1\{SMTP[Port]} -ra {Server[AdminEmail]} -rf {SMTP[RetryOutbound]}\" SmtpSendPush="..\acSMTP\smtpsend4.exe -dw -sm {s} -ln 200 -r 2 -helo {Server[HostName]} -rd {SMTP[Out]}\127.0.0.1\{SMTP[Port]} -ra {Server[AdminEmail]} -rf {SMTP[Retry]}\ -f {s} -u {s} -w {s} -o {Dirs[Temp]}\push-{RANDOM-ID}.xml" SendMailApp="{Delivery[SmtpSend]} -o {Dirs[Temp]}\smtpsend-{RANDOM-ID}.xml -f {SMTP[Out]}\" SendMailAppRetry="{Delivery[SmtpSendOutbound]} -rh 0 -o {Dirs[Temp]}\retry-{RANDOM-ID}.xml -f {SMTP[Retry]}\" SendMailAppReturn="{Delivery[SmtpSend]} -sm localhost -p {SMTP[Port]} -o {Dirs[Temp]}\return-{RANDOM-ID}.xml -f {SMTP[Out]}\127.0.0.1\{SMTP[Port]}\" SendMailAppLocal="{Delivery[SmtpSend]} -sm 127.0.0.1 -p {SMTP[Port]} -o {Dirs[Temp]}\local-{RANDOM-ID}.xml -f {SMTP[Out]}\127.0.0.1\{SMTP[Port]}\" SendMailAppRetryOutbound="smtpsend4.exe -dw -helo {Server[HostName]} -rh 0 -ln 200 -o {Dirs[Temp]}\retryout-{RANDOM-ID}.xml -f {SMTP[RetryOutbound]}\"

pig пишет: лучше его тогда убить, не дожидаясь
Ок, это не сложно. Просто хотела убедиться, что в случае моего отсутствия или "незамечания" такой ситуации, процесс закончится правильно и сам.
wikipost
pig03.11.2010 12:46
Здесь:
SendMailAppRetryOutbound="smtpsend4.exe -dw -helo {Server[HostName]} -rh 0 -ln 200 -o {Dirs[Temp]}\retryout-{RANDOM-ID}.xml -f {SMTP[RetryOutbound]}\"

Только явно длительность не указана, а по умолчанию... суток двое, кажется набегает.
wikipost
matveeva03.11.2010 13:09
pig пишет: суток двое, кажется набегает.
Да, за попытками чужих писем попасть к нам я наблюдала ровно двое суток. Это, видимо, по умолчанию.
Вот это параметр?
-rh hours - move to retry folder, if can't post within 'hours' (default is 4 hr, 0= never move to retry)
А есть еще и
-r - number of days to keep send trying; return if older -ir - immediately return message on any errors -rd - folder for returned mail (default 'mail\spool\')

Может, поставить "-ir "? Это же только для нашей отправляемой почты играет? Не получилось с первого раза, дальше и не надо, сообщить отправителю о неудаче, пусть сам разбирается, что у него не так.
wikipost
pig03.11.2010 15:46
С первого раза не всегда получается. Может сервер оказаться недоступен. Яндексы-Гугли всякие любят при первом обращении мягко так послать: мол, повтори-ка попытку, — спамеров так ненавязчиво отшивают. Так что немедленный возврат — не фонтан.
А вот если письмо лежит в retry и долбится на отправку каждые пять минут — это не есть хорошо, надо смотреть настройки планировщика. Эта очередь должна пинаться раз в несколько часов, она для того и сделана, чтобы снизить нагрузку на сеть.
wikipost
matveeva03.11.2010 16:15
pig пишет: надо смотреть настройки планировщика
А это где? Если в пункте дерева "Планировщик", то у меня там только один работающий пункт — Update
wikipost
ili_a03.11.2010 16:32
В E3 был VerifyDomainsInDns в ini Проверять нелокальные домены, используемые в адресах, на их "реальность" в DNS - возможность их использования в качестве почтовых доменов (существование в DNS MX- или A-записей для этих доменов)
В E4 его в ini нет, но мне казалось что соответствие домена проверяется по умолчанию, по крайней мере у меня так работает, пользователю сообщается об ошибке, письмо никуда не уходит. Или домен в данном случае был перепутан с реальным?
wikipost
pig03.11.2010 16:46
matveeva пишет: Если в пункте дерева

Нет, это не там. Почему-то в конфигурации жёстко пять минут задано (вместо ранее имевших место быть четырёх часов). Остатки отладки? А на обработку основной очереди исходящих период поставлен три минуты. И не настраивается это, зашито прямо в коде.

ili_a пишет: домен в данном случае был перепутан с реальным?

Похоже на то — реальный, но мёртвый.
wikipost
tbmos03.11.2010 21:18
ред: 04.11.2010 08:21
"Почему-то в конфигурации жёстко пять минут задано"

да и лог отправки из-за этого растет ужас как,особенно еще если и рассылки почтовые делать,возможно" пять минут"поправить ?
wikipost
ac07.11.2010 00:37
Причина радикального уменьшения паузы повторов — ошибки greylisting'а в каком-то из почтовых серверов (у получателей). Частые попытки (в течении первых 4х часов) он нормальными повторами не считал (его разработчики вбили себе в голову, что повтор должен быть через 15мин, хотя стандартов на этот счет нет). А при четырехчасовой паузе в очереди повторов он успевал "забыть", что ждет повторных попыток, т.е. считал отправителя новым, и заново запускал его список ожидающих повторов. В итоге почта к ним не уходила никогда. Пришлось опытным путём подбирать, и вот при таких значениях greylisting'и перестали брыкаться.

OK, с тех пор уже достаточно много воды утекло, может они уже исправились Расширим интервал, посмотрим. В след.обновлении этот параметр станет конфигурируемым (через ini, т.е. только для самых настойчивых ).
wikipost
tbmos12.11.2010 14:40
к сожелению не исправился,пускай уж лог растет,чем выслушивать жалобы о не доставке почты(клиентам не объяснишь).
wikipost
ac12.11.2010 15:20
В обновлении http://code.eserv.ru/07.11.2010 интервалы MTA-планировщика сделаны настраиваемыми.
wikipost
tbmos12.11.2010 16:28
это понятно,спасибо. мое сообщение больше скорее для админов,чтобы обратили внимание.
"ошибки greylisting'а" "может они уже исправились"
wikipost
Работает на Eserv/5.05567 (10.02.2020)