[Top] [All Lists]

LMTP-style ESMTP extension (was: [Asrg] pre-rfc thought balloon: ESMTP DATAFIRST)

2006-06-06 11:27:47
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         |
__/   | |    -- Holger Lembke in dan-am

Attachment: pgpA2RY6f36lH.pgp
Description: PGP signature

Asrg mailing list
<Prev in Thread] Current Thread [Next in Thread>