--On October 28, 2011 2:36:54 PM -0700 Quanah Gibson-Mount
wrote:
--On October 28, 2011 4:14:02 PM + Viktor Dukhovni
wrote:
FREE_RESULT)); +rc = ldap_parse_result(ld, res, &err, 0, 0, 0, 0,
This should be dict_ldap->ld rather than just "ld". ;)
Working on testing this now.
--On October 28, 2011 4:14:02 PM + Viktor Dukhovni
wrote:
FREE_RESULT)); +rc = ldap_parse_result(ld, res, &err, 0, 0, 0, 0,
This should be dict_ldap->ld rather than just "ld". ;)
Working on testing this now.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, In
On Fri, Oct 28, 2011 at 02:27:32AM +, Viktor Dukhovni wrote:
> A better solution is required, I'll post an updated proposal
> tomorrow.
Please try the below. It inlines the two-line (possibly deprecated)
ldap_result2error() function, which just calls ldap_parse_result().
I don't believe we ac
On Fri, Oct 28, 2011 at 08:30:48AM -0700, Quanah Gibson-Mount wrote:
> Reading the code in libraries/libldap/sasl.c, specifically the
> function ldap_sasl_bind_s. This is from OpenLDAP 2.1.30. Note that
> ldap_result2error is still called after ldap_parse_sasl_bind_result.
Use of a function int
--On October 28, 2011 3:55:54 AM + Viktor Dukhovni
wrote:
On Thu, Oct 27, 2011 at 07:22:05PM -0700, Quanah Gibson-Mount wrote:
The issue I fixed today would affect any postfix build with an
OpenLDAP API at least as far back as OpenLDAP 2.1. What postfix
revisions you fix are entirely
On Thu, Oct 27, 2011 at 07:22:05PM -0700, Quanah Gibson-Mount wrote:
> The issue I fixed today would affect any postfix build with an
> OpenLDAP API at least as far back as OpenLDAP 2.1. What postfix
> revisions you fix are entirely up to you of course, and I think
> reasonably I wouldn't expect
--On October 28, 2011 2:27:32 AM + Viktor Dukhovni
wrote:
A better solution is required, I'll post an updated proposal
tomorrow.
Sounds good!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
Zimbra :: the leader in open source messaging a
On Thu, Oct 27, 2011 at 04:25:07PM -0700, Quanah Gibson-Mount wrote:
> >Therefore, I propose the following Postfix fix/work-around which
> >is required for anyone running Postfix 2.3 or later, linked with
> >OpenLDAP 2.4 or later (perhaps even late 2.3.x releases, I just
> >compared OpenLDAP 2.3.4
--On October 28, 2011 2:18:22 AM + Viktor Dukhovni
wrote:
On Thu, Oct 27, 2011 at 05:55:21PM -0700, Quanah Gibson-Mount wrote:
The original response from Viktor had:
Naturally also post the Postfix table definition, which will indicate
whether you're using simple or SASL binds. If po
On Thu, Oct 27, 2011 at 05:55:21PM -0700, Quanah Gibson-Mount wrote:
> The original response from Viktor had:
>
> Naturally also post the Postfix table definition, which will indicate
> whether you're using simple or SASL binds. If possible try both,
> and report any difference in behaviour, sinc
--On October 27, 2011 8:45:34 PM -0400 Wietse Venema
wrote:
Your post read like hey look what I found the same bug is in
older releases. If my explanation is viewed as hostile, then
don't read my replies. I will in return not read your posts.
The original response from Viktor had:
Natura
Quanah Gibson-Mount:
>
>
> --On October 27, 2011 8:14:51 PM -0400 Wietse Venema
> wrote:
>
> > We don't create Postfix from scratch with each release; instead we
> > use an evolutionary approach. This results in similarities between
> > releases.
>
> Of course. I was simply pointing out that
--On October 27, 2011 8:14:51 PM -0400 Wietse Venema
wrote:
We don't create Postfix from scratch with each release; instead we
use an evolutionary approach. This results in similarities between
releases.
Of course. I was simply pointing out that if you are going to fix this
bug, it need
Quanah Gibson-Mount:
>
>
> --On October 27, 2011 4:25:07 PM -0700 Quanah Gibson-Mount
> wrote:
>
> > +#define FREE_RESULT 0
> > +if ((rc = ldap_parse_sasl_bind_result(dict_ldap->ld, res, 0,
> > FREE_RESULT)) != LDAP_SUCCESS)
> > + return (rc);
> > +
> > +return(ldap_result2error(
--On October 27, 2011 4:25:07 PM -0700 Quanah Gibson-Mount
wrote:
+#define FREE_RESULT 0
+if ((rc = ldap_parse_sasl_bind_result(dict_ldap->ld, res, 0,
FREE_RESULT)) != LDAP_SUCCESS)
+ return (rc);
+
+return(ldap_result2error( dict_ldap->ld, res, 1 ));
Two notes:
The requir
--On October 27, 2011 4:14:12 AM + Viktor Dukhovni
wrote:
Therefore, I propose the following Postfix fix/work-around which
is required for anyone running Postfix 2.3 or later, linked with
OpenLDAP 2.4 or later (perhaps even late 2.3.x releases, I just
compared OpenLDAP 2.3.4 with 2.4.23
--On October 27, 2011 4:14:12 AM + Viktor Dukhovni
wrote:
Therefore, I propose the following Postfix fix/work-around which
is required for anyone running Postfix 2.3 or later, linked with
OpenLDAP 2.4 or later (perhaps even late 2.3.x releases, I just
compared OpenLDAP 2.3.4 with 2.4.23
On Wed, Oct 26, 2011 at 05:10:41PM -0700, Quanah Gibson-Mount wrote:
> >I'm using simple binds as I have since postfix 2.3. I actually was not
> >aware the code for using SASL mechanism binds had been added to postfix.
> >Very happy to know that. ;) I have my own test server set up now so I
> >c
--On October 26, 2011 4:45:01 PM -0700 Quanah Gibson-Mount
wrote:
I'm using simple binds as I have since postfix 2.3. I actually was not
aware the code for using SASL mechanism binds had been added to postfix.
Very happy to know that. ;) I have my own test server set up now so I
can bette
--On October 26, 2011 6:08:56 AM + Viktor Dukhovni
wrote:
On Tue, Oct 25, 2011 at 10:14:39PM -0700, Quanah Gibson-Mount wrote:
Ok, logs were still on the server I was using earlier. Here's part
of one of the connections in question.
LDAP server logs are no way to report a suspected
On Tue, Oct 25, 2011 at 10:14:39PM -0700, Quanah Gibson-Mount wrote:
> Ok, logs were still on the server I was using earlier. Here's part
> of one of the connections in question.
LDAP server logs are no way to report a suspected Postfix issue to
this list. They are for LDAP administrators, not P
--On October 25, 2011 9:47:43 PM -0700 Quanah Gibson-Mount
wrote:
I noticed this the other day when debugging a self-inflicted issue with
postfix and LDAP. If postfix is configured to bind as user X, and user X
doesn't exist in LDAP, LDAP will return error code 49 (invalid
credentials). T
I noticed this the other day when debugging a self-inflicted issue with
postfix and LDAP. If postfix is configured to bind as user X, and user X
doesn't exist in LDAP, LDAP will return error code 49 (invalid
credentials). This is of course the correct behavior on the LDAP side of
things. How
23 matches
Mail list logo