Iliya Peregoudov wrote:
> Maxim Cherniavsky wrote:
>
>>>>
>>>> Т.е приходит подряд два ответа, что на мой вгляд ничему не
>>>> противоречит (rfc 2821)
>>>>
>>>> An SMTP server MUST NOT intentionally close the connection except:
>>>>
>>>> - After receiving a QUIT command and responding with a 221 reply.
>>>>
>>>> - After detecting the need to shut down the SMTP service and
>>>> returning a 421 response code. This response code can be issued
>>>> after the server receives any command or, if necessary,
>>>> asynchronously from command receipt (on the assumption that the
>>>> client will receive it after the next command is issued).
>>>> ключевое слово asynchronously что на самом деле и происходит, и по
>>>> логам CGP мы видим как будто 421 вернулся на RSET, что на самом
>>>> деле не так.
>>>
>>>
>>> Вчитайтесь внимательнее. Это как раз тот самый пример, мягко говоря,
>>> неквалифицировнности - у авторов всяко разных "расширений протоколов".
>>
>>
>> Ну какое расширение то? В 821ой тоже было про 421 вообще на любую
>> команду, в разделе sequence of commands
>>
>
> На стр. 36 [RFC822] написано:
>
> 421 <domain> Service not available, closing transmission channel
> [This may be a reply to any command if the service knows it must shut
> down]
>
> На стр. 37 [RFC822] (SEQUENCING OF COMMANDS AND REPLIES) написано:
>
> The communication between the sender and receiver is intended to be an
> alternating dialogue, controlled by the sender. As such, the sender
> issues a command and the receiver responds with a reply. The sender
> must wait for this response before sending further commands.
>
> Т.е. автор RFC822 понимал (конечно, понимал, на то он и Postel), что у
> любого протокола стоит задача корреляции запроса с ответом. Вот про
> это и комментарий со стр. 37: SMTP -- чёткий диалог, причём сервер в
> нём -- пассивная сторона. И отвечать сервер должен одним ответом на
> один запрос. Если уж так хочется ответить 421, будь добр дождаться
> запроса.
> Но не любого, поскольку на QUIT и TURN отвечать 421 нельзя (согласно
> стр. 38).
Да, в 821 было четко прописано на какую команду какие ответы. Но этого нет в 2821, может я что то и просмотрел
>
> Почему так важна чёткая корреляция запросов с ответами? Пример:
>
> C: MAIL, RCPT, RCPT
> S: 250, 451, 421
>
> Какой из адресов-реципиентов отлупляет сервер своим третьим ответом?
> По привычной логике -- второго, и тут привычная логика совпадает с
> RFC822. По логике RFC2822 -- первого.
Согласен, но результат доставки то все равно один - письмо не прошло,
тем более что второй RCPT вы сказали в закрытый сокет
С помощью 421 сервер не отлупляет адрес ресипиента, он отлупляет текущую
транзакцию, rollback так сказать, а последний 250 queued был
промежуточным commit'ом.
>
> На самом деле, не так уж важно, закрыл сервер сессию молча, или плюнул
> перед этим 421, он её закрыл. Причём не по команде клиента. И клиент
> это должен расценивать однозначно -- сервер не хочет с ним говорить,
> зазорным считает.
Не хочет и считает зазорным в рамках ДАННОЙ сессии.
>
> В вашем случае надо просто добиться того, чтобы SMTP сервер не
> закрывал сессию.
Я не согласен что это надо решать такими методами, почему неправильно открыть новую сессию и пытаться доставить следующее письмо? То письмо на котором пришло 421 (или еще какое нарушение протокола) откладывается с соответствующим delay и все. Основная мысль, которую я высказываю - не надо банить весь сервер, от этого гораздо больше вреда, чем пользы.
>
> Если SMTP сервер закрывает сессию из-за того, что в сессии слишком
> много отлупов, надо найти способ заставить клиент организовывать
> сессии покороче. Есть ли в CGP настройки для ограничения количества
> MAIL/RCPT, выдаваемых в одной сессии?
Я вроде не видел....
>
> Если SMTP сервер закрывает сессию из-за того, что словил 1 письмо с
> вирусом, в топку такой сервер. Если же он делает это только после
> ловли N писем с вирусами в одной сесии -- решение опять же в
> укорочении сессий с этим сервером.
С почтой последние N лет все достаточно печально и среда сильно агресивна, поэтому лучше потратить чуть больше ресурсов, но письмо таки доставить.
--
Best regards,
Maxim Cherniavsky
Comstar-UTS, Internet Division
mailto: maxim (at) comstar.ru
Получено Sat Dec 24 12:33:33 2005
Этот архив был сгенерирован hypermail 2.1.8 : Tue 21 Feb 2006 - 03:17:58 MSK