Я запускаю Ubuntu 10.04 с Sendmail на виртуальной машине VMWare. В моем файле mail.log есть тысячи ошибок, связанных с отказом в подключении, и я бы хотел от них избавиться. Каждую секунду происходит несколько ошибок, и я убежден, что из-за этой проблемы некоторые из наших законных писем не отправляются.
Пример:
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6C3K6e0008595: to=root, ctladdr=smmsp (115/126), delay=1+08:59:56, xdelay=00:00:00, mailer=relay, pri=8940371, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6C3K19D008593: to=smmsp, delay=1+08:59:58, xdelay=00:00:00, mailer=relay, pri=8941647, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6D2K2lX023270: to=postmaster, delay=09:59:56, xdelay=00:00:00, mailer=relay, pri=9331939, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6C7e3Cp010618: to=postmaster, delay=1+04:39:47, xdelay=00:00:00, mailer=relay, pri=9754324, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6BNe474006871: to=root, ctladdr=smmsp (115/126), delay=1+12:39:58, xdelay=00:00:00, mailer=relay, pri=9930371, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6CMK1lb021417: to=root, delay=13:59:57, xdelay=00:00:00, mailer=relay, pri=10410356, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6BLK2Bk005641: to=postmaster, delay=1+14:59:56, xdelay=00:00:00, mailer=relay, pri=10571717, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6BK01i9004244: to=postmaster, delay=1+16:20:00, xdelay=00:00:00, mailer=relay, pri=10926911, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]`
Я читал, где потенциальная проблема заключается в том, что sendmail не прослушивает порт 25, поэтому я выполнил эту команду
# sudo netstat -a -n -p |grep 0.0.0.0:25
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 1137/sendmail: MTA:`
Я также попытался изменить строки:
DAEMON_OPTIONS('Name=MTA, Addr=127.0.0.1, Port=smtp')dnl`
DAEMON_OPTIONS('Name=MSP, Addr=127.0.0.1, Port=submission')dnl`
в моем sendmail.mc и перестроил конфигурацию sendmail, но я вообще не смог отправить электронное письмо, когда это сделал.
Я также прилагаю копию моего файла hosts, так как я не уверен на 100%, что он правильный.
127.0.0.1 example.org localhost localhost.localdomain mail.example.org.localdomain`
10.1.1.204 example.org mail.example.org mail.example.ci.oh.us mail-server`
Наш почтовый сервер mail.example.org обрабатывает всю пересылаемую почту с нашего веб-сервера example.org. Эта часть меня всегда смущает, но она была настроена таким образом, когда я взял на себя управление этими серверами.
Спасибо за любую помощь и дайте мне знать, если вам нужно, чтобы я опубликовал что-нибудь еще. Я сделаю все возможное, чтобы исправить эти ошибки.
Вы искали журналы sendmail для rejecting connections ...?
Sendmail может отказываться принимать входящие соединения, если средняя загрузка системы слишком высока.
Проверить номер сообщения в «очереди клиента» (mailq -Ac) - в некоторых случаях причиной таких проблем было огромное количество спам-сообщений в очереди клиента, например из-за размещенных / взломанных "дружественных к спаму" веб-страниц.
Как читать HUGE clientmqueue в человеческом формате?
Вы можете увеличить «отказаться от средней нагрузки» с 12 по умолчанию, используя следующую строку в вашем файле sendmail.mc:
define(`confREFUSE_LA',`20')
"Настройка производительности Sendmail" Ник Кристенсон (стр. 139) говорится о настройке между 12 и 20 на выделенном сервере, отличном от Linux, и даже выше на выделенном сервере Linux. [Linux рассчитывает среднюю нагрузку по-другому]
В Sendmail-8.14.0 появилась возможность установить его как параметр DaemonPortOptions. Вы можете использовать его, чтобы установить разные DRAWLA для loopback (127.0.0.1), внутренних и общедоступных IP-адресов.
Похоже, что сообщения откладываются, поэтому может быть, что у вас есть некоторые сообщения в очереди, которые повторяются снова и снова. Взгляните на свою очередь (mailq), чтобы узнать, может ли это быть так.
Вы можете просматривать отдельные сообщения в своей очереди: перейдите в каталог очереди, и у вас будет два файла для каждого электронного письма, один из которых начинается с df *, а другой с qf *. Вместе они составляют все сообщение (одно содержит информацию о деталях очереди, другое - содержимое электронной почты ... да, намеренно упрощенное объяснение :-)). Если вы посмотрите на детали и решите, что хотите удалить сообщение из очереди, вы можете просто удалить оба файла с тем же идентификатором очереди. В качестве альтернативы вы можете переместить все файлы в другой каталог, который удалит их из очереди, где вы можете просмотреть на досуге и вернуть все, что вы действительно хотите попробовать, и повторно отправить (я никогда не сталкивался с проблемой идентификатора очереди, выполняя итак .. но, естественно, вы попадаете в середину обычного процесса sendmail, делая это).
Если они законны и их необходимо повторить, возможно, вам потребуется настроить параметры повторных попыток в конфигурации sendmail, чтобы они выполнялись реже (как частота, так и общее время повторных попыток до отказа и создания отчета о недоставке). Я оставлю это упражнение по просмотру этих настроек вам (его легко найти в самой конфигурации или с помощью базового поиска в Интернете).
Определение того, что это за сообщения, - это, конечно, первый шаг, чтобы вы могли увидеть, не заполняет ли что-то вашу очередь, или просто пытается отправить плохое письмо и т. Д.
Что касается ретрансляции веб-сервера через почтовый сервер, это не редкость. Обычно наличие только одной точки выхода для почты упрощает управление такими вещами, как ваши записи SPF и т.д. конечно оправдано.
Наконец, единственный способ, которым я обычно представляю, что эти попытки / соединения влияют на законную электронную почту, - это если вы имеете дело с очередью, которая достаточно велика, чтобы законные электронные письма оставались в ожидании повторных попыток. Обычно это не так, так как новое электронное письмо будет сначала проверено в очереди ... однако, если оно будет отложено по нормальной законной причине, ему придется пройти через обычную повторную попытку очереди.
Дополнение: при просмотре записи в журнале выдается идентификатор очереди. Так, например, если запись «s6C3K6e0008595» все еще находится в вашей очереди, у вас будут файлы qfs6C3K6e0008595 и dfs6C3K6e0008595, которые вы можете изучить.