RE: RFC3463, 450 reply codes, and 4.7.1 extended codes.

The author never anticipated a situation where a sender may be not authorized 
at one time but could be authorized at another.  At the most basic level, that 
seems like the definition of an unreliable system. 

Fortunately, imagination does not limit reality.  And UBE certianly challenges 
the reality of the email architecture.  I have no problem supporting an RFC 
errata note indicating that this seamingly incorrect prognistication be 
eliminated.   

In more broad terms, I like opinions as to whether these predictions of utility 
have any value, or whether they should be deleted from a future revision.

Greg V.

-----Original Message-----
From: Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu 
[mailto:Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu]
Sent: Monday, May 09, 2005 9:58 AM
To: ietf-smtp(_at_)imc(_dot_)org
Subject: RFC3463, 450 reply codes, and 4.7.1 extended codes.


It was suggested to me that an SMTP server implementing greylisting
needs to return a descriptive code, and some variant on

450 4.7.1 You've been greylisted, try again later

is the "best fit" from RFC3463, which says:

      X.7.1   Delivery not authorized, message refused

         The sender is not authorized to send to the destination.  This
         can be the result of per-host or per-recipient filtering.  This
         memo does not discuss the merits of any such filtering, but
         provides a mechanism to report such.

Yep.  Stick a 4 on it to tell the other end that it's not authorized *now*,
but might be later, and we're ready to rock.  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?