Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id OAA09589; Wed, 31 May 1995 14:13:41 -0400 X-Resent-To: drums@CS.UTK.EDU ; Wed, 31 May 1995 14:13:40 EDT Errors-to: owner-drums@CS.UTK.EDU Received: from wilma.cs.utk.edu by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id OAA09582; Wed, 31 May 1995 14:13:39 -0400 Received: by wilma.cs.utk.edu (cf v2.11c-UTK) id OAA11913; Wed, 31 May 1995 14:13:33 -0400 Date: Wed, 31 May 1995 14:13:33 -0400 Message-Id: <199505311813.OAA11913@wilma.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: perry@imsi.com cc: John Gardiner Myers , drums@CS.UTK.EDU, moore@CS.UTK.EDU Subject: Re: RFC 821 problem list In-reply-to: Your message of "Wed, 31 May 1995 13:03:49 EDT." <9505311703.AA19737@snark.imsi.com> > > The 522 reply code identifies a *transient* condition--the error is > > likely to go away if the RCPT command is retried in a separate > > transaction. The condition should instead be assigned a 4XX reply > > code. > > That would break current systems, wouldn't it? I don't think so. 522 wouldn't be re-used, we would just assign a 4xx code to take its place in new implementations. I assume that no SMTP clients *depend* on 522 being issued under any particular conditions. Any SMTP client which treats 522 as a special-case transient error will presumably work just fine if they get a 4xx code instead, and any client that treats 522 as a permanent error will work better if it sees 4xx.