On Thu, 22 Dec 2005 15:49:42 +0300
"Maxim Cherniavsky" <CGatePro@mx.ru> wrote:
> Vladimir A. Butenko wrote:
>
>> >>> >>> Он вернул 550 и бросил конекшен >> >> >> То есть он даже не упал. Он вернул ошибку и решил, что разговаривать с >> Вами не хочет. Имеет полное право.
Нет. Про "это письмо" он Вам уже ответил 5xx, как Вы сами сказали. Бросить connect - это уже следующая акция. Никак с "плохим письмом" не связанная.
>> соседка - "нет, ну почему ты не хочешь со мной разговаривать сейчас? >> Нет, ну почему я должна через час перезванивать - у меня знаешь >> сколько всего есть тебе рассказать!". >> >> Не хочет. Он. Другой конец. Если для Вас это проблема - то решайте это >> с владельцем того хоста, чтобы он не посылал Ваш сервер далеко, а >> просто возвращал ошибки на конкретные письма, которые ему не нравятся.
>сознательно не хотим, во что верить бы не хотелось)
Предусмотренно. Отрубанием соединения.
> 2. Поэтому делать такие выводы, основываясь на проблеме доставки пары
>сообщений - это Ваша политика и ничего более
Нет. Если хост бросил соединение в момент передачи письма - то это одно дело. Скорее всего либо упал, либо решил (пионэрским образом), что письмо - плохое. В этом случае письмо откладывается. А вот если хост бросил соединение ПОСЛЕ приема (пусть и неудачного) письма, то это именно разговор хоста и Вас. Отношение двух сущностей, без реляций к переписке меж ними :-)
>> Какой пример, какой дамп? Кстати, если дамп - то тем более не стоит >> долбиться. Правда, CGatePro письмо, на котором другой хост упал, >> немножко передвинет в очереди - но это так, в порядке гуманитарной >> помощи владельцам падающих хостов.
А с каких пор это перестало считаться "самоделкой"? Не всяка самоделка - линухоманами сделана, не льстите им. Симантечные "продукты" в областях, в которых они ничего не понимают - ничем не лучше. Вон, опять же пример много раз приводился с Cisco PIX firewall: рутеры всяки они делают еще ничего, а как что-то чуть "повыше", даже примитивный SMTP - то тут и швах и пионэрство.
В том, кстати, и суть CGatePro Plugin - чтобы компаниям, специализирующимся в одном (в анти-вирусах, например), не приходилось лезть в те области, в которых они не сильны.
>давал 550 в процессе приема сообщения (в процессе передачи DATA) и это >воспринимается CGPro как broken. Сегодня глянув документацию к антиспаму >(ftp://ftp.symantec.com/public/english_us_canada/products/sym_mail_security/5.0_mse/manuals/sms_imp_guide.pdf) >у меня есть сомнения что там был разрыв tcp. Как только убрали Reject вся >почта на хост ушла.
Угу. А 550 они радостно шлют СРАЗУ, как только понимают, что это spam? Не дожидаясь "."? То есть - они высылают 550, который никто не читает (SMTP - полудуплексный протокол), а потом таки бросают соединение.
В качестве гуманитарной помощи фирме Симантек можно, конечно, посмотреть на вводные данные после того, как оно бросило соединение. Но тут еще вопрос, как оно их бросило - если при помощи посылки FIN - то всё хорошо, но это не воспримется как бросание соединия, и CGatePro ему довпихнет весь мессаж, а потом считает, что там есть в буфере. А если оно шлёт RSET (чтобы таки уронить канал и престать принимать ненужное письмо) - то никто никогда Вам не прогарантирует, что этот самый 550 дойдёт до CGatePro. Он вообще может с этой машины не уйти. Или из Вашего раутера.
>> Каждое сообщение и так "само по себе". И нормально само по себе >> откладывается - по приему 4xx, например. А вот если проблемы с хостом, >> а не с письмом - как-то падение соединения, неправильные промпты, >> ответы на HELO, отсутствие соединеия - то откладывается вся очередь на >> хост. Это - разные задержки.
Нет, не одной.
>>> 10:46:35.84 2 LIST [12552509] distributed to dron@comstar.ru (1 >>> addresses, 0 removed) as [12552510] >>> 10:46:35.84 2 QUEUE([12552510]) from <kenji@dbzmail.com>, 9663 bytes >>> (<decb01c606cb$1aea61fe$cbb66b85@dbzmail.com>) >>> 10:46:35.84 2 ENQUEUER-01([12552510]) enqueued >>> у хоста в Last Error стоит connection with ... is broken >> >> >> И что? Если сообщение получило 4xx, то оно ИНДИВИДУАЛЬНО отложилось на >> какое-то время. А если после этого хост упал - то отложилась вся очередь.
>доставиться из-за broken на хост. Причин broken ни в логах, ни в monitors >нет и никогда не было, и пытаться понять что там унутре решило >заблокировать хост не представляется возможным.
Из какой "выдержки из логов"? Из этой? Лично мне она ничего не показывает. Если Вам что-то показывает - то поделитесь, пожалуйста, знанием - я правда буду признателен.
Учтите, что очередь к хосту - это очередь к хосту. И если она блямкнулась и почему-то на неё поставили delay, то когда приходит письмо на тот же хост, оно попадает в ту же очередь, и послушно ждёт конца delay. Может, у Вас там какое другое письмо очередь эту остановило? Сканирование логов по имени домена должно Вам помочь найти нужные части логов.
> Та диагностика, которую выдает CGPro, говорит о том что хост broken из-за
>некторого количества 450, что может и не так. Если в логи кто нибудь
>напишет причину broken ВСЕМ станет легче.
Она туда пишется. Называется "connection is broken". Причину его знает только другая сторона, потому что это означает, что на нижнем (TCP) уровне connection упал. На некоторый OS Вы можете увидеть reset - это значит, что оно таки было RSET'ed. На Унихах, насколько я помню, нет нормальной socket-команды на то, чтобы действительно порвать коннект, есть только shutdown/close, так что broken означает скорее всего приход FIN в тот момент, когда хост обязан выдать какой-то ответ.
>> Так что Вы попробуйте, пожалуйста, сначала понять - что у Вас там >> реально происходит (логи Вам в том помощники), потом решите, >> соответствует ли эта реальность Вашим ожиданиям, а если нет - то >> приведите, пожалуйста, подробно, эту реальность, а также Ваше видение >> того, где эта реальность расходится в Вашими ожиданиями поведения >> CGatePro в этой реальности. >>
>большого желания нет и пытаться в очередной раз догадаться почему именно в >этой ситуации возникли broken тоже. Если сможете предложить нормальный >метод дигностики, то с удовольствием займусь.
Мне очень трудно Вам что-то предложить, если Вы и так уже всё знаете. Если же у Вас всё-таки остаются сомнения в том, что происходит на самом деле, то установка SMTP Log Level в Low Info, а потом присылка логов, иллюстрирующих то, что происходит - будет полезна по крайней мере нам.
Нужно отфильтровать логи по имени хоста, а когда таким образом будет найдена сессия, приведшая к проблеме, то лучше привести весь Log для времени этой сессии: то есть не только выдачи SMTP-xxxxx, но и прочие записи, попавшие в лог в этот момент - хотя бы все записи в момент обрыва соединения.
> P.S. Напомнить некую инсталяцию на некотором узле, где приходилось
>реллеить почту на крупные почтовые системы (hotmail, yahoo, mail.ru ) через >отдельные smtp сервера исключая CGPro из-за broken? Может стоит наконец >сделать настроечку в виде галочки?
"Крупные почтовые сервера" (типа hotmail и yahoo) именно потом и бросили заниматься пионерскими глупостями, потому что их клиенты стали жаловаться на проблемы с получением почты. Если под каждый такой "крупный сервер" подстраиваться - то получится не Интернет, а телефон.
> Best regards,
> Maxim Cherniavsky
> Comstar-UTS, Internet Division
> mailto: maxim (at) comstar.ru
>
>
> ##################################################################
> Вы получили это сообщение потому, что подписаны на список рассылки
> <CGatePro@mx.ru>.
>
> Чтобы отписаться, отправьте сообщение на адрес <CGatePro-off@mx.ru>
> Чтобы переключиться в режим дайджеста - mailto:<CGatePro-digest@mx.ru>
> Чтобы переключиться в индексный режим - mailto:<CGatePro-index@mx.ru>
> Для административных запросов адрес <CGatePro-request@mx.ru>
>
>
>
Sincerely,
Vladimir
Получено Thu Dec 22 13:44:55 2005
Этот архив был сгенерирован hypermail 2.1.8 : Tue 21 Feb 2006 - 03:17:54 MSK