[Top] [All Lists]

RE: RSET command - possible security loophole

2011-05-31 17:08:02

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