ietf-smtp
[Top] [All Lists]

Re: retry question

2008-08-09 12:10:06



--On Saturday, 09 August, 2008 09:44 -0700
ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:

Okay.  But if there are no recipients under consideration at
all the DATA would be rejected with a 503, or wouldn't it ?

There's no rule that says it has to be. Indeed, RFC 2920 has
this example:

   S: <wait for open connection>
   C: <open connection to server>
   S: 220 innosoft.com SMTP service ready
   C: EHLO dbc.mtview.ca.us
   S: 250-innosoft.com
   S: 250 PIPELINING
   C: MAIL FROM:<mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>
   C: RCPT TO:<nsb(_at_)thumper(_dot_)bellcore(_dot_)com>
   C: RCPT TO:<galvin(_at_)tis(_dot_)com>
   C: DATA
   S: 250 sender <mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us> OK
   S: 550 remote mail to <nsb(_at_)thumper(_dot_)bellore(_dot_)com> not 
allowed
   S: 550 remote mail to <galvin(_at_)tis(_dot_)com> not allowed
   S: 354 enter mail, end with line containing only "."
   C: .
   C: QUIT
   S: 554 no valid recipients
   S: 221 goodbye

This clearly shows a server accepting the data but rejecting
the . because there are no valid recipients.

An added bit of  this story is that I think we believe that, in
a more perfect world, the server would respond to the DATA verb,
not with "354 go ahead and send data" but with "554 no valid
recipients" rather than waiting for data transmission and the
"." and then generating the 554.   But we know that often
doesn't happen, because of long-standing habits and pipelining
issues.   We also know that, even when it does, many clients
simply ignore the response to the DATA verb, treating all such
responses as if they were 354.  The purist model for what the
server might do in that sequence, especially without pipelining,
is pathological and would imply a dialogue like:

   [...]
   S: 550 remote mail to <galvin(_at_)tis(_dot_)com> not allowed
   C: DATA
   S: 554 no valid recipients
   C: first body line
   S: 503 Bad sequence of commands
   C: second body line
   S: 503 Bad sequence of commands
   C: etc
   S: 503 Bad sequence of commands
        [...]
   C: .
   S: 554 no, bozo, I told you there were no valid recipients

In practice, the server gets fed up after too much of this and
resets the connection in self-defense.

I don't disagree with anything Ned said in his note, but want to
reinforce the principle that trying to make too-fine
distinctions in this area won't work in practice and may lead to
even more confusion.

    john