Я заметил, что несколько писем имеют значительную задержку (до 12 дней) после того, как они были отложены: «Отложено: в соединении отказано»
Вот пример:
Nov 4 09:29:52 server0004 sendmail[4789]: sA49TLmW004726: to=<** Recipient Deleted **>, delay=00:00:31, xdelay=00:00:00, mailer=esmtp, pri=1806434, relay=mx01.inthehive.net. [109.68.0.70], dsn=4.0.0, stat=Deferred: Connection refused by mx01.inthehive.net.
Nov 16 12:11:44 server0004 sendmail[32326]: sA49TLmW004726: to=<** recipient Deleted ** >, **delay=12+02:42:23**, xdelay=00:00:01, mailer=esmtp, pri=1896434, relay=mx01.inthehive.net. [109.68.0.70], dsn=2.0.0, stat=Sent (B546894210001 Message accepted for delivery)
/ etc / sysconfig / sendmail содержит:
DAEMON=yes
QUEUE=1h
Из того, что я прочитал, опция QUEUE настраивает sendmail на повторную попытку отправки сообщений в mailq каждый час.
Других сообщений в файле журнала для этого сообщения нет. Я изо всех сил пытаюсь понять, почему это ждало так долго, прежде чем повторить попытку.
Мы используем Centos 6.5, sendmail-8.14.4-8.el6.x86_64 (это действительно старая версия, в настоящее время мы тестируем последнюю версию с нашим приложением)
Любые указатели приветствуются
РЕДАКТИРОВАТЬ: я должен упомянуть, что большинство отложенных писем, похоже, отправляются своевременно, мы отправляем ~ 160 000 писем в неделю с этого сервера.
РЕДАКТИРОВАТЬ: Есть другие записи сообщения aS49TLmW004726 в журналах sendmail между первой попыткой и окончательной доставкой:
Nov 4 09:29:57 server0004 sendmail[4789]: sA49TLmW004726: to=<** Address Removed **>, delay=00:00:36, xdelay=00:00:05, mailer=esmtp, pri=1806434, relay=mx3.mail.icloud.com. [17.158.8.50], dsn=2.0.0, stat=Sent (Ok, envelope id 0NEI00IHCCZ30H20@nk11p00mm-smtpin005.mac.com)
Nov 4 09:30:00 server0004 sendmail[4789]: sA49TLmW004726: to=<** Address Removed **>, delay=00:00:39, xdelay=00:00:03, mailer=esmtp, pri=1806434, relay=mailin1.rmx.de. [217.111.120.6], dsn=2.0.0, stat=Sent (Ok: queued as 04CFC180964)
Nov 4 09:30:02 server0004 sendmail[4789]: sA49TLmW004726: to=<** Address Removed **k>, delay=00:00:41, xdelay=00:00:02, mailer=esmtp, pri=1806434, relay=mx.paulandsam.co.u...a.hostedemail.com. [216.40.42.4], dsn=2.0.0, stat=Sent (Ok Queued as wish11_2c048f6822d39)
Nov 4 09:30:06 server0004 sendmail[4789]: sA49TLmW004726: to=<** Address Removed **>,<** Address Removed **>,<** Address Removed **>,<** Address Removed **>, delay=00:00:45, xdelay=00:00:04, mailer=esmtp, pri=1806434, relay=mx-eu.mail.am0.yahoodns.net. [188.125.69.79], dsn=2.0.0, stat=Sent (ok dirdel 4/0)
Nov 4 09:30:06 server0004 sendmail[4789]: sA49TLmW004726: to=<** Address Removed **>,<** Address Removed **>, delay=00:00:45, xdelay=00:00:00, mailer=esmtp, pri=1806434, relay=mx-c1.talktalk.net. [62.24.202.3], dsn=2.0.0, stat=Sent (ok: Message 702806395 accepted)
Nov 4 09:30:07 server0004 sendmail[4789]: sA49TLmW004726: to=<** Address Removed **>, delay=00:00:46, xdelay=00:00:01, mailer=esmtp, pri=1806434, relay=mxgb1.opaltelecom.net. [62.24.139.61], dsn=2.0.0, stat=Sent (ok: Message 664665974 accepted)
Nov 4 09:30:09 server0004 sendmail[4789]: sA49TLmW004726: to=<** Address Removed **>, delay=00:00:48, xdelay=00:00:01, mailer=esmtp, pri=1806434, relay=mailserver.ukdpi.co.uk. [213.171.216.114], dsn=2.0.0, stat=Sent (Ok: queued as 9ABDFD60281)
Nov 4 09:30:11 server0004 sendmail[4789]: sA49TLmW004726: to=<** Address Removed **>, delay=00:00:50, xdelay=00:00:02, mailer=esmtp, pri=1806434, relay=aspmx.l.google.com. [74.125.195.26], dsn=2.0.0, stat=Sent (OK 1415093312 t19si273668wiv.66 - gsmtp)
Nov 4 09:30:11 server0004 sendmail[4789]: sA49TLmW004726: to=<** Address Removed **>,<** Address Removed **>, delay=00:00:50, xdelay=00:00:00, mailer=esmtp, pri=1806434, relay=mx01.inthehive.net., dsn=4.0.0, stat=Deferred: Connection refused by mx01.inthehive.net.
Nov 4 09:30:13 server0004 sendmail[4789]: sA49TLmW004726: to=<** Address Removed **>,<** Address Removed **>,<** Address Removed **>, delay=00:00:52, xdelay=00:00:02, mailer=esmtp, pri=1806434, relay=mx-eu.mail.am0.yahoodns.net. [188.125.69.79], dsn=2.0.0, stat=Sent (ok dirdel 3/0)
Мы отправляем ~ 15 сообщений в неделю на номер 109.68.0.70
В вашем вопросе сказано, что вы "пытаясь понять, почему это так долго ждали, прежде чем повторить попытку", но мне кажется, что эти журналы являются окончательными: ваш почтовый сервер не ждет 12 дней перед повторной попыткой отправки. Он повторяет его довольно часто (хотя без всех журналов я не могу сказать, как часто), но удаленный сервер постоянно недоступен. Поэтому на ваш вопрос невозможно ответить, поскольку он основан на ложных предикатах.
Мне тоже интересно Зачем удаленный сервер не принимал ваши звонки, но если предположить, что у вас не было полного отказа интернет-соединения - что кажется маловероятным - у нас нет возможности узнать. Это могут быть закрылки, но это вне вашего контроля; возможно, удаленному серверу не нравится получать от вас так много писем, поэтому он отказывается отвечать в периоды занятости, но это также находится вне вашего контроля; возможно, их сервер просто перегружен (sendmail, например, отказывается от соединений при высокой загрузке системы), но опять же, это вне вашего контроля.
Вы можете попытаться связаться напрямую с администратором этого сервера, чтобы задать ему вопрос; но кроме этого вы мало что можете сделать - конечно, похоже, что с вашим сервером нет ничего плохого.
Недавно у меня была аналогичная проблема с одним из доменов, для которых мы ретранслируем. В очереди для этого домена было одно сообщение, из-за которого их шлюз завис и не принял сообщение. Это прибыло, когда их шлюз был недоступен для обслуживания (поэтому мы создали для них очередь сообщений, прежде чем они вернутся в эксплуатацию).
При последующих запусках очереди сообщение duff было проверено, истекло время ожидания и другие сообщения, поставленные в очередь для этого домена, отображались как повторные без фактической попытки (показано с xdelay = 00: 00: 00). После того, как домен вернулся в эксплуатацию, новые сообщения доставлялись немедленно, но старые сообщения, оставшиеся позади, на самом деле не подвергались повторным попыткам и в конечном итоге были возвращены.
Чтобы решить эту проблему, мы добавили несколько регулярных запусков очередей с различным порядком ...
# Puppet Name: queuerun-modtime
10 * * * * /usr/lib/sendmail -q -OQueueSortOrder=modtime
# Puppet Name: queuerun-random
40 * * * * /usr/lib/sendmail -q -OQueueSortOrder=random