On Sat, 6 Oct 2001, Mike Richardson wrote:
> Now the RFC 2595 says that the AUTH PLAIN "mechanism consists of a single
> message from the client to the server" but shows:
>
> C: a003 AUTHENTICATE "PLAIN" (21+)
> C: <null>tim<null>something
> S: a003 OK
So it does. Though it's {21+} not (21+). The actual lines are
C: a003 AUTHENTICATE "PLAIN" {21+}
C: <NUL>tim<NUL>tanstaaftanstaaf
My guess is that the {21+} means "21 data characters follow". Otherwise,
if the input comes on multiple lines like this, the server won't know
when it ends.
But of course, *that isn't SMTP*.
I don't believe this is relevant to SMTP, which is a lock-step protocol.
After the client has sent an AUTH command, it must wait for a response.
You can't send additional data just like that. That's the way SMTP works
for *all* commands. Therefore, I and other implementors of PLAIN have
taken the "obvious" interpretation for SMTP, which is that the data
follows immediately on the same line as "AUTH PLAIN".
The RFC to read is 2554 "SMTP Service Extension for Authentication", but
unfortunately, it doesn't show a PLAIN example. What it does say is
this:
The optional initial-response argument to the AUTH command is
used to save a round trip when using authentication mechanisms
that are defined to send no data in the initial challenge.
When the initial-response argument is used with such a
mechanism, the initial empty challenge is not sent to the
client and the server uses the data in the initial-response
argument as if it were sent in response to the empty challenge.
after having defined the syntax of AUTH as
AUTH mechanism [initial-response]
I rest my case.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
