RFC 2554 first defines "A server challenge, otherwise known as a ready
response, is a 334 reply with the text part containing a BASE64 encoded
string."
That the initial ready response should be empty is a little more
discreetly implied:
"When the initial-response argument is used with such a mechanism, the
*initial empty challenge* is not sent to the client and the server[...]
as if it were sent in response to the *empty challenge.*"
Examples also show this:
C: AUTH PLAIN
S: 334
C: AHdlbGRvbgB3M2xkMG4=
S: 235 2.0.0 OK Authenticated
----------------------------------
bash$ telnet example.com 25
...
auth plain
334
dXNlcm5hbWUAdXNlcm5hbWUAcGFzc3dvcmQA
235 authentication successful
----------------------------------
And in RFC4954:
"In SMTP, a server challenge that contains no data is defined as a 334 reply with no text
part. Note that there is still a space following the reply code, so the complete response line is
"334 "."
Charlie Brady wrote:
On Sun, 29 Nov 2009, Rick wrote:
Trying to get SMTP auth working with alpine, I came across a bug.
Alpine sends AUTH PLAIN and waits for a 334 response, then sends the
auth string. According to the RFC, the server should reply with 334
and a nothing else, but in Auth.pm qpsmtpd responds with "334 Please
continue." the "Please continue" is interpreted as a non-zero
length initial challenge which causes alpine (and maybe other
clients?) to abort the session.
Perhaps that's a bug in alpine. I can't see anything in RFC 2554 which
suggests that the client should disconnect in this circumstance, or
should use a SASL challenge string in the context of AUTH PLAIN.
Definition of 'continue_req' allows a BASE64 string following 334 space.
Admittedly, 'Please continue' is not a base64 string. What does alpine
do if it sees "334 Continue"?
Nothing I can see relevant in RFC 4616 either.
The simple fix is to change this part in Auth.pm:
if ( $mechanism eq "plain" ) {
if (!$prekey) {
$session->respond( 334, "Please continue" );
$prekey= <STDIN>;
}
To this:
if ( $mechanism eq "plain" ) {
if (!$prekey) {
$session->respond( 334, " " );
$prekey= <STDIN>;
}
There's a space in there, otherwise qpsmtpd won't send any response
which is equally as bad.
I suggest somebody commit this small change to the source tree.
-Rick
