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