On 2006-06-05 20:59:47 -0400, Mark E. Mallett wrote:
The LMTP-style solution adds value without taking any away, whereas a
mere rearrangement of commands does take functionality away.
I agree that an LMTP-style solution has merit. There are however, some
details of LMTP which make it (IMHO) unsuitable for deployment on the
internet (in fact, RFC 2033 warns of this, too).
1) It requires a different greeting from the client (LHLO instead of
EHLO). A client cannot detect an LMTP server from the response to
EHLO. This doesn't fit into the ESMTP extension model.
2) It changes the meaning of DATA and BDAT. In the ESMTP extension model
there is no way for the client to tell the server which extension it
supports, so the server cannot change the meaning of standard
Therefore I propose an ESMTP extension which does the following:
The server announces that it supports the extension with a keyword in
the reply to EHLO. I propose MULTI-RCPT-DATA.
The client may then use the command MDAT instead of DATA. MDAT behaves
the same as DATA in LMTP.
Open to question:
* Is it worthwhile to specify an analog of BDAT? BDAT doesn't seem to
be widely implemented.
* While we are specifying a replacement for DATA: Would it be
worthwhile to split the DATA into header and body?
_ | Peter J. Holzer | Ich sehe nun ein, dass Computer wenig
|_|_) | Sysadmin WSR | geeignet sind, um sich was zu merken.
| | | hjp(_at_)hjp(_dot_)at |
__/ | http://www.hjp.at/ | -- Holger Lembke in dan-am
Description: PGP signature
Asrg mailing list