--On Tuesday, May 31, 2011 11:19 -0400 Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:
My impression is that the behavior of RSET has never been
defined with respect to authentication, and that the Right
Thing for RSET to do with respect to authentication is
absolutely nothing.
A separate question is whether RSET affects anything in an
SMTP extension. It's easy to say that RSET doesn't affect
extensions, but I doubt that's the right tack. RSET should
definitely affect CHUNKING, for instance. But I think RSET
should only affect the current message being sent.
Keith,
I think you are right, but that your formulation above is
backwards. As I read 5321, the semantics of RSET are completely
clear and actually quite precise: It clears the mail transaction
state and all the data that go with it; it does not clear the
session state. It is also clear that an extension could modify
those semantics or even add arguments to RSET. Possibly not a
good idea, but very clearly possible in terms of how 5321 (and
its predecessors) define the extension model.
The place where "backwards" comes in is the place where I think
Hector has uncovered a problem, even though it is not the
problem his initial note was about. I think that, as we are
checking extensions that set data that needs to be carried from
one command to others, we should be checking to be sure that
action is either explicitly bound to either session or
transaction state or that new states are clearly defined. Such
a clear definition would properly include a statement about what
RSET (and EHLO and completion of the DATA command) does to the
state and/or data. That is a requirement on the relevant
extension specification. We may not have been clear enough
about that requirement to be diligent and consistent about
insisting on it -- in retrospect, it might even have been useful
to put something about state or data retention in the template.
But, at least modulo the possibility of tuning the template, it
isn't a 5321 problem because 5321 does exactly what it should do
-- defines the behavior in the absence of extensions and
specifies that extensions can change that behavior. As far as
the existing extensions are concerned, the problem is much more
likely "incomplete spec" than, e.g., "error in protocol".
With respect to authentication, it's arguable that there
should be some way to "logout" without ending the current TCP
session. But that would have to be a separate SMTP extension.
Right. Or part of a particular authentication extension.
john