Frank Ellermann wrote:
SM wrote:
If we are going to draw scenarios, then we have to
look into the actual retry codes being returned.
Hector proposed an abstraction. If this abstraction
agrees with reality (as in running code and 2821bis)
and is simpler to understand than existing prose with
long examples it is good for a "retry clarification"
draft.
To arrive at a useful abstraction we have to reduce
the numerous scenarios, and for the "retry" business
we can IMHO assume that HELO and MAIL FROM went well.
+1.
First, lets note that we might have arrive at the source of debate
which was the typo in 2821 regarding DATA 5yz responses allowing for
retries (section 4.2.5). This typo was corrected in 2821bis. Only
DATA 4yz allows retries. Not 5yz without some out of scope human
intervention. 2821bis matches the inherent semantics of 821. Only god
can explain why 2821 (DRUMS?) didn't catch this. Obviously it fell
through the cracks because it was clearly incorrect.
I think the chart models what we have today in general for the basic
retry principle. It fits the state machine and semantics of all the
documents (with the exception of the 2821 gaffe in 4.2.5).
It is not a flow chart of all the possible client/server reply codes.
Its a baseline guideline on "How to Decide Retry" based on the RCPT
and DATA Payload transfer responses.
I thought about having 4yz/5yz, I left it at 45z and 55z for
simplicity, but as Ned pointed out, the 2nd digit should probably be
generic. I was thinking along of lines, as you pointed out, where
there an assumption all went well, so we don't have a 421 or other
system related temporary error. Once you do, however, I think then it
attempts to become a more complex flow chart which is still possible
for a document, but I wasn't trying to do that here :-)
There are various cases for RCPT. IMO they all boil
down to three basic values 2xx, 4xx, and 5xx. That
gives us 2^3 = 8 possible mixes, including a case of
no RCPT at all.
Hector's table had only three rows, I think that was
an over-simplification. Three columns for the DATA
results 2xx, 4xx, and 5xx could be also too simple.
But four columns 5xx, 354-2xx, 354-4xx, and 354-5xx
could be a good abstraction. I tried three columns
plus a comment for all "there is no valid recipient"
cases.
Good point:
C: RCPT TO: B
S: 450 try later
C: RCPT TO: C
S: 450 he didn't paid bill
C: RCPT TO: D
S: 550 I just don't like him.
C: DATA
S: 554 - no valid recipients
Note, its possible to have if the RCPT state was not satisfy:
C: DATA
503 bad sequence of commands - do RCPT first!
> Ned pointed out that this is too simple for
PIPELINING.
I am not sure because PIPELINING is not suppose to by-pass the normal
client/server transactions. Its just an command stacking concept for
the most part to optimized and reduced TCP transmissions. But I can
see obviously how errors can occur.
Also PIPELINING is a "add-on" concept. The basic SMTP system is king
here. PIPELINING has to fit into the BASIC framework. If we consider
PIPELINING, then we have to look at all other add-ons as well.
Fundamentally, they all have the fit the basic SMTP state machine.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com