Barney Desmond wrote: > 2009/5/26 Per olof Ljungmark <p...@bsdlabs.com>: >> May 26 08:13:41 terrapin postfix/smtpd[79633]: NOQUEUE: reject: RCPT >> from sender.server[1.2.3.4]: 550 5.1.1 <recipi...@domain.com>: Recipient >> address rejected: User unknown in relay recipient table; >> from=<sen...@domain.com> to=<recipi...@domain.com> proto=ESMTP >> helo=<sender.server> >> >> May 26 08:23:06 terrapin postfix/smtpd[79805]: NOQUEUE: reject: RCPT >> from sender.server[5.6.7.8]: 550 5.1.1 <recipi...@domain.com>: Recipient >> address rejected: User unknown in relay recipient table; >> from=<sen...@domain.com> to=<recipi...@domain.com> proto=ESMTP >> helo=<sender.server> > > Per, > > There appears to be some confusion here, as it's unclear exactly how > the LDAP server is being queried. The 550 rejection in the quoted > lines above are a recipient rejection. For "local" mail that's > typically a query to the OS, which is the getpwnam() function others > have been referring to. Postfix asks the system whether the user > exists, and the system responds. Postfix doesn't know whether that > information is coming from /etc/passwd, or NIS, or LDAP, etc. > > Perhaps you are using LDAP tables in Postfix directly, in which case > the getpwnam() function isn't involved. That's fine too. > > The issue here is what happens when something fails. > > When postfix asks the system about a user account, some systems will > report a "user doesn't exist", when the real problem is that the > database (LDAP) was down. The OS may not support the idea of a > "temporary failure, please try again". Postfix can't do anything about > this. If the system says the account doesn't exist, it has to trust > it. > > When postfix is using a database table, things are different. Unless > I'm very mistaken, Postfix absolutely *will not* report a 550 > hard-failure if the backend is "down". It will report a 450 soft-fail, > because 550 would be wrong. 550 means "that user does not exist", > which would be a lie if it can't connect to the LDAP server. > > We need evidence that the right problem is being diagnosed, so please > provide the output of `postconf -n`. You can hide confidential domains > with "example.com", but it has to be consistent. The more information > you hide the harder it is for others to diagnose. > >> Can one change the bounce code/message temporarily on-the-fly? postconf -b? > > If you can detect that the LDAP server is down and you want to take > action independently, you might consider changing > "unknown_local_recipient_reject_code" to 450, then change it back when > the LDAP server comes back. You can use `postconf -e` to do this. I'm > pretty sure that's the right setting. > >> May 26 12:53:59 thewheel slapd[52495]: conn=134006 fd=51 ACCEPT from >> IP=172.16.1.12:60033 (IP=0.0.0.0:389) >> May 26 12:53:59 thewheel slapd[52495]: conn=134006 op=0 BIND dn="" method=128 >> May 26 12:53:59 thewheel slapd[52495]: conn=134006 op=0 RESULT tag=97 err=0 >> text= >> May 26 12:53:59 thewheel slapd[52495]: conn=134006 op=1 SRCH >> base="o=inter-sonic.com" scope=2 deref=0 >> filter="(&(accountStatus=active)(|(mail=kryd...@starlight.se)(mailalternateaddress=kryd...@starlight.se)))" >> May 26 12:53:59 thewheel slapd[52495]: conn=134006 op=1 SRCH attr=mail >> mailalternateaddress >> May 26 12:53:59 thewheel slapd[52495]: conn=134006 op=1 SEARCH RESULT >> tag=101 err=0 nentries=1 text= > > Okay, that's the LDAP server showing it's getting queried. I try to > avoid LDAP as much as possible, but I suspect someone on the list will > ask for postfix-logs also showing that it's *directly* querying the > LDAP server (this looks like pretty good evidence to me though). I'm > not sure if this will require more verbose logging.
Thank you very much for this informative answer! After reading, I looked back at the incident we had a while ago (that spurred my initial post) when communication with the LDAP servers had a problem. What I found does shed some light over my confusion , it appears we are dealing with two cases 1) the LDAP servers where unreachable and 2) they returned empty answers. In case 1) postfix in fact returned a 4xx error and in 2) of course a 5xx because the answer was empty. Sorry for the noise here but I had missed this until I read the your post and went back to look at the logs. For completness, here is an excerpt from just now with verbose logging in Postfix and I think it shows it uses the LDAP directly as a database. May 26 16:56:04 terrapin postfix/smtpd[91767]: dict_ldap_lookup: In dict_ldap_lookup May 26 16:56:04 terrapin postfix/smtpd[91767]: dict_ldap_lookup: Using existing connection for LDAP source /usr/local/etc/postfix/ldap-lookup.cf May 26 16:56:04 terrapin postfix/smtpd[91767]: dict_ldap_lookup: /usr/local/etc/postfix/ldap-lookup.cf: Searching with filter (&(accountStatus=Active)(|(mail=mag...@starlight.se)(mailalternateaddress=mag...@starlight.se))) May 26 16:56:04 terrapin postfix/smtpd[91767]: dict_ldap_get_values[1]: Search found 0 match(es) May 26 16:56:04 terrapin postfix/smtpd[91767]: dict_ldap_lookup: Using existing connection for LDAP source /usr/local/etc/postfix/ldap-lookup.cf May 26 16:56:04 terrapin postfix/smtpd[91767]: dict_ldap_lookup: /usr/local/etc/postfix/ldap-lookup.cf: Searching with filter (&(accountStatus=Active)(|(ma...@starlight.se)(mailalternateaddre...@starlight.se))) May 26 16:56:04 terrapin postfix/smtpd[91767]: dict_ldap_get_values[1]: Search found 0 match(es) May 26 16:56:04 terrapin postfix/smtpd[91767]: dict_ldap_get_values[1]: Leaving dict_ldap_get_values May 26 16:56:04 terrapin postfix/smtpd[91767]: dict_ldap_lookup: Search returned nothing And finally, if I'm allowed to continue on the original subject, from what I gather "postconf" can be used to change varios aspects of the configuration. We already have a script that monitors the smptd and ldap servers and it could easily be adopted to use postconf to temporarily change the configuration if I understand the above and the manual correctly. One last thing I could not find in the manual, maybe I'm blind as usual, but does postconf -b|-c|-e require a postfix reload? Thank you everyone for your patience! -- per
