[EMAIL PROTECTED] writes:
I sent this transcript off to one of the SMTP developers, and he sent me this excerpt from the RFC (emphasis his):
4. The AUTH command AUTH mechanism [initial-response] Arguments: a string identifying a SASL authentication mechanism. an _optional_ base64-encoded response
So the Motorola SMTP client is treating the AUTH initial-response as optional, and not sending it as part of the AUTH PLAIN command. Instead, the client is waiting for a '334' response from the server, after which it will send the actual authentication credentials.
Direct this SMTP developer's attention to chapter 6 of RFC 2595, which defines the SASL PLAIN mechanism:
6. PLAIN SASL mechanism
[ â ]
The mechanism consists of a single message from the client to the server. The client sends the authorization identity (identity to login as), followed by a US-ASCII NUL character, followed by the authentication identity (identity whose password will be used), followed by a US-ASCII NUL character, followed by the clear-text password.
The â[initial response]â parameter to the âAUTHâ command is only optional in the sense that not all SASL mechanisms require it. He's looking at the generic SASL documentation, but he should also be looking at the SASL PLAIN documentation specifically.
SASL CRAM-MD5, for example, does not use the â[initial response]â parameter to the AUTH command, because that SASL mechanism begins with a server-initiated challenge. The SASL PLAIN mechanism consists of a single message from the client to the server. There's nothing else in the definition of a SASL PLAIN that specifies the initial server response. If your SMTP developer believes that AUTH PLAIN without the initial client message is valid, please have him identify for me which documentation specifies what the initial server message should be, in that case.
pgpICTU1tXJmv.pgp
Description: PGP signature
