Re: Проблемы с SMTP протоколом в CGP 5.2.19

Здравствуйте,

On 2010-10-06 19:13, Kostik wrote:
> Всем привет.
>
> Натолкнулись на странную проблему в CGP 5.2.19. Пардон за такое длинное письмо.
>
> Дано: у нас синхронная постановка в очередь (т.е. Enqueue Asynchronously
> выключено). И у нас есть helper, который может зависнуть на несколько
> минут(мы про это знаем, но так бывает). Но потом он просыпается и отвечает
> ОК. У этого хелпера, соответственно, выставлен большой Time-out.
>
> Вот как выглядит такое входящее к CGP SMTP соединение:
> ---
> <Обычное начало SKIP>
>
> 18:08:12.483 5 SMTPI-162105([x.x.x.x]) inp: DATA
> 18:08:12.483 5 SMTPI-162105([x.x.x.x]) out: 354 Enter mail, end with "." on
> a line by itself\r\n
>
> <Вот тут хелпер завис на 3 минуты, но потом ответил ОК>
>
> 18:11:14.460 2 SMTPI-162105([x.x.x.x]) [251638376] received, 412635 bytes
> 18:11:14.460 5 SMTPI-162105([x.x.x.x]) out: 250 251638376 message accepted
> for delivery\r\n
> 18:11:14.460 3 SMTPI-162105([x.x.x.x]) read failed. Error Code=connection
> closed by peer
>
> <Отвечаем, но отправителя уже нет>

Да, и что существенно, узнаём мы об этом, уже послав ответ 250.

> 18:11:14.460 4 SMTPI-162105([x.x.x.x]) closing connection
> 18:11:14.460 4 SMTPI-162105([x.x.x.x]) releasing stream
> ---
>
>
> Проблема: в процессе такого ожидания TCP соединение может закрыться или у
> отправителя произошёл timeout. Т.е. отправитель уже не видит, что ему
> ответили в SMTP диалоге. И следуя RFC-5321:
> ---
> 3.8. Terminating Sessions and Connections
> ...
> SMTP clients that experience a connection close, reset, or other
> communications failure due to circumstances not under their control
> (in violation of the intent of this specification but sometimes
> unavoidable) SHOULD, to maintain the robustness of the mail system,
> treat the mail transaction as if a 451 response had been received and
> act accordingly.
> ---
> Клиентам SMTP, узнавшим о закрытии соединения, сбросе или других
> коммуникационных сбоях вследствие неконтролируемых клиентом событий (в
> нарушение данной спецификации, иногда неизбежное), для обеспечения
> устойчивости почтовой системы следует трактовать почтовую транзакцию, как
> при получении отклика 451 и действовать в соответствии с этим.
> ---
> http://www.rfc-archive.org/getrfc.php?rfc=5321
>
> Т.е. клиент будет повторят отправку этого сообщения. И логично было бы
> предположить, что CGP со своей стороны как сервер, тоже воспримет эту
> ситуацию как 451 и отвергнет это сообщение, в ожидании повтора от клиента.
>
> Но в логах видна такая ситуация:
> ---
> 18:11:14.460 2 QUEUE([251638376]) enqueued
> 18:11:14.460 2 SMTPI-162105([x.x.x.x]) [251638376] received, 412635 bytes
> 18:11:14.460 5 SMTPI-162105([x.x.x.x]) out: 250 251638376 message accepted
> for delivery\r\n
> 18:11:14.973 2 LOCAL-000010(xxx@xxxx.xxx) [251638376] stored on
> [x.x.x.x]:25: 255 364204220 message delivered
> 18:11:14.973 2 DEQUEUER [251638376] LOCAL(xxx@xxxx.xxx) delivered:
> Delivered to the user mailbox
> 18:11:14.973 2 QUEUE([251638376]) deleted
> ----
>
> Т.е. CGP успешно принял такое сообщение и доставил его. Но клиент этого не
> знает и повторяет отправку этого же сообщения.
>
> Такое плохое поведение хелпера - это частный случай.

Как раз это и привело к ситуации, что с TCP соединением ничего не происходило в течение долгого времени. Отправитель полностью закончил передачу сообщения, а сервер не мог ответить, ожидая ответа от зависшего хелпера. Отправитель не дождался и уронил соединение, а сервер об этом узнал только после отправки ответа.

> Но кажется, что в
> случае, если клиент "отключился" после DATA, он не узнает что стало с его
> письмом и повторит отправку. Но CGP это письмо всё же примет и доставит его
> адресату.

Подтверждение факта приёма положительного ответа протоколом не предусмотрено. Сервер получил конверт, тело письма и терминирующую точку на строке, отправил положительный ответ, а в ответ на это узнал, что соединение было прервано. Но до или после приёма ответа - мы не знаем.

> Подскажите, кто не прав и что делать?
>
> =kostik
>

-- 
Best regards,
Dmitry Akindinov -- Stalker Labs.