----- Original Message -----
From: <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Monday, May 09, 2005 9:57 AM
Subject: RFC3463, 450 reply codes, and 4.7.1 extended codes.
----- Original Message -----
From: <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Monday, May 09, 2005 9:57 AM
Subject: RFC3463, 450 reply codes, and 4.7.1 extended codes.
Unfortunately, there's one final line to that description:
This is useful only as a permanent error.
What's the general consensus here? Is 4.7.1 in fact useful as a
temporary error in this case, or do we risk the wrath of the RFC
wonks if stuff deploys that uses that?
In my view, that should say:
This type of extended code only make senses for
permanent errors (i.e., when X is 5).
Why?
Well, first, extended and more importantly "optional" extended response
codes are design to provide a computer coded extended "description" for the
required response code. If supported, the X must match the x in the
required x5y code. What will ultimately be used for controlling the client
is the require 4xx or 5xx codes.
In other words, if you issue
450 4.7.1 You've been greylisted, try again later
550 5.7.1 You've been blackkisted, don't bother to try again
You need to be backward compatible and so that client will base the retry
logic on 450/550. Not 4.7.1/5.7.1. It may not even recognize it.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com