SM wrote:
The existing prose attempts to cover the breadth of SMTP whereas the
abstraction addresses specific scenarios. This discussion has gone
beyond retry clarification.
Only because there is a refusal to acknowledge and old/current 2821
semantic that was corrected in 2821bis. An important consideration in
any attempt to mold or codify a I-D or BCP for Retry Clarification.
It gets more complicated as we take PIPELINING into account.
And that is why it SHOULD be removed from consideration BEFORE attempt
to codify any retry clarification for the basis SMTP specification.
Lets checks out existing software to see how their clients and server
behave in the area of dealing with retries:
In SendMail (8.14.1), first without PIPELINING enabled.
Client side. Starting with the DATA command it issues and getting a
reply code:
C: DATA
if replyType == 4yz -> returns EX_TEMPFAIL
if replyType == 5yz -> returns EX_UNAVAILABLE
if replyType != 3yz -> returns EX_PROTOCOL (error)
Fallback is receiving 3yz, continues with data transfer:
C: <EOT>
if replyType == 452 -> returns EX_TEMPFAIL
if replyType == 4yz -> returns EX_TEMPFAIL
if replyType == 2yz -> returns EX_OK
if replyClass != x5z -> returns EX_PROTOCOL (error)
if replyType == 5yz -> returns EX_UNAVAILABLE
Ok, what does these EX_xxxxxxxx constants mean?
# define EX_OK 0 /* successful termination */
# define EX_UNAVAILABLE 69 /* service unavailable */
# define EX_TEMPFAIL 75 /* temp failure; user is invited to
retry */
# define EX_PROTOCOL 76 /* remote error in protocol */
There is some specifics.
** EX_UNAVAILABLE -- A service is unavailable. This can occur
** if a support program or file does not exist. This
** can also be used as a catchall message when something
** you wanted to do doesn't work, but you don't know
** why.
** EX_TEMPFAIL -- temporary failure, indicating something that
** is not really an error. In sendmail, this means
** that a mailer (e.g.) could not create a connection,
** and the request should be reattempted later.
** EX_PROTOCOL -- the remote system returned something that
** was "not possible" during a protocol exchange.
Ok, so far this is exact for an SMTP state machine. Perfect.
Since we are concern about the EX_UNAVAILABLE error status, lets see
how it applies to to the return codes in a RCPT TO to determine how it
will by default handle retries.
Ok, this is handled it its markfailure function per recipient passing
the EX_xxxxxxxxx code from above.
Right here folks:
switch (rcode)
{
case EX_OK:
break;
case EX_TEMPFAIL:
case EX_IOERR:
case EX_OSERR:
q->q_state = QS_QUEUEUP;
break;
default:
q->q_state = QS_BADADDR;
break;
}
It is clear, it will only requeue (QS_QUEUEUP) for a EX_TEMPFAIL
captured in its send data code. Not for EX_UNAVAILABLE which is for
5yz. In this case, it is marked as a BAD USER (QS_BADUSER).
That is the base SMTP send logic.
Did I need to continue?
There is PIPELINING logic in the code, and I don't think it worth the
effort to go over that, but lets see if there striking changing in
logic.... hmmmm, very complicated to read so I will punt on this for
now. You might think this is important but I don't for the basic SMTP
model simply because PIPELINING is not an expected requirement for
implementors. We specs needs to make sense for the base model first.
The key point, is that here is SendMail, one of he more popular SMTP
systems in the world actually following the specifications for
retries. It marks the address BAD for a DATA <EOT> 5yz response.
I looked at Exim, and it also only retries on 4yz responses. Not 5yz.
Our software is the same and I am sure most are.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com