At 12:15 AM 8/11/2008, Hector Santos wrote:
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.
The people who have commented on 2821bis are the same people who have
been posting on this thread. If there were any such change in
semantics in 2821bis, they would have pointed it out.
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).
I can show you a case where a DSN will be generated for all
recipients if one of them fails and another case where you only get a
DSN for the non-successful recipients. The first case was a LDA
quirk and it is obviously incorrect. The point is not to look at a
part of the code only and draw a conclusion based on it. I only
mentioned DSN here as I was describing a case I came across.
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 suggest that you do an actual test and see the results.
Regards,
-sm