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

От: Kostik <CGatePro_at_mx_ru>
Дата: Wed 06 Oct 2010 - 19:13:48 MSD

Всем привет.

Натолкнулись на странную проблему в 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

<Отвечаем, но отправителя уже нет>

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 успешно принял такое сообщение и доставил его. Но клиент этого не знает и повторяет отправку этого же сообщения.

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

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

=kostik Получено Wed Oct 06 15:14:05 2010