ietf-smtp
[Top] [All Lists]

Re: another per-recipient data reply proposal

2007-02-11 22:46:37

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?
(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, ...)

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

[about open problems]

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). Otherwise there is little chance
to get the single {2,4,5}yz reply code as content analysis probably
takes longer in many cases.

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?