I'm not a fan of what you proposed with separate keyword just to
check status. I'd much rather have this as separate DATA commands
if done at all. If not done as part of DATA (which I do not see
as being worth the effort), then the way to go is to add an extension
with RCPT parameters, so for example:
250-helo example.com, pleased to meet you
...
250-RCPTSTATUS
250 HELP
MAIL FROM:<user(_at_)example(_dot_)com>
250 <user(_at_)example(_dot_)com> - sender ok
RCPT TO:<you(_at_)example(_dot_)org> STATUS
250 <you(_at_)example(_dot_)org> - recipient ok
RCPT TO:<me(_at_)example(_dot_)org> STATUS
250 <me(_at_)example(_dot_)org> - recipient ok
RCPT TO:<postmaster(_at_)example(_dot_)org>
250 <postmaster(_at_)example(_dot_)org> - recipient ok
DATA
[header and email body goes here]
250-you(_at_)example(_dot_)org ok
350-me(_at_)example(_dot_)org mailbox full try again later *
250 OK
[* I don't remember correct code for this and don't have time to lookup]
The last line is the one for those addresses not specificaly mentioned
before, i.e. those addresses not listed with STATUS at RCTP line.
However as I noted before, I think doing it with new DATA command
which has this new type of status by default like LMTP would provide
more benefits to the userbase to make worth such deployment.
On Tue, 6 Jun 2006, Tony Finch wrote:
"Peter J. Holzer" <hjp-asrg(_at_)hjp(_dot_)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.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg