ESMTP Extension Support in Client Mode

["Robert A. Rosenberg" <hal9001@xxxxxxxxx>]

> I know that this is months too late for the Final Call (and the RFC 
> has already been published) but I just found out about it and had 
> some thoughts that I would have raised at Final Call time so here 
> goes anyway (for any good it can do if there is any attempt to 
> revise the RFC).
>
>   ----------------------------------------------------------------------
>
>
> This is a suggested additional paragraph to RFC2645 section 5.4 
> (Other Commands) or for a new section 5.5 (ESMTP Extension Support 
> in Reversed State).
>
> There is no comments in the RFC on the suggested level of support in 
> the ODMR ESMTP MTA Server beyond an ambiguous statement in section 4 
> that the ODMR Server "does not need to a full SMTP Server" [whatever 
> that means]. While this appears to only refer to the lack of need 
> for the scheduling and requeueing functions in the SMTP server, it 
> can also be read to imply that no ESMTP Extension support is needed 
> in the Server code for handling the transfer process once a 
> connection to the user's SMTP Server has occurred. I would like to 
> see something like the following to cover this situation (in either 
> 5.4 or as a new 5.5 - wordsmithing and/or editing of this new text 
> is welcome <g>).
>
> New Text -
>
> Since the intent of ODMR support is to handle a dial-up connection, 
> maximum utilization of the connection's bandwidth should supported 
> if practical. With this caveat the support in the Client Support 
> code in the Server SHOULD include as many of the bandwidth 
> conserving ESMTP Extensions as possible. Example of these extensions 
> include 8BITMIME, PIPELINING and CHUNKING [I forget what other exist 
> in this class - add more as needed <g>]. This will allow the Client 
> to use all such extensions that are offered at EHLO time by the 
> user's SMTP Server when it is contacted in response to the ATRN 
> triggered state reversal.
>
> Thank you.