Re: RSET command - possible security loophole

Keith Moore 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.
> 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.
Good points.

In regards to authentication, in our code, for IP based (Relay Tables, 
POPB4SMTP), it can not change the authentication based on IP.  For 
ESMTP AUTH, once the session authenticated, per RFC2554, section 4, it 
will not allow another AUTH to be issued with a 503 response.
While I wasn't particular going in that direction with an 
authentication RSET relationship between two or more transactions, it 
was interesting to note how the interpretation of the text provided 
could mean different things.
I guess one question might be where/when does a Mail Transaction begin 
and start.     That seems to be:
   MAIL FROM:  - Start of Mail Transaction
   DATA EOD    - End of Mail Transaction

RSET, in general, clears everything about the "transaction" (MAIL, 
RCPT, DATA) at least our server does and taking a quick look at Exim 
and Sendmail code, pretty much the same thing, and since there is a 
specific order EHLO, MAIL, RCPT and DATA,  EHLO and MAIL can start a 
new transaction as well.
My post was about remembering a transaction "security" data point that 
had occurred in a previous failed transaction (most likely as a system 
wide policy generated at DATA before EOD) and its possible 
applicability in subsequent (same session) transactions.  RFC5321 made 
an effort to clarity policy related reply codes like 450, 550:
   DATA
     I: 354 -> data -> S: 250
                       E: 552, 554, 451, 452
                       E: 450, 550 (rejections for policy reasons)
     E: 503, 554

as oppose to 2821:

   DATA
      I: 354 -> data -> S: 250
                        E: 552, 554, 451, 452
      E: 451, 554, 503

So that is my only focus here.

--
Sincerely

Hector Santos
http://www.santronics.com