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