> On 02/28/2011 10:07 PM, Timothy Pearson wrote: > <snip> >>> I wish I could tell you the reason why postfix was rejecting the >>> messages with >>> 'reject_unknown_client' set as a smtpd_client_restrictions entry, but >>> alas, my >>> postfix knowledge doesn't extend that far... But, I can confirm the >>> behavior and >>> let you know what caused the rejection. >>> >>> I can see the lookup for pearsoncomputing.net just fine as well: >>> >>> [17:48 nirvana:/home/david/Documents/law/clients-rlf] # nslookup >>> 74.84.118.181 >>> Server: 192.168.6.17 >>> Address: 192.168.6.17#53 >>> >>> Non-authoritative answer: >>> 181.118.84.74.in-addr.arpa name = pearsoncomputing.net. >>> >>> Authoritative answers can be found from: >>> 118.84.74.in-addr.arpa nameserver = ns2.mcomdc.com. >>> 118.84.74.in-addr.arpa nameserver = ns1.mcomdc.com. >>> >>> However, I think postfix doesn't like the fact that there is no >>> "hostname.pearsoncomputing.net', provided, just a domainname. Fox >>> example, >>> when >>> I do a lookup on my office server, I get: >>> >>> [17:48 nirvana:/home/david/Documents/law/clients-rlf] # nslookup >>> 66.76.63.60 >>> Server: 192.168.6.17 >>> Address: 192.168.6.17#53 >>> >>> Non-authoritative answer: >>> 60.63.76.66.in-addr.arpa name = mail.rbpllc.com. >>> >>> Authoritative answers can be found from: >>> 63.76.66.in-addr.arpa nameserver = ns2.suddenlink.net. >>> 63.76.66.in-addr.arpa nameserver = ns1.suddenlink.net. >>> ns2.suddenlink.net internet address = 66.76.2.133 >>> >>> Notice the "name =" difference. I have a hostname, you just have your >>> domain. >>> Like I said, I'm no postfix expert, but I think that (or something >>> along >>> those >>> lines) is what is happening. >>> >>> >>> >> >> Do you mind checking to see if the problem is still occurring? Other >> people have mentioned that there were some DNS issues a few days ago >> which >> have since been resolved; I would like to know if this issues was >> resolved >> along with them. >> >> Thanks! >> >> Tim >> > > Glad to test - but it is still no good: > > Feb 28 22:58:05 nirvana postfix/smtpd[8659]: warning: 74.84.118.181: > address not > listed for hostname pearsoncomputing.net > Feb 28 22:58:05 nirvana postfix/smtpd[8659]: connect from > unknown[74.84.118.181] > Feb 28 22:58:05 nirvana postfix/smtpd[8659]: NOQUEUE: reject: RCPT from > unknown[74.84.118.181]: 450 4.7.1 Client host rejected: cannot find your > hostname, [74.84.118.181]; from=<bugs@...> > to=<testtrindns@...> proto=ESMTP helo=<vali.starlink.edu> > Feb 28 22:58:05 nirvana postfix/smtpd[8659]: disconnect from > unknown[74.84.118.181] > > 16:52 archangel:~/arch/tpkg> nslookup 74.84.118.181 > Server: 192.168.6.14 > Address: 192.168.6.14#53 > > Non-authoritative answer: > 181.118.84.74.in-addr.arpa name = pearsoncomputing.net. > > Authoritative answers can be found from: > 118.84.74.in-addr.arpa nameserver = ns1.mcomdc.com. > 118.84.74.in-addr.arpa nameserver = ns2.mcomdc.com. > > 23:00 archangel:~/arch/tpkg> dig -x 74.84.118.181 > > ; <<>> DiG 9.7.2-P3 <<>> -x 74.84.118.181 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44549 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;181.118.84.74.in-addr.arpa. IN PTR > > ;; ANSWER SECTION: > 181.118.84.74.in-addr.arpa. 10770 IN PTR pearsoncomputing.net. > > ;; AUTHORITY SECTION: > 118.84.74.in-addr.arpa. 10770 IN NS ns1.mcomdc.com. > 118.84.74.in-addr.arpa. 10770 IN NS ns2.mcomdc.com. > > ;; Query time: 0 msec > ;; SERVER: 192.168.6.14#53(192.168.6.14) > ;; WHEN: Mon Feb 28 23:00:53 2011 > ;; MSG SIZE rcvd: 124 > > Mine: > > 23:00 archangel:~/arch/tpkg> dig -x 66.76.63.60 > <snip> > ;; ANSWER SECTION: > 60.63.76.66.in-addr.arpa. 21600 IN PTR mail.rbpllc.com. > > Will your domain name registrar give you the option of handling your own > pointer > records? If so, with multiple hosts behind a single IP, I have had good > luck > with the following setup: > > rlfpllc.com A 66.76.63.60 > ftp.rlfpllc.com A 66.76.63.60 > mail.rlfpllc.com A 66.76.63.60 > www.rlfpllc.com A 66.76.63.60 > rlfpllc.com MX rlfpllc.com - priority: 10 > rlfpllc.com MX 3111skyline.com - priority: 20 > phoenix.rlfpllc.com A 66.76.63.60 > providence.rlfpllc.com CNAME rlfpllc.com > > Phoenix is the primary box, (providence, etc.. ) are other internal hosts > that > are cname hosts to the primary that allow host.domain.com access on > alternate > ports. 3111skyline is just my backup mail host. Having the > 'hostname'.domain.com > specified at your domain registrar dns level allows reverse lookups to > resolve > to a host not just a domain. I think that might be the key with the > rejections > here. I used to have notes on all this, but it was years ago when I sorted > all > this out. (I've just been using the same setup for ? a decade now) > > Let me know when you need another test. I'm happy to do it. After dropping > the > reject_unknown_client restriction again and reloading postfix, the > original > confirmation comes right through: > > Feb 28 23:07:06 nirvana postfix/smtpd[8701]: warning: 74.84.118.181: > address not > listed for hostname pearsoncomputing.net > Feb 28 23:07:06 nirvana postfix/smtpd[8701]: connect from > unknown[74.84.118.181] > Feb 28 23:07:06 nirvana postfix/smtpd[8701]: B59EE5FBCD: > client=unknown[74.84.118.181] > Feb 28 23:07:06 nirvana postfix/cleanup[8705]: B59EE5FBCD: > message-id=<201103010458.p214w2tk008579@...> > Feb 28 23:07:06 nirvana postfix/qmgr[8672]: B59EE5FBCD: > from=<bugs@...>, size=2927, nrcpt=1 (queue active) > Feb 28 23:07:06 nirvana postfix/smtpd[8701]: disconnect from > unknown[74.84.118.181] > Feb 28 23:07:06 nirvana postfix/local[8706]: B59EE5FBCD: to=<me at > 3111skyline.com>, orig_to=<testtrindns@...>, relay=local, > delay=0.26, delays=0.18/0.01/0/0.07, dsn=2.0.0, status=sent (delivered to > command: /usr/bin/procmail -a "$EXTENSION") > Feb 28 23:07:06 nirvana postfix/qmgr[8672]: B59EE5FBCD: removed > > OK, thanks for checking. I host my own DNS, but it looks like the problem is not DNS related this time around. Rather it seems that my firewall box has messed up the routing; instead of originating traffic on .180 it has decided to originate traffic on .181, which was reserved for QuickBuild. Fixing it may involve separating the firewall boxes due to the complexity of the routing tables in use. Tim