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.
