Re: ESMTP Extension Support in Client Mode

[Randall Gellens <randy@xxxxxxxxxxxx>]

At 1:13 AM -0400 8/23/99, Robert A. Rosenberg wrote:

> 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.

The statement allows different ways of implementing the ODMR server. 
It can be integrated into a full SMTP server, which supports AUTH and 
ATRN in addition to everything else, or it can be a very small 
process that only supports the commands listed, and only processes 
the queues (perhaps built by a separate SMTP process).

The statement says nothing about the duties of the provider-side ODMR 
process acting as an SMTP client.


> 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

It's certainly a good idea for the provider ODMR client process to 
take advantage of 8BITMIME and PIPELINING if the customer ODMR server 
process supports them.  I'm not sure if this belongs in the RFC or 
not, but I'm not opposed to it.