[Top] [All Lists]

Re: RSET command - possible security loophole

2011-06-01 14:54:13

--On Wednesday, June 01, 2011 12:09 -0400 Peter Bowen
<pzbowen(_at_)gmail(_dot_)com> wrote:

But this would be allowed, correct?

No, it is not.  See below.

(Assuming no previous AUTH was sent)

C: MAIL FROM:<whoever@wherever>
S: 250 Go ahead, you unauthenticated thing you
C: RCPT TO:<highmucketymuck@wherever>
S: 559 Authorization failure, need to authenticate to send to
    this address 
S: 250 State reset
C: AUTH blah blah blah
S: 250 OK, you're authorized now
C: RCPT TO:<highmucketymuck@wherever>
S: 250 OK, you're allowed to do that now

Once the RSET is issued, I would think the state it is not
"during a mail transaction".

That is correct: unless some extension changes it, mail
transactions start with a MAIL command.  Since RSET resets any
mail transaction that happens to be in progress, the sequence
above ought to produce a "command out of order" response to the
second RCPT command.   As far as the server is concerned, no
MAIL command has been issued (because RSET cleared the previous
one), so the second RCPT command, which requires a mail session,
has been issued without one.

Deciding what 5321 commands and state RSET resets is not
discretionary with either the client or the server.  Either one
would cause a nightmare.

Again, I believe that 5321 is quite clear on this.  If someone
believes otherwise, please identify the text that leads you to
believe that RCPT following after RSET with no intervening MAIL
command is valid so we can try to get it fixed.