Charlie, I'm beginning to wonder if you actually understand the RFCs.
Don't just pick apart the excerpts I am posting. Go and read the full
RFC4954 and my quotes in context. Is there a reason you are being so
stubborn? Does your motivation lay anywhere along the lines of
improving the qpsmtpd server, or is it merely to engage in retarded
Internet quibbling?
Let me break it down:
1) RFC4954 obsoletes 2554. This information was vague in 2554. It is
clear in 4954.
2) a 334 response is to contain the BASE64 encoded string supplied by
the SASL mechanism and MUST NOT contain any text other than the BASE64
encoded challenge.
3) "Please continue" is what qpsmtpd returns. "Please continue" is not
from the SASL mechanism. It is also not BASE64 encoded. This is a
bug! It needs to be fixed.
4) If the initial response argument to the AUTH command is omitted (as
is the case with the command "AUTH PLAIN" vs "AUTH PLAIN [argument]"),
you can't just return whatever text response strikes your fancy. You
must return the appropriate challenge as defined in the SASL
documentation. For AUTH PLAIN, this happens to be nothing.
5) When you want to send an empty response, RFC4954 spells out to the
letter that it needs to be "334 " including that cute little trailing space.
6) Maybe my interpretation is wrong. Let's observe the behavior of some
other clients and servers, or look at some examples posted around the
web or in the RFCs. Whoops, they match what I just said. Maybe you
should pull your head out of your butt and listen to what I'm saying.
There might be something to it. And even in this fantasy world where
your interpretation on everything is the only right and just one, at
least one other client and other servers don't seem to agree with you.
Maybe even if you were right and all this documentation were totally
ambiguous, we should go ahead and go with the flow just to be compatible
and make qpsmtpd a better piece of software that is usable by all those
mundanes who don't live in your fantasy world.
7) The RFCs also clearly state that all AUTH exchanges, without being
limited to only certain mechanism, need to respond to a client command
of "*" by canceling the AUTH exchange and issuing a 501. qpsmtpd
doesn't do this for AUTH PLAIN! ANOTHER BUG! I'm only trying to help.
Why are you being so stubborn? Read RFC4954.
8) You mentioned previously that you couldn't find any documentation to
support alpine's behavior of canceling the authentication in this
circumstance. You used the word "disconnect" but that's not what I said
not was it what I meant. Well I found the documentation for you. Not
surprisingly, it's right there in that document you never read that
supersedes RFC2554--RFC4954: If the client cannot BASE64 decode any of
the server's challenges, it MUST cancel the authentication using the "*"
response. Well that's why alpine issues a * in response to "Please
continue." But before you go right back to arguing that I'm a douche
and we can just BASE64 encode "Please continue," alpine ALSO spits out a
warning that the server is issuing a non zero length initial challenge
to AUTH PLAIN which is incorrect. And as I've repeatedly claimed and
defended, alpine is right! qpsmtpd should return "334 ". nothing more
and nothing less. The RFCs say so, alpine says so, examples agree with
me, postfix does it this way, and damnit *I* just say so. I'm a
nobody. I'm not even a qpsmtpd contributor. You can choose to ignore
me if you want, but I have spent the last two days reading and rereading
RFCs, researching this issue, debugging the problem, and trying to
figure out for myself if the problem is a buggy old command-line email
client that I don't even use or if it's something in the
not-even-version-1-yet smtp server software that I've been running
mostly without issues for years.
Well it's out there, archived on the list, and I'm done defending
myself. When somebody else has issues with SMTP AUTH in the future,
hopefully they will come across this discourse and be able to understand
the 10-second fix I've explained. Or better yet, perhaps a more
open-minded committer will read this tonight and patch the git
respository so these obvious bugs I pointed out won't have to be
revisited again in the future.
I've got mine patched already. Charlie, you must be the life of the
party when somebody cracks a joke and you try to argue the semantics of
the punchline.
Peace,
-Rick
Charlie Brady wrote:
On Sun, 29 Nov 2009, Rick wrote:
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.*"
The statement above says absolutely nothing about what happens when
the initial-response argument is not used. It explicitly only applies
to when the argument is used.
Examples also show this:
C: AUTH PLAIN
S: 334
C: AHdlbGRvbgB3M2xkMG4=
The example only shows that it is possible to have an empty argument.
It does not state that the argument must not be used.
----------------------------------
And in RFC4954:
"In SMTP, a server challenge that contains no data is defined as a
334 reply with no text part.
That doesn't say anything about a 334 reply which does have a text part.
