Applied to my tree as 7de104bf663c041fca8e6d1dc16dd6d97bfa6848
http://github.com/rspier/qpsmtpd/commit/7de104bf663c041fca8e6d1dc16dd6d97bfa6848
(Charlie, this didn't apply normally, so I had to do it by hand.)
-R
Charlie Brady wrote:
On Sun, 29 Nov 2009, Rick wrote:
Trying to get
On 30-11-2009 1:25, Rick wrote:
Maybe you should pull your head out of your butt and listen to what I'm saying.
I doubt if any one is willing to when you are stating it like this...
In conflicts or disagreement it is better to try and de-escalate than to
throw oil at the flames, by this you
On Sun, 29 Nov 2009, Rick wrote:
Charlie Brady wrote:
[...]or should use a SASL challenge string in the context of AUTH PLAIN.
RFC4954 was more clear:
The AUTH command initiates a [SASL] authentication exchange between the
client and the server.
[...]
A server challenge is sent as a 334
On Sun, 29 Nov 2009, Ask Bj?rn Hansen wrote:
On Nov 29, 2009, at 16:25, Rick wrote:
Hi Rick!
I'm pretty sure Charlie wasn't just being stubborn but rather just
trying to figure out what the behavior really should be so we don't
change it to work compatibility with alpine just to break it
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
On Sun, 29 Nov 2009, Rick wrote:
Also I noticed that Auth.pm does not respond to a client * command during
AUTH PLAIN. * is supposed to cancel the AUTH exchange regardless of the
mechanism. Here's what I get:
AUTH PLAIN
334
*
504 Invalid authentificat
*
500 Unrecognized command
According
On Sun, 29 Nov 2009, Rick wrote:
Also I noticed that Auth.pm does not respond to a client * command
during AUTH PLAIN. * is supposed to cancel the AUTH exchange regardless
of the mechanism. Here's what I get:
AUTH PLAIN
334
*
504 Invalid authentificat
*
500 Unrecognized command
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
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
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
Charlie Brady wrote:
[...]or should use a SASL challenge string in the context of AUTH PLAIN.
RFC4954 was more clear:
The AUTH command initiates a [SASL] authentication exchange between the
client and the server.
[...]
A server challenge is sent as a 334 reply with the text part containing
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
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
On Nov 29, 2009, at 16:25, Rick wrote:
Hi Rick!
I'm pretty sure Charlie wasn't just being stubborn but rather just trying to
figure out what the behavior really should be so we don't change it to work
compatibility with alpine just to break it with something else.
It's entirely possible that
14 matches
Mail list logo
