"Peter J. Holzer" <hjp-asrg@hjp.at> wrote:
>
>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.

Wrong: the client indicates that it wants to use an extension either by
issuing a command defined by the extension or by using the extension's
MAIL or RCPT parameters.

For an LMTP-like extension it would be appropriate to define a MAIL
extension parameter which changes the semantics of the subsequent
DATA command (including variants like BDAT and BURL).

In addition to that I think it would be more tasteful to change LMTP
slightly so that it follows the SMTP one-response-per-command model
more closely. It would also be nice to make per-recipient confirmations
optional if the server configuration doesn't require them (e.g. all
recipients have the same security preferences). That is:

* The SMTP service extension is called "recipient checking after data"

* The EHLO keyword associated with the extension is RECHECK, which has
no parameters.

* There is one new parameter for the MAIL verb, "RECHECK", and the
maximum length of the MAIL command is extended by 8 characters.

* There are no new parameters for the RCPT verb.

* There is one new verb, "RECHECK".

The extension is used as follows:

When the client starts a transaction with MAIL FROM:... RECHECK, the
server MAY respond to some or all of the transaction's RCPT commands
with a "350 Recipient pending" reply. (Other replies to RCPT have the
same semantics as usual.)

If the message data is not accepted by the server (a 4xx or 5xx reply),
the client MUST issue a RSET command. The server SHALL respond to any
pipelined RECHECK commands with a "503 bad sequence of commands" reply.
After the message data has been accepted by the server (a 250 reply),
the transaction is not complete until the client has re-checked all the
pending recipient addresses and then issued a RSET command. The client
MUST issue a RSET command even if there are no pending recipients.

The client re-checks a recipient address by issuing the command
  "RECHECK" SP ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path)
                    [SP Rcpt-parameters] CRLF
The parameters MUST be the same as in an earlier RCPT TO: command. If
they do not match, the server SHALL respond with a "503 Bad sequence of
commands" reply. If the server responded to the earlier RCPT command with
a 2xx, 4xx, or 5xx reply, it SHALL respond to the RECHECK command with the
same reply. If the server responded to the earlier RCPT command with a
350 reply, it SHALL respond with a 2xx, 4xx, or 5xx reply as appropriate.

The client MUST re-check all pending recipients and MAY re-check other
recipients. It MAY issue the RECHECK commands in any order. If the
client does not re-check every pending recipient before resetting the
transaction, the server MUST NOT deliver the message to the unchecked
pending recipients.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
RATTRAY HEAD TO BERWICK ON TWEED: SOUTH 3 OR 4 BECOMING VARIABLE 3 OR LESS.
SHOWERS LATER. MODERATE OR GOOD, OCCASIONALLY POOR LATER. SMOOTH OR SLIGHT.

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg