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:
http://www.openldap.org/mailman/listinfo
as the contact for list problems, but that address was rejected with:
mailman@www.openldap.org: host www.openldap.org[204.152.186.57] 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 [64.18.0.90]) 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 ([204.152.186.50]) (using TLSv1) by exprod5mx267.postini.com ([64.18.4.10]) 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 openldap-technical-bounces+dwhite=olp.net@openldap.org)
Received: from pinky.olp.net (postfix@pinky.olp.net [67.217.151.200]) 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 [67.217.151.100]) 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, i.e.:
authz-regexp ".*uidNumber=([^,]+),cn=peercred,cn=external,cn=auth" ldap:///ou=People,dc=example,dc=net??one?(uidNumber=$1)
That sounds nice, but will it works with the "TLS_REQCERT demand" I have for ldaps:// ?
Try:
TLS_REQCERT: try
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