>>>>> "ph10" == Philip Hazel <ph10@???> writes:
>> We're setting up some Proofpoint demo boxes and using SMTP VRFY
>> callouts to our exim (4.20) relays to verify recipients. It
>> appears that when the LDAP server returns a DEFER, that the entire
>> LDAP error (including search string, bind dn and passwd) are passed
>> back to the Proofpoint box and nothing is logged by exim.
ph10> 4.20 is an old release - dated May 2003. I suggest you upgrade
ph10> to the latest release (4.60), especially as this change was made
ph10> for 4.50:
ph10> 75. A backgrounded daemon closed stdin/stdout/stderr on entry;
ph10> this meant that those file descriptors could be used for SMTP
ph10> connections. If anything wrote to stderr (the example that came
ph10> up was "warn" in embedded Perl), it could be sent to the SMTP
ph10> client, causing chaos. The daemon now opens stdin, stdout, and
ph10> stderr to /dev/null when it puts itself into the background.
ph10> This might not be what is happening in your case, of course. If
ph10> you still have the same issue with 4.60, repost the problem.
And indeed we do.
The Proofpoint boxes make multiple connections to our Exim relays, and
hold them open making lots of VRFY calls. Since we verify a lot of
our user addresses via LDAP, we were running into a 2 minute timeout
set on the LDAP server. It seems that Exim would keep the LDAP
connection open but wouldn't notice or otherwise attempt to restablish
the connection after the timeout, and so would start deferring. When
that happened, the sending MTA (Proofpoint) would still get the entire
LDAP query and error. Also, nothing was being logged by Exim, so only
the sending MTA knew there was an error.
The errors received by the sending MTA were either "ldap search
initialization failed" or "ldap_result failed: 81, Can't contact the
LDAP server".
Before we stumbled onto the LDAP timeout, we tried the VRFYs against
our 4.60 test box and had the same problems.
