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 commands. 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? hp -- _ | Peter J. Holzer | Ich sehe nun ein, dass Computer wenig |_|_) | Sysadmin WSR | geeignet sind, um sich was zu merken. | | | hjp at hjp.at | __/ | http://www.hjp.at/ | -- Holger Lembke in dan-am
Attachment:
pgp6tElandxQ0.pgp
Description: PGP signature
_______________________________________________ Asrg mailing list Asrg at ietf.org https://www1.ietf.org/mailman/listinfo/asrg