Re: Почему 3 минуты?

От: Sergey Chumakov <CGatePro_at_mx_ru>
Дата: Mon 16 Nov 2009 - 12:28:08 MSK

На Sat, 14 Nov 2009 09:42:03 +0300
"Dmitry Akindinov" <CGatePro@mx.ru> записано:

> Здравствуйте,
>
> Sergey Chumakov wrote:
> > Добрый день.
> >
> > CGP 5.2.16, кусок лога SMTP (это не проверка отправителя):
> >
> > 14:34:03.770 4 SMTP-016665(xxx.com.ua) Connected. DSN SIZE TLS AUTH SOLICIT
> > 14:34:03.770 4 SMTP-016665(xxx.com.ua) [2133954407] sending
> > 14:34:03.770 5 SMTP-016665(xxx.com.ua) out: MAIL FROM:<zzz@zzz.ru> SIZE=2350\r\n
> > 14:37:03.771 3 SMTP-016665(xxx.com.ua) read failed. Error Code=read time-out
> > 14:37:03.771 4 SMTP(xxx.com.ua) [2133954407] batch reenqueued into tail
> > 14:37:03.771 4 SMTP(xxx.com.ua) re-enqueue
> > 14:37:03.771 4 SMTP-016665(xxx.com.ua) closing connection
> > 14:37:03.772 4 SMTP-016665(xxx.com.ua) releasing stream
> >
> > Почему 3 минуты, если по RFC должны ждать 5? Где это можно настроить? Я
> > понимаю, что для проверки отправителя лучше 3, а не 5 (а еще лучше -
> > возможность настройки этого параметра), но для SMTP-то зачем?
>
> Действительно, в коде тайм-аут - 3 минуты. В следующих версиях сделаем пять.
> Но что это изменит? SMTP крайне редко используется в интерактивном
> режиме, чем можно заниматься пять минут после получения MAIL FROM?
Объясняю ситуацию. Два CGP, на одном включена проверка отправителя, тайм-аут которой не настраивается и составляет 3 минуты (если я ничего не путаю). Второй сервер пытается послать письмо с Return-Path, первичный релей почтового домена которого не отвечает. Дальше, я думаю, понятно. :-)

Если это одна настройка (что для SMTP, что для проверки отправителя), то лучше оставить все как есть, чем поставить 5 минут для обоих случаев. В идеале тайм-ауты должны быть разными: для проверки отправителя пусть будет 3 минуты, для сессии SMTP - 5 минут, согласно RFC. А еще лучше, если можно будет эти тайм-ауты менять вручную. Замечу, что настраиваемое (желательно) кеширование позитивных и негативных результатов проверок отправителя помогло бы избежать бОльшей части подобных проблем. И существенно снизило бы нагрузку на сервер, DNS и т.д.

-- 
С уважением, 

Сергей Чумаков,
ведущий инженер сектора транспортной сети.
Группа телекоммуникационных компаний Vega.
т. 0-800-600-0-600
Получено Mon Nov 16 09:28:20 2009

Этот архив был сгенерирован hypermail 2.1.8 : Mon 16 Nov 2009 - 16:16:18 MSK