Article delegate-en/4881 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
search
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
[Reference:<_A4872@delegate-en.ML_>]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: SMTP AUTH LOGIN
02 Aug 2010 00:17:12 GMT feedback@delegate.org (Yutaka Sato)
The DeleGate Project


Hi,

In message <_A4872@delegate-en.ML_> on 07/14/10(01:20:12)
you =?iso-8859-1?Q?Jes=FAs_DIEGO_FERN=C1NDEZ?= <pu4jabdyi-mlee2cg2alrr.ml@ml.delegate.org> wrote:
 |Thanks to your action with 9.9.7 (AUTH LOGIN) we have been able to deploy Delegate as a gateway between simple smtp clients and SSL+Auth BPOS email server. We just finished the stress tests and the results have been very satisfactory.
 |
 |We only found one problem:
 |- When using SMTP with TLS and AUTH-LOGIN, Delegate sends two consecutive EHLO commands to the server. One after the TLS negotiation (to refresh the EHLO, mandatory by rfc) and one before the login command.
 |- The BPOS smtp server has a protection against "abusive clients": it delays 5 second the answer of the consecutive EHLO commands.
 |- The result was that each email had an extra delay of 5 seconds during the connection.
 |
 |We solved it with a workaround: commenting-out the 3 lines where you preserve/clear/restore the EHLO cache:
...
 |Of course this is only a good workaround if the connection is explicit TLS, which is our case; I am sure that, in other situations, the modification could have an impact (if not, you would not have bothered to preserve the EHLO cache).
 |
 |Please consider in future releases a definitive solution to this problem. For the moment we will stick to version 9.9.7-modified.

Thank you for your problem report.
My intention in the previous modification to do preserve/clear/restore
the EHLO cache in the function "doAUTH_LOGIN_SV()" was to ensure not to
make any impact to the existing code nor to get any effect from the
context of EHLO without inspecting the impact of the modification.

Since the function is used just to judge the availability of the
AUTH LOGIN in the session context only when MYAUTH is specified,
thus reusing EHLO cache in the current context, maybe got after STLS,
indicating the availability of the AUTH LOGIN, will work as expected
without causing impact to usual or existing SMTP session processing.

So I'll modify the code as the enclosed patch in 9.9.8.

Cheers,
Yutaka
--
  9 9   Yutaka Sato <y.sato@delegate.org> http://delegate.org/y.sato/
 ( ~ )  National Institute of Advanced Industrial Science and Technology
_<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
Do the more with the less -- B. Fuller

*** dist/src/delegate9.9.8-pre9/src/smtp.c	Mon May 24 18:11:09 2010
--- ./src/smtp.c	Mon Aug  2 08:46:57 2010
***************
*** 1514,1525 ****
--- 1514,1529 ----
  static int doAUTH_LOGIN_SV(PCStr(myhost),FILE *log,FILE *ts,FILE *fs,PVStr(resp)){
  	const char *cache = EHLO_cache;
  	int doauth = SMTP_doauth;
  	IStr(caps,4*1024);
  	const char *dp;
  
+ 	if( EHLO_cache && strstr(EHLO_cache,"LOGIN") ){
+ 		/* 9.9.8 it should be reused not to repeat EHLO */
+ 		sv1log("#### Reusing EHLO cache\n");
+ 	}else
  	EHLO_cache = 0;
  	SMTP_doauth = 0;
  	HELO_withSV("EHLO",myhost,log,ts,fs,AVStr(caps));
  	EHLO_cache = cache;
  	SMTP_doauth = doauth;
  

  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
@_@V