ietf-smtp
[Top] [All Lists]

Re: RSET command - possible security loophole

2011-05-31 15:13:56

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

<Prev in Thread] Current Thread [Next in Thread>