Re: RSET scope issue

[John Beck <[e-mail]>]

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