Sendmail: Timeout waiting for input from mail.domain.ru during message collect

Начало Наверх

Sendmail & Postfix. Сообщения в maillog.

3.16.2. Sendmail. Timeout waiting for input from mail.domain.ru during message collect.

3.16.16.Sendmail. lost input channel from mail.domain.com [2.22.123.221] to MTA after.

3.16.17. Sendmail. timeout writing message to g.mx.mail.yahoo.com.: Broken pipe: 2 Time(s).

3.16.18. Postfix. timed out while sending message body

3.16.2 Sendmail. Timeout waiting for input from mail.domain.ru during message collect.
Вся информация, представленная на этой странице, взята из sendmail-конференции и с сайта www.sendmail.org.

1. Это не ошибка sendmail.
Это сообщение говорит о проблемах в сети, кратковременных или нет. Как правило эта проблема возникает только с одним или некоторыми хостами. Удаленный сайт успешно переслал информацию из SMTP-envelope и приступил к этапу передачи данных DATA, во время чего произошел сбой. Из-за это сбоя истек период DATA timeout, определенный для вашего Sendmail.

Часто такая ситуация возникает при прохождении сообщения слишком большого размера. При этом сообщения размером меньше 1КБ проходят нормально. Тогда можно попробовать посылать сообщения, начиная с "проходящего" размера письма, последовательно увеличивая, и таким образом определив проблемный размер.

Это может быть проблемой MTU, если вы находитесь в сети топологии FDDI-кольцо или PPP-линк или что-то еще, использующей размер пакета,отличный от стандарнтого ethernet'овского.

Это также может произойти, если ваш firewall фильтрует ICMP-пакеты, которыми определяется MTU, либо процесс определения MTU запрещен, и какой-либо промежуточный MTU между конфликтующими сетями имеет слишком большое значение:
"...Is your server on something other than ethernet, e.g. an FDDI ring? If so, probably your network is filtering out ICMP packets by which MTU route discovery takes place. Remote hosts which also have large MTUs would only be able to get small packets to you; thus the timeout when you try to receive SMTP DATA ("during message collect") of sufficiently large messages.

More generally, this would occur when MTU route discovery is suppressed and the sending and receiving hosts support larger MTUs than some link between them. Protocols other than SMTP can be affected as well, e.g. ftp with large files. Fixing things can be easy or hard, based on local experience..."

Что по этому поводу говорят разработчики:
"...
Различные MTU в Сети.
Существует два способа решения проблемы, возникающей при наличии в Интеренете сетей, имеющих различные максимальные значения размера пакета. Первый: пакеты могут быть фрагментированы маршрутизаторами по мере необходимости во время прохождения по маршруту. Это не затруднит посылающий хост, но нагрузит маршрутизатор лишней работой. Второй: посылающий хост может выяснить, какое максимальное значение размера пакета допустимо во всех сетях между двумя хостами, таким образом: он посылает пакет большого рамера и получает обратно сообщение от того промежуточного хоста, который не в состоянии обработать такой большой пакет. Этот процесс, называемый "Path MTU Discovery",- определение(обнаружение) MTU пути(маршрута)- описан в RFC 1191. (На сайте http://sendmail.by.ru/faq/section3.htm#3.10 этот термин переведен как "открытие канала MTU", что, с моей точки зрения, не совсем верно, поскольку discovery в данном контексте применен в значении "обнаружение, исследование, определение параметра" - прим.перевод.), Преимущество этого метода перед другими подробно описано в RFC. Тем не менее любой пакет, посылаемый удаленному хосту, размер которого больше максимального MTU промежуточного хоста в сети, должен быть повторно послан по крайней мере еще один раз. Этих чрезмерных накладных расходов можно избежать, если установить на сетевом интерфейсе более скромное значение MTU.

У процесса "определения MTU пути" есть обратная сторона. Сервера, использующие этот процесс, обычно посылают IP-пакеты с установленным флагом DF (не фрагментировать). Когда маршрутизатор не может доставить пакет следующему пункту назначения, он вовращает сообщение ICMP "Destination Unreachable", что свидетельствует о невозможности обработки пакета. RFC 1191 гласит, что значение MTU для следующего пунтка в сети будет включено в этот возвращенный ICMP-пакет. Таким образом, исходящий сервер будет знать размер пакета, который необходимо установить для повторной посылки, и, таким образом, можно последовательно определить максимальный размер пакета, который может быть послан без фрагментирования. Проблема возникает тогда, когда маршрутизатор между двумя собщающимися хостами тайно (тихо, скрытно) отвергает ICMP-пакеты. В этом случае посылающий хост не знает, что делать. Он никогда не получит ни подтверждения, что пакет доставлен, ни ICMP-пакет "Destination Unreachable", свидетельствующий о проблемах в сети. Проявлением этой проблемы является успешная передача очень маленьких электронных сообщений в то время, как сообщения большего размера (взможно, большего, чем "магические" значения 536 или 1500 байт) не могут быть доставлены.

Эта ситуация не такая уж и редкая. Руководствуясь соображениями безопасности значительное число сайтов находятся за маршрутизаторами или брэндмаурами, пакетные фильтры которых отвергают все ICMP-пакеты. Хотя лекарство может показаться гораздо хуже, чем сама болезнь, и , конечно, я не одобряю этой политики, но это не удивительно, что некотрые сайты выбирают именно это способ. Опасения, связанные с сетевыми атаками, основанными на протоколе ICMP, особенно распределенные атаки на отказ в обслуживании (DDoS), вполне оправданы.
Определение MTU маршрута - относительно малоизученная часть IP-протокола, и большое количество людей, ответственных за политику сетевой безопасности интернет-сайтов, вероятно, никогда не слышало об этом. Поэтому они не понимают, зачем это нужно. Эта политика, возможно, ошибочна, но в настоящее время она понятна.

Если организация имеет проблемы с прохождением почты на другие сайты и причиной этого является процесс "определения MTU маршрута" (наверное, из-за необходимости повторной пересылки больших пакетов после урегулирования вопроса о максимально-допустимом значении MTU на всем маршруте, -прим. первод. ), то, возможно, будет лучше отказаться от этого процесса на серверах, подверженных этой проблеме. (Конечно, если эту проблему вызывает собственная сеть,то лучше разрешить ICMP-пакетам проходить к почтовым серверам). Несмотря на то, что это снимет перегрузку, в то же время усилия, затраченные на фрагментацию пакетов, могут уменьшить(? -прим.первод.) нагрузку на почтовые сервера, и любая выгода будет очень незначительной (потому, что возрастет нагрузка на роутер, который будет заниматься фрагментацией? -прим. перевод), если вообще измеримой.
..."

Дополнительно:
"...The IP standards define fragmentation and Path MTU Discovery to deal exactly with this. So, one or the other of those are prevented from working correctly for some reason, and the true fix is to find out why and remove that reason (a semi-fix is to turn off Path MTU Discovery and rely on fragmentation, if the problem is that Path MTU Discovery is prevented from working due to brokenness beyond your control - see the FAQ)..."
Стандарт IP предусматривает для обработки пакетов большого размера фрагментацию и "определение MTU маршрута". Если какая-либо из этих операций мешает нормальной работе, то следует выявить причину и устранить ее(например, отключить "определение MTU маршрута" и использовать фрагментацию, если "определение MTU маршрута" по независящим от вас причинам мешает нормальной работе).

Процесс "определения MTU маршрута" может быть причиной еще и таких сообщений в maillog: "collect: I/O error on connection" и "reply: read error from host.name". Подробно об этом говорится в п.3.10 в FAQ на http://www.sendmail.org/faq/section3.html#3.10
Перевод первоначальной версии этот параграфа, взятый с сайта http://sendmail.by.ru/faq/section3.htm#3.10 с изменениями (выделены зеленым цветом) c родного сайта www.sendmail.org:
"Если Вы получаете такие сообщения иногда и случайно, они, вероятно, из-за временной сетевой проблемы, или отдаленной аварии хоста или же резкого завершение подключения. Если Вы получаете их много от одного конкретного хоста, имеется, вероятно, некоторая несовместимость между 8.x и тем хостом (см. Q3.12 и Q3.20). Если Вы получаете их много вообще, Вы можете иметь сетевые проблемы, которые заставляют связи сбрасываться.
Заметьте, что эта проблема иногда вызывается несовместимыми значениями MTU (Maximum Transmission Unit) в SLIP или PPP соединении. Убедитесь, что ваш размер MTU сконфигурирован так, что имеет то же самое значение, какое у вашего провайдера сконфигурировано для вашего подключения. Если Вы все еще имеете проблемы, то скажите вашему провайдеру сконфигурировать ваш размер MTU до 1500 (максимальное значение) и сконфигурируйте ваш размер MTU аналогично.
Другая возможность состоит в том, что Вы имеете router/firewall фильтрацию всех входящих ICMP сообщений, в то время как ваша OS выполняет "открытие канала MTU "
(современные реализации TCP/IP стэков делают это по умолчанию) . Открытие канала MTU полагается на некоторые ICMP сообщения, возвращаемые обратно на хост, порождающий трафик - см. RFC 1191 для подробностей или см. наш совет по Path MTU Discovery.

А вот часть сообщения с comp.mail.sendmail о специфической ошибке SCO7.1.0, которая может порождать подобные проблемы:
Subject: Re: Recipient mail server times out sendmail connection
Date: 5 Jun 2002 21:37:02 -0700
From: maillist@screamingplants.com (ike)
Я запустил пакетный сниффер на проблемный почтовый трафик и обнаружил, что tcp checksum больших пакетов была больше 14. Это сетевая ошибка оперционной системы SCO 7.1.0. После наложения нескольких заплаток проблема была устранена"

Еще несколько ссылок по этой теме

На comp.mail.sendmail есть рекомендации по установке значения 576 для MSS на проблемный маршрут:
root add mail.olavolsen.no mss 576 gw 192.168.0.1

2      "...AFAIR an RFC recomends 576 as MTU for default route..."

3      What are the Optimum Windoze values for MTU and MSS?

4    "... Sounds like an mtu path discovery problem I had. Are you by any chance behind a pppoe broadband gateway/router? PPPoE has an 8-byte header, so to fit through mtu 1500 ethernet, its max mtu is 1492. But LAN side of router is default 1500. Normally this smaller hole in the mtu path is negotiated, but something must be blocking it. I fixed it by setting eth0 of my internal smtp server to mtu 1492.
But mtu of your connection may differ. You can test max mtu by pinging something on the internet with do not fragment while varying the packet size. Max -s plus 28 is max mtu. For ethernet -s 1472 + 28 = 1500 mtu. For pppoe -s 1464 + 28 = 1492 mtu:

ping -c1 -s 1464 -M do www.dslreports.com

If that fails, try progressively smaller numbers until it works, then add 28 to get max mtu (or error may show actual mtu). ..."

5    "...It was indeed a problem with the MTU - but not the MTU itself, but the systems using ICMP "Destination Unreachable"-messages to figure out the correct packet size In my case it was the installed KERIO Personal Firewall 2.1.5 dropping those ICMP-messages..."

6    "...If there is an MTU problem, *every* communication that uses large outgoing packets should get a problem as soon as such packets start to be used..."

7    Executive summary: A broken Cisco PIX "smtp firewall" stupidly assumed that the terminating ".CRLF" would be in its own IP packet, and effectively dropped the final packet in the bit-bucket if it had also the last part of the text and the CRLF preceding the dot. Other similar equipment may have similar brokenness...

8    "...MTU related problems may cause "lost with no trace" of big packets from some affected hosts. Usually first big packet is sent during SMTP session when transmission of the message body starts..."

9    Solaris 2.5. There are a couple of patches that deal with broken pipes.

10    It's caused by MTU, the default MTU in eth0 was 1500, after lowering it to 500, everything works beautifully.

11    "...With a simple command /sbin/ifconfig eth0 mtu 1440 the floodgates opened and the mail started arriving. ..."

12    "...change mss for default route to 576 and check if it makes mail go as it should..."

13"...If you get a lot of them in general, you may have network problems that are causing connections to get reset..."

"...This means that as the sendmail server was receiving (collecting) the message the data transfer stopped. This could happen for many reasons, the remote host going down, a network error, stateful firewall issues, etc... ...I suggest that you configure your server with MTU of 1300 instead of the default 150..."

"...Blocking any of them (ICMP Type 3 packets - прим. перевод.) doesn't increase security at all, but only makes life difficult for yourself and for others trying to communicate with you..."

MTU

iptables --insert FORWARD --proto tcp --tcp-flags SYN,RST SYN --jump TCPMSS --set-mss 1200

3.16.16. Sendmail. lost input channel from mail.domain.com [2.22.123.221] to MTA after

1. Claus Assmann: Networking problem or the sender just hang up (telnet?)
2. Claus Assmann:Then you and they should check the network connectivity. If it happens only with a few sites, then it's usually the other side. If it happens with a lot, then it's your side...
3. Per Hedeland: The most common cause of this message by far in today's e-mail world is spamware that simply drops the connection on any error ("User unknown", "Relaying denied", whatever). Try to examine the "lost input channel" cases in more detail - do they appear to concern legitimate mail? You have the sending host in the message above, and if it's "after rcpt" you should also have some 'from=' and 'to=' entries for the message in question (look for lines with the same "queue ID"). If that info indicates that it's legitimate mail, you may have cause for concern, otherwise not. The timing thing could simply be a matter of periodic "spam attacks" - what you need to check is if the "mail delivers normally" is from/for the *same* hosts/users that fails at other points in time. The FAQ lists some cases of networking problems that may cause errors like these (see e.g. Q3.10 and the others it refers to) - but those will typically happen either in the initial handshake or during DATA, not "after rcpt".

3.16.17. Sendmail. timeout writing message to g.mx.mail.yahoo.com.: Broken pipe: 2 Time(s).

http://groups.google.com/group/comp.mail.sendmail/browse_frm/thread/1e1d55a2c4681005#
" ... mostly when there's some puny device or a device with a sysdmin under influence in the TCP field, usually some 40G8 in transparent mode or some netfilter re-setup by nephew *needing* to test his last illuminabominations about post tunnelling your access so he may use your bw to dl some stuff and of course he's b0rken the frame size somehow (maybe trying and get jumbo size?)..."

3.16.18. Postfix. Сообщение в maillog: status=deferred (conversation with mumin.chel.usi.ru[212.57.144.25] timed out while sending message body)

timed out while sending message body (решение: sysctl net.ipv4.tcp_sack=0)

Предыдущая задачка: процесс поиска решения.

На всякий случай, если вдруг эта инфа потеряется на linux.org, перескажу, как автор решал эту проблему.
1. Сначала озадачился MTU, потом уговорил разрешить пинги принимающую сторону, потом напустил на лог tcpdump прожку wireshark, потом ему присоветовали покрутить MSS, а потом пришел гуру Chumka и сказал:
">Правомерно ли посылать "кучу DUP ACK"
После трех DUP ACK - должен наступить режим fast retransmit. НО! В твоем случае это не "куча DUP ACK", а SACKи с одним и тем же ACK-номером, которые советую тебе отключить (net.ipv4.tcp_sack). Wireshark почему-то не показывает sack в логе твоем, поэтому лучше смотреть tcpdump'ом.
Chumka (*) (19.05.2009 10:39:15)