ietf-smtp
[Top] [All Lists]

Re: another per-recipient data reply proposal

2007-02-14 11:28:07


On 2/12/2007 12:26 AM, Claus Assmann wrote:
So the current protocol suggestion looks like this:

* Client initiates by sending MAIL with an extension.
* RCPT returns normal reply codes (no 3yz)
* DATA and the last BDAT return (in order):
  either: a single {2,4,5}yz reply code to indicate the
      overall transaction status,
  or: 353 to indicate the start of server responses,
      followed by:
     - one reply code per recipient which got a 2yz reply.
     - one end of mail reply code (as in the current ESMTP model,
       which is the same as the "final" reply code in
       draft-hall-deferrals).

Eric: could you update your draft to reflect this status?

Yeah, will do this coming weekend probably. I lost the source document and
was trying to get by with small edits to the text file, but I'll need to
rewrite to accommodate all the changes (minor and major).

(and please change the name so it's more specific, i.e., it should
have "RCPT" somewhere in it's name and hopefully a nice abbreviation,
e.g., DRR, RRAD, ...)

I'll probably name the extension PRDR

On Tue, Feb 06, 2007, Eric A. Hall wrote:

1) the hard time limits

I would increase the time for the first reply after end of mail
data from 1 minute to at least 5 minutes or even 10 minutes (to
match the current (RFC2821) value).

okay

2) duplicate avoidance technology does not seem to have been resolved to
everyone's satisfaction yet

Checkpointing is "out" as it has (security) problems between untrusted
parties. So I think we "just" live with what we have?

I'll word some of it more strongly

I'm not going to introduce any new rules or behaviors over existing SMTP.
The best place to fix those problems is in SMTP generally, and I don't
want to risk coming up with a slightly different set of rules.

Generally speaking though, I think the bis-bis update to SMTP probably
ought to implement something like "final reply ought to have its own
write() if possible" as a way for receivers to detect that client has lost
connection to the server.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/