Subject: RSET scope issue

From: Chris Newman <[email-masked]>
Date: Mon, 14 Aug 2000 16:16:07 -0700

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.

		- Chris Newman
		[Not speaking as chair]

---

From: "Lee Thompson" <[email-masked]>
Date: Mon, 14 Aug 2000 16:32:59 -0700

>   immediately before a QUIT. In other situations, it restores the state to

Agreed.

-- 
Lee Thompson                       [email-masked]
Seattle Lab Inc.           http://www.seattlelab.com
Software Engineer                      ICQ: 19545760

---

From: Russ Allbery <[email-masked]>
Date: 14 Aug 2000 16:42:49 -0700

Chris Newman <[email-masked]> 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:

>   that immediately after the most recent EHLO.  An SMTP server MUST NOT close

> "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 ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Gregory Neil Shapiro <[email-masked]>
Date: Mon, 14 Aug 2000 17:16:34 -0700 (PDT)

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

cnewman> I propose that the sentence marked above be deleted.

I agree.

---

From: Philip Hazel <[email-masked]>
Date: Tue, 15 Aug 2000 09:03:10 +0100 (BST)

I support this change.

The first sentence in effect makes the point about resetting the 
transaction rather than the connection, but this could be made clearer. 
(The wording of the first sentence is also a bit odd - a command doesn't 
usually "specify", and the use of the future tense reads oddly.) Here is 
a minor revision:

   This command causes the current mail transaction to be aborted. It 
   resets the state to what it was at the beginning of the transaction. 
   The state of the connection itself is not affected. Any stored sender 
   .... etc.

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

---

From: John Beck <[email-masked]>
Date: Tue, 15 Aug 2000 06:46:42 -0700

+> 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).

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

Chris> I propose that the sentence marked above be deleted.

Philip> I support this change.

As do I, though we've already reached quota on this one.

Philip> The first sentence in effect makes the point about resetting the
Philip> transaction rather than the connection, but this could be made
Philip> clearer.  (The wording of the first sentence is also a bit odd - a
Philip> command doesn't usually "specify", and the use of the future tense
Philip> reads oddly.)  Here is a minor revision:

Philip> This command causes the current mail transaction to be aborted. It
Philip> resets the state to what it was at the beginning of the transaction.
Philip> The state of the connection itself is not affected. Any stored sender
Philip> .... etc.

I support this clarification too.

-- John

---

From: Russ Allbery <[email-masked]>
Date: 15 Aug 2000 12:56:26 -0700

>    The state of the connection itself is not affected. Any stored sender 

I support this change as well.

---

From: Chris Newman <[email-masked]>
Date: Tue, 15 Aug 2000 18:32:26 -0700

>    The state of the connection itself is not affected. Any stored sender

I object to this proposed change.

Take command sequence:

MAIL FROM:<[email-masked]>
MAIL FROM:<[email-masked]>
RSET

Unless we explicitly add language to the SMTP spec which states that a 
"MAIL FROM" MUST return a 503 error when a transaction is in progress, then 
the second sentence in the proposed text is factually incorrect (or at best 
in a gray area).  Given what 821 says about "MAIL FROM" doing an implied 
reset and the fact 503 is not listed as a valid response to "MAIL" in 821, 
I can't see a justification for such a drastic reversal.

Because a mail transaction is arguably part of the connection state, the 
third sentence could be seen as contradictory to the first sentence.

Given how hard it is to get wording right in this area and how late we are, 
I'd prefer to just delete the offending sentence and be done with it.

		- Chris (speaking for myself only)

---

From: [email-masked] (Kai Henningsen)
Date: 17 Aug 2000 19:42:00 +0200

> "MAIL FROM" MUST return a 503 error when a transaction is in progress, then

4.1.1.2 ... In general, the MAIL command may be sent only when no mail  
transaction is in progress ...

4.1.4 makes this a MUST NOT, and says that a 501 MUST be returned and the  
server MUST stay in the same state. (503 is for commands that don't start  
a transaction.)

> the second sentence in the proposed text is factually incorrect (or at best

... so it actually *is* factually correct.

> I can't see a justification for such a drastic reversal.

Incidentally, 821 has almost exactly the same text ("must ... 501 ... same  
state", page 27).

> I'd prefer to just delete the offending sentence and be done with it.

Does the above take care of your objection?

MfG Kai