On Tue, Feb 10, 2009 at 9:58 PM, Wietse Venema <wie...@porcupine.org> wrote: > jan gestre: >> On Tue, Feb 10, 2009 at 7:44 PM, Wietse Venema <wie...@porcupine.org> wrote: >> > David Cottle: >> > [ Charset ISO-8859-1 unsupported, converting... ] >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> Hash: SHA1 >> >> >> >> All, >> >> >> >> I see this a lot in my mail.log (unknown): >> >> >> >> Feb 10 20:38:28 server postfix/smtpd[21977]: connect from >> >> unknown[72.4.168.106] >> >> Feb 10 09:38:30 server postfix/smtpd[21977]: NOQUEUE: reject: RCPT >> >> from unknown[72.4.168.106]: 554 5.7.1 Service unavailable; Client host >> > >> > Try: http://www.postfix.org/DEBUG_README.html#no_chroot. If it >> > works, send a complaint to your vendor. I, the Postfix author, do >> > not recommend that chroot is turned on except by experts. >> > >> > Wietse >> > >> > Try turning off chroot operation in master.cf >> > ============================================= >> > >> > A common mistake is to turn on chroot operation in the master.cf >> > file without going through all the necessary steps to set up a >> > chroot environment. This causes Postfix daemon processes to fail >> > due to all kinds of missing files. >> > >> > The example below shows an SMTP server that is configured with >> > chroot turned off: >> > >> > /etc/postfix/master.cf: >> > # ============================================================= >> > # service type private unpriv chroot wakeup maxproc command >> > # (yes) (yes) (yes) (never) (100) >> > # ============================================================= >> > smtp inet n - n - - smtpd >> > >> > Inspect master.cf for any processes that have chroot operation not >> > turned off. If you find any, save a copy of the master.cf file, >> > and edit the entries in question. After executing the command >> > "postfix reload", see if the problem has gone away. >> > >> > If turning off chrooted operation made the problem go away, then >> > congratulations. Leaving Postfix running in this way is adequate >> > for most sites. If you prefer chrooted operation, see the Postfix >> > BASIC_CONFIGURATION_README file for information about how to prepare >> > Postfix for chrooted operation. >> > >> >> I have this same problem that I was not able to solve for almost a >> week now. I posted too on various mailing lists including this (mail >> from gmail and yahoo are blocked), some suggested to install a caching >> nameserver but obviously in your case it doesn't work too. Replaced >> OpenDNS with other DNS server to no avail, still the same result. If >> rbl is enabled all incoming emails were blocked so I have no recourse >> but to turn it off, caveat is I've got lots of SPAM. Also I don't have >> Postfix in chroot environment. >> >> Here's my log: >> >> Feb 10 21:34:46 kartero postfix/smtpd[14176]: NOQUEUE: reject: RCPT >> from wf-out-1314.google.com[209.85.200.172]: 554 5.7.1 Service >> unavailable; Client host [209.85.200.172] blocked using >> bl.spamcop.net; from=<ipcopper...@gmail.com> >> to=<jan.ges...@ddb.com.ph> proto=ESMTP helo=<wf-out-1314.google.com> > > This thread is about CLIENT names logged as UNKNOWN, > > You are having a problem with a DNS server that produces bogus replies > for non-existent hostnames. You can twiddle with Postfix configurations > until the cows come home. It will not make an iota of difference. > > Wietse >
I apologize for that, I thought it's the same.
