[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ESMTP Extension Support in Client Mode

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.