-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of John C
Klensin
Sent: Tuesday, May 31, 2011 12:44 PM
To: Keith Moore
Cc: Hector Santos; ietf-smtp(_at_)imc(_dot_)org
Subject: Re: RSET command - possible security loophole
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.
Given that the model of SMTP in general involves some connection-specific stuff
(accept(), 220, EHLO, 250) followed by zero or more message-specific actions
(MAIL, RCPT, DATA, RSET) and some things that have to do with neither (RSET,
NOOP, HELP, VRFY, EXPN), I'm at a loss to understand how there's some blending
of semantics here.
Are there properties of the session state, other than implementation-specific
ones, that might ever be altered by commands after EHLO? I can't think of any.
Past EHLO, everything is either neutral or is a message-specific instruction
of some kind. If that's the case, then declaring that RSET only ever resets
message state seems like where the RFC should leave it.
-MSK