RE: RSET scope issue

"Woodhouse, Gregory J." <gregory.woodhouse@med.va.gov> Tue, 15 August 2000 02:13 UTC

Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22919 for <drums-archive@odin.ietf.org>; Mon, 14 Aug 2000 22:13:26 -0400 (EDT)
Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA15026; Mon, 14 Aug 2000 22:13:08 -0400 (EDT)
Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 14 Aug 2000 22:13:06 -0400
Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA15010; Mon, 14 Aug 2000 22:13:05 -0400 (EDT)
Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Mon, 14 Aug 2000 22:13:05 -0400
Received: (from moore@localhost) by astro.cs.utk.edu (cf 8.9.3) id WAA26116 for dist-drums@cs.utk.edu; Mon, 14 Aug 2000 22:13:05 -0400 (EDT)
Received: from cambridge1-smrly3.gtei.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id UAA08479; Mon, 14 Aug 2000 20:11:37 -0400 (EDT)
Received: from cambridge1-smrly3.gtei.net (199.94.215.250 -> cambridge1-smrly3.gtei.net) by cs.utk.edu (smtpshim v1.0); Mon, 14 Aug 2000 20:11:37 -0400
Received: from deptvass2-cp.va.gov (deptvass2-cp.va.gov [205.128.215.121]) by cambridge1-smrly3.gtei.net (Postfix) with SMTP id B2B283991 for <drums@cs.utk.edu>; Tue, 15 Aug 2000 00:11:36 +0000 (GMT)
Received: from 152.129.1.70 by vhaishmul4 (InterScan E-Mail VirusWall NT); Mon, 14 Aug 2000 19:17:36 -0500 (Central Daylight Time)
Received: by VHAISHHBEXC4 with Internet Mail Service (5.5.2650.21) id <3ZK0W7LR>; Mon, 14 Aug 2000 19:15:19 -0500
Message-ID: <03F40A4BFEFAD111B55E0000F81E4FB1603874@VHAISFEXC1>
From: "Woodhouse, Gregory J." <gregory.woodhouse@med.va.gov>
To: Detailed Revision/Update of Message Standards <drums@cs.utk.edu>
Subject: RE: RSET scope issue
Date: Mon, 14 Aug 2000 19:06:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
List-Unsubscribe: <mailto:drums-request@cs.utk.edu?Subject=unsubscribe>

It basically makes sense to me. It seems that what is happening here is an
unstated assumption that transactions will never be nested, so an RSET
always goes back to the top level (immediately after EHLO). This ought to
either be made explicit or some language like "the current transaction must
be reset to its initial state" should be used instead. I'm not sure if just
deleting the phrase is the right approach because it seems to rely on
knowledge of an unstated assumption.

===
Gregory Woodhouse <gregory.woodhouse@med.va.gov>
Financial Product Line
+1 415 744 6362
"Computer science is no more about computers than astronomy is
about telescopes." -- E.W. Dijkstra


-----Original Message-----
From: Russ Allbery [mailto:rra@stanford.edu]
Sent: Monday, August 14, 2000 4:43 PM
To: Detailed Revision/Update of Message Standards
Subject: Re: RSET scope issue


Chris Newman <cnewman@innosoft.com> writes:

> There is a bug in the definition of the RSET command in section 4.1.1.5
> of draft 12.  The current text follows:

>   4.1.1.5 RESET (RSET)

>   This command specifies that the current mail transaction will be
aborted.
>   Any stored sender, recipients, and mail data MUST be discarded, and all
>   buffers and state tables cleared.  The receiver MUST send a "250 OK"
reply
>   to a RSET command with no arguments.  A reset command may be issued by
the
>   client at any time.  It is effectively equivalent to a NOOP (i.e., if
has
>   no effect) if issued immediately after EHLO, before EHLO is issued in
the
>   session, after an end-of-data indicator has been sent and acknowledged,
or
>   immediately before a QUIT. In other situations, it restores the state to
>                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   that immediately after the most recent EHLO.  An SMTP server MUST NOT
close
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   the connection as the result of receiving a RSET; that action is
reserved
>   for QUIT (see section 4.1.1.10).

> The sentence I have marked is incorrect in the presence of the "AUTH" or
> "STARTTLS" extensions and is generally contradictory with the definition
> of "RSET", namely to reset the _transaction state_ rather than the
> _connection state_.

> I propose that the sentence marked above be deleted.

I support this change.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>