[Date Prev][Date Next] [Chronological] [Thread] [Top]

Slow Email Devliery, Was: ldaprc with ldaps:// and ldap:// fallback

Apologies for the list clutter, but I couldn't find a more appropriate
place to send this.

I originally sent this question to mailman@www.openldap.org, which is
listed on:


as the contact for list problems, but that address was rejected with:

<mailman@www.openldap.org>: host www.openldap.org[] said: 550
5.1.2 <mailman@www.openldap.org>... Rejected; bad system address (in reply
to RCPT TO command)

My original question was:

I've noticed that my emails to the openldap-technical list are delayed.
Typically the email is delayed from 30 minutes to an hour or two.

However, this email I sent yesterday was delayed for 16 hours. In all
cases, the delay appears to happen internally within boole.openldap.org.

Could this be due to a reputation issue with my relay server
(pinky.olp.net)? Or is this just moderation delay?

Here's a header snippet from the email in question:

Received: from psmtp.com (exprod5mx267.postini.com []) by
neo.olp.net (Postfix) with ESMTP id 8E23420EDC1 for <dwhite@olp.net>; Fri,
25 Jun 2010 08:56:28 -0500 (CDT)

Received: from source ([]) (using TLSv1) by
exprod5mx267.postini.com ([]) with SMTP; Fri, 25 Jun 2010
09:56:28 EDT

Received: from boole.openldap.org (mailman@localhost [IPv6:::1]) by
boole.openldap.org (8.14.3/8.14.3) with ESMTP id o5PDj7QP064017 for
<dwhite@olp.net>; Fri, 25 Jun 2010 13:56:20 GMT (envelope-from

Received: from pinky.olp.net (postfix@pinky.olp.net []) by
boole.openldap.org (8.14.3/8.14.3) with ESMTP id o5OLriEj067106 for
<openldap-technical@openldap.org>; Thu, 24 Jun 2010 21:54:08 GMT
(envelope-from dwhite@olp.net)

Received: from quark.olp.net (vpn.olp.net []) by
pinky.olp.net (Postfix) with ESMTP id 378C0292E8E; Thu, 24 Jun 2010
16:53:42 -0500 (CDT)

Received: by quark.olp.net (Postfix, from userid 1000) id 1EFE6E7E002; Thu,
24 Jun 2010 16:53:40 -0500 (CDT)

On 24/06/10 16:53 -0500, Dan White wrote:
On 24/06/10 22:13 +0200, Emmanuel Dreyfus wrote:
Dan White <dwhite@olp.net> wrote:

You could do SASL EXTERNAL over both, with ldapi:/// using Unix peercred,


That sounds nice, but will it works with the "TLS_REQCERT demand" I have
for ldaps:// ?



In this case, EXTERNAL should only be offered after successful TLS
negotiation, or over a unix domain socket.

If TLS negotiation fails, then a SASL bind won't work without selecting
another mechanism.

Dan White

Dan White