Re: RSET command - possible security loophole

Its says once authorized, you can't issue it again:

Old 2554:

  Restrictions:
    After an AUTH command has successfully completed, no more AUTH
    commands may be issued in the same session.  After a successful
    AUTH command completes, a server MUST reject any further AUTH
    commands with a 503 reply.

    The AUTH command is not permitted during a mail transaction.

Updated to:

  Restrictions:
    After an AUTH command has been successfully completed, no more
    AUTH commands may be issued in the same session.  After a
    successful AUTH command completes, a server MUST reject any
    further AUTH commands with a 503 reply.

    The AUTH command is not permitted during a mail transaction.
    An AUTH command issued during a mail transaction MUST be
    rejected with a 503 reply.

I think we are debating two things: the relationship between the 
authenticated identity and that of the SENDER (MAIL FROM) of the 
message, and how this applications to subsequent same session 
transactions that have completed an initial transaction.
Personally, we need to look at it as what multiple transactions help 
resolve as oppose to doing it separately.  In the latter, each (AUTH) 
can be different, but if thats the case, than these individual 
messages should not be viewed as under the same group.
Practically, targets have properties of smart hosting, port, tls and 
authentication requirements.
So to me, this is just am implementation queuing consolidation 
heuristic design issue.

John C Klensin wrote:
> Yes, exactly.
>
> And the "only one AUTH per session" condition (which you
> describe as "nly allowed before the first MAIL in the
> session"... well, while 4954 could have imposed that condition,
> I don't think it does (and, IMO, it would have been be really
> bad design if it had)
>
>     john
>
>
> --On Wednesday, June 01, 2011 17:24 -0400 Peter Bowen
> <pzbowen(_at_)gmail(_dot_)com> wrote:
>
> > On Wed, Jun 1, 2011 at 15:39, John C Klensin
> > <john+smtp(_at_)jck(_dot_)com> wrote:
> > > 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
> > > > C: RSET
> > > > 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.
> > You are of course correct.  What I intended did not make it
> > into the example.  Corrected:
> >
> > 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 C: RSET
> > S: 250 State reset
> > C: AUTH blah blah blah
> > S: 250 OK, you're authorized now
> > C: MAIL FROM:<whoever@wherever>
> > S: 250 Go ahead, I know who you are
> > C: RCPT TO:<highmucketymuck@wherever>
> > S: 250 OK, you're allowed to do that now
> >
> > My point is that sending a RSET sets the state back to "not
> > during mail transaction", hence you can AUTH after RSET.  The
> > other alternative is that AUTH is only allowed before the
> > first MAIL in the session.
> >
> > Thanks,
> > Peter
--
Sincerely

Hector Santos
http://www.santronics.com