Добрый день!
Блин!! все анекдоты про прграммистов точные, в какую то фигню упрутся ,
надо это или не надо главно что то долбить , как дятел!1 Хоть
немножко шире мыслить нужно!! Новый год на носу!!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
VAB> После того, как и более чем детально об"яснение г-на Перегудова Вами не было VAB> понято, я слабо надеюсь на успех, но всё же попробую еще раз. VAB> On Sat, 24 Dec 2005 15:33:17 +0300 VAB> "Maxim Cherniavsky" <CGatePro@mx.ru> wrote:
>> Iliya Peregoudov wrote: >>
>> >> Да, в 821 было четко прописано на какую команду какие ответы. Но этого нет >>в 2821, может я что то и просмотрел VAB> Нету. И это проблема г-на Кленсина, который ни малейшего отношения к этимVAB> протоколам не имеет, но решил увековечить своё имя, став Editor (хорошо VAB> хоть, что не author) этого 2821.
VAB> Но сути это не меняет: сути протокола SMTP, которые есть клиент-сервер без
VAB> МАЛЕЙШЕЙ асинхронности. И далее Вам об"ясняют, почему:
>>> Почему так важна чёткая корреляция запросов с ответами? Пример:
>>>
>>> C: MAIL, RCPT, RCPT
>>> S: 250, 451, 421
>>>
>>> Какой из адресов-реципиентов отлупляет сервер своим третьим ответом?
>>> По привычной логике -- второго, и тут привычная логика совпадает с
>>> RFC822. По логике RFC2822 -- первого.
>> >> >> Согласен, но результат доставки то все равно один - письмо не прошло, тем >>более что второй RCPT вы сказали в закрытый сокет VAB> Нет, результат РАЗНЫЙ. VAB> Во-первых "сказали в закрытый сокет" - Вы совсем неправы. Если коннект VAB> закрывался сервером при помощи FIN, то клиент об этом узнает, только почитав VAB> с сокета что-то. Например, когда Вы делаете FTP трансвер на сервер, то VAB> сервер, открыв с Вами data connection, сразу же может выдать close() на своюVAB> часть сокета (shutdown по униксному), и потом - принять от Вам 10GB файл, VAB> зато когда Ваш конец пошлёт FIN, то соединение закроется мгновенно.
VAB> Так вот, выдав второй RCPT To, cервер не только не обнаружит того, что VAB> другой конец "закрыт", он и при чтении этого не обнаружит. Сначала он VAB> обнаружит там 421 - неважно, выдал ли сервер этот ответ сейчас, или послал VAB> его "асинхронно" 5 минут назад: сам протокол сугубо синхронный. И этот 421 VAB> будет считан и интерпретирован как отлуп второго адреса RCPT. VAB> И этот адрес будет, в соответствии, с настройками Вашего сервера, отложен на VAB> какое-то время. А первый адрес - на другое (если Ваш сервер различает 450 и VAB> 421). А потом, выдав СЛЕДУЮЩУЮ команду - RSET, DATA, RCPT TO - сервер увидитVAB> FIN - "connection is broken" - и уже отложит очередь всего хоста. На VAB> какое-то третье время.
VAB> Я надеюсь, теперь Вам стало понятно, почему выдавать ДВА ответа на один VAB> запрос сервера (450 и 421) - это глупость: двух ответов быть не может, VAB> второй ответ будет воспринят как ответ на СЛЕДУЮЩУЮ команду. И этот ответ VAB> будет воспринят совсем по-другому: 4xx в ответ на RCPT TO, MAIL FROM, на VAB> DATA, на ".", и на любую другую команду воспринимается ПО РАЗНОМУ: первое - VAB> откладывает доставку данного письма на данный адрес, второе-четвертое - VAB> откладывает доставку данного письма на все адреса выданные выше, остальное - VAB> сигнализирует о проблеме всего сервера, и, соответственно, откладывает всю VAB> очередь на сервер. VAB> Когда Вы говорите, что по приему 421 на RSET CGatePro должен отложить не VAB> очередь на хост, а "только письмо", то Вы не учитываете того, что "текужего" VAB> письма уже нет. Выдав RSET CGatePro привел сессию в исходное состояние - ни VAB> на одном конце нету никакого письма "в процессе обработки". Более того, VAB> письмо в CGatePro (точнее, "batch" - совокупность письма и набора адресов VAB> внутри данного хоста) - уже "released" и возвернут в очередь хоста как VAB> "незанятый". Далее, если у Вас в этот момент шла параллельная посылка на VAB> этот хост в несколько каналов, то письмо могло быть схвачено другим каналомVAB> и уже доставлено им (обычно так не происходит, потому что batch был всё же VAB> отложен, но если на 4xx Вы откладываете адреса на 0 секунд - то запросто).
VAB> Надеюсь, что теперь мы разобрались с разницей в ответах "отлуп на письмо", VAB> "отлуп на адрес", и "отлуп на разговор".
>> С помощью 421 сервер не отлупляет адрес ресипиента, он отлупляет текущую >>транзакцию, rollback так сказать, а последний 250 queued был промежуточным >>commit'ом.
VAB> Это классно, только не имеет никакого отношения к протоколу SMTP.
VAB> По поводу асинхронности - она таки есть. Но совершенно в другом смысле. Она VAB> означает, что если Вы знаете ЧТО нужно выдать в ответ на следующую команду, VAB> то Вы можете это выдать сразу. Например, Вы, найдя спам в письме на этапе VAB> приема - можете выдать 4xx сразу, не дожидаясь ".". Но если при этом вы VAB> бросите канал (да еще не FIN'ом, а RESET-ом), то не надейтесь, что Ваш 4хх VAB> кто либо получит - получат "connection is broken", и опять же VAB> отложат-отлупят не письмо, а всю очередь на Ваш хост. VAB> Поэтому асинхронность со стороны сервера почти никто не использует: нельзя VAB> предугадать, какую команду выдаст сервер. Единственное, что можно сделать - VAB> это, получив соединение от явного спамера выдать в канал сразу VAB> 5xx а пошёл ты! VAB> 5xx а пошёл ты! VAB> 5xx а пошёл ты! VAB> 5xx а пошёл ты! VAB> 5xx а пошёл ты!
VAB> Но опять же - плавно и культурно закрыть соединение.
VAB> В обратную сторону асинхронность используется чаще. Можно в сервер выдать VAB> сразу кучу RCPT TO:, а потом - разгребать ответы на них. По хорошему, для VAB> того, чтобы так делать, клиент обязан проверить, что сервер выдал PIPELINING VAB> в числе своих свойств (смысл - позволить работать таким дремучим хостам, у VAB> которых TCP не поддерживает flow control - вряд ли таковые есть).
>>> На самом деле, не так уж важно, закрыл сервер сессию молча, или плюнул
>>> перед этим 421, он её закрыл. Причём не по команде клиента. И клиент
>>> это должен расценивать однозначно -- сервер не хочет с ним говорить,
>>> зазорным считает.
>>
>> Не хочет и считает зазорным в рамках ДАННОЙ сессии.
VAB> Да. А что такое "сессия"? И чем она отличается от "другой сессии"? В тот
VAB> момент, когда "активного письма" в ней нет? А даже если есть?
>>> В вашем случае надо просто добиться того, чтобы SMTP сервер не
>>> закрывал сессию.
>> >> Я не согласен что это надо решать такими методами, почему неправильно >>открыть новую сессию и пытаться доставить следующее письмо? VAB> Потому что если у меня нормальный сервер, то он бросит соединение с Вами VAB> тогда, когда он не хочет разговаривать С ВАМИ. А если Вы будете после этогоVAB> непрерывно долбиться, то он (сервер) позвонит в Спортлото и будет требовать VAB> Вашей экстрадиции.
>>То письмо на >>котором пришло 421 (или еще какое нарушение протокола) откладывается с >>соответствующим delay и все. Основная мысль, которую я высказываю - не надо >>банить весь сервер, от этого гораздо больше вреда, чем пользы.
VAB> А Вам тщательно и повторно об"ясняют, что если 4xx пришло "на письмо", то
VAB> отложится само письмо. А если пришло не на письмо, но отложится сервер.
>>>
>>> Если SMTP сервер закрывает сессию из-за того, что в сессии слишком
>>> много отлупов, надо найти способ заставить клиент организовывать
>>> сессии покороче. Есть ли в CGP настройки для ограничения количества
>>> MAIL/RCPT, выдаваемых в одной сессии?
>>
>> Я вроде не видел....
VAB> Вы знаете, если Вы помимо приведения выдержек из Логов, попробуете еще VAB> открывать настройки сервера (об открывании мануала я и не мечтаю уже) - то VAB> сеттинг Recipients/Message наверняка приведет к еще более глубокому VAB> удивлению.
>>> Если SMTP сервер закрывает сессию из-за того, что словил 1 письмо с
>>> вирусом, в топку такой сервер. Если же он делает это только после
>>> ловли N писем с вирусами в одной сесии -- решение опять же в
>>> укорочении сессий с этим сервером.
>> >> С почтой последние N лет все достаточно печально и среда сильно агресивна, >>поэтому лучше потратить чуть больше ресурсов, но письмо таки доставить.
VAB> А оно и будет доставлено. На нормально работающий сервер.
>> -- >> Best regards, >> Maxim Cherniavsky >> Comstar-UTS, Internet Division >> mailto: maxim (at) comstar.ru
VAB> Sincerely,
VAB> Vladimir
VAB> ##################################################################VAB> Вы получили это сообщение потому, что подписаны на список рассылки VAB> <CGatePro@mx.ru>.
VAB> Чтобы отписаться, отправьте сообщение на адрес <CGatePro-off@mx.ru> VAB> Чтобы переключиться в режим дайджеста - VAB> mailto:<CGatePro-digest@mx.ru> VAB> Чтобы переключиться в индексный режим - mailto:<CGatePro-index@mx.ru> VAB> Для административных запросов адрес <CGatePro-request@mx.ru>Получено Sat Dec 24 18:15:55 2005
Этот архив был сгенерирован hypermail 2.1.8 : Tue 21 Feb 2006 - 03:17:58 MSK