On 02/28/2011 05:22 PM, Timothy Pearson wrote:

...

...

Tim,

I went to register for the bugzilla and found that the confirmation request from 74.84.118.181 was rejected by postfix because 74.84.118.181 does not provide a proper reverse lookup causing:

<snip> >> It is 'reject_unknown_client' causing the rejection. From: >> http://www.postfix.org/postconf.5.html the rejection is caused when: >> <snip> > Hi David, > > How exactly did you get this error? My reverse DNS checks out OK and I > don't see any problems with a test registration on the Bugzilla. > > Thanks! > > Tim

Tim, my postfix setup is:

[17:35 nirvana:/home/david/Documents/law/clients-rlf] # postconf -n alias_database = $alias_maps alias_maps = hash:/etc/postfix/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix data_directory = /var/lib/postfix debug_peer_level = 2 html_directory = no inet_interfaces = all mail_owner = postfix mail_spool_directory = /var/spool/mail mailbox_command = /usr/bin/procmail -a "$EXTENSION" mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 10240000 mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain myhostname = nirvana.3111skyline.com mynetworks_style = subnet myorigin = $mydomain newaliases_path = /usr/bin/newaliases proxy_interfaces = 66.76.63.120 queue_directory = /var/spool/postfix readme_directory = no relay_domains = rlfpllc.com, rbpllc.com, rankinfirm.com, rankinlawfirm.com, drrankin.com sample_directory = /etc/postfix/sample sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtpd_client_restrictions = reject_rbl_client zen.spamhaus.org

<** I had to remove reject_unknown_client from the line above **>

smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, reject_non_fqdn_hostname smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination unknown_local_recipient_reject_code = 550

Before removing 'reject_unknown_client' from smtpd_client_restrictions, the confirmation email was rejected with (note I've removed the @ signs below and replaced them with ' at '):

Feb 28 16:22:22 nirvana postfix/smtpd[6858]: 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@pearsoncomputing.net to=<trin at 3111skyline.com> proto=ESMTP helo=<vali.starlink.edu> Feb 28 16:22:22 nirvana postfix/smtpd[6858]: disconnect from unknown[74.84.118.181]

After removing 'reject_unknown_client' the confirmation came through no problem:

Feb 28 16:32:05 nirvana postfix/smtpd[6966]: warning: 74.84.118.181: address not listed for hostname pearsoncomputing.net Feb 28 16:32:05 nirvana postfix/smtpd[6966]: connect from unknown[74.84.118.181] Feb 28 16:32:05 nirvana postfix/smtpd[6966]: 8E24D5FBCD: client=unknown[74.84.118.181] Feb 28 16:32:05 nirvana postfix/cleanup[6968]: 8E24D5FBCD: message-id=201102282222.p1SMMIkD004700@thor.starlink.edu Feb 28 16:32:05 nirvana postfix/smtpd[6966]: disconnect from unknown[74.84.118.181] Feb 28 16:32:05 nirvana postfix/qmgr[6945]: 8E24D5FBCD: from=bugs@pearsoncomputing.net, size=2878, nrcpt=1 (queue active) Feb 28 16:32:05 nirvana postfix/local[6971]: 8E24D5FBCD: to=<me at 3111skyline.com>, orig_to=<trin at 3111skyline.com>, relay=local, delay=0.4, delays=0.31/0.01/0/0.07, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -a "$EXTENSION") Feb 28 16:32:05 nirvana postfix/qmgr[6945]: 8E24D5FBCD: removed

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

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@pearsoncomputing.net to=testtrindns@3111skyline.com 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@thor.starlink.edu Feb 28 23:07:06 nirvana postfix/qmgr[8672]: B59EE5FBCD: from=bugs@pearsoncomputing.net, 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@3111skyline.com, 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

<snip>

I may be misunderstanding what you mean by fixing the routing, but when postfix checks to 'reject_unknown_client'

<snip>

I think I was unclear on that point. I mean the actual kernel level network routing--essentially, when my servers attempt to send a data packet they can do so via two pipes if you will, one for each of my public IP addresses. Before QuickBuild went down earlier all traffic was sent out the .180 pipe. Now, due to the network card change, all traffic is being sent through the .181 pipe, which does not correspond to any of my DNS entries and is apparently tripping up certain spam filters.

Changing all the DNS entries would be a somewhat irritating undertaking, so I prefer to take this opportunity to better control the external IP routing. :)

Tim

On 03/02/2011 11:15 AM, Timothy Pearson wrote:

...

<snip> > I may be misunderstanding what you mean by fixing the routing, but > when > postfix checks to 'reject_unknown_client' <snip>

OK, routing has been repaired, would you mind checking one more time?

Thanks!

Tim

---

To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

Works like a champ now:

Mar 2 18:43:51 nirvana postfix/master[1903]: reload -- version 2.8.1, configuration /etc/postfix Mar 2 18:44:25 nirvana postfix/smtpd[5101]: connect from pearsoncomputing.net[74.84.118.180] Mar 2 18:44:25 nirvana postfix/smtpd[5101]: 967625FBDA: client=pearsoncomputing.net[74.84.118.180] Mar 2 18:44:25 nirvana postfix/cleanup[5105]: 967625FBDA: message-id=201103030044.p230iNPs024029@thor.starlink.edu Mar 2 18:44:25 nirvana postfix/qmgr[5098]: 967625FBDA: from=bugs@pearsoncomputing.net, size=2944, nrcpt=1 (queue active) Mar 2 18:44:25 nirvana postfix/smtpd[5101]: disconnect from pearsoncomputing.net[74.84.118.180] Mar 2 18:44:25 nirvana postfix/local[5106]: 967625FBDA: to=<me at 3111skyline.com>, orig_to=testtrindns3@3111skyline.com, relay=local, delay=0.21, delays=0.16/0.01/0/0.04, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -a "$EXTENSION") Mar 2 18:44:25 nirvana postfix/qmgr[5098]: 967625FBDA: removed

I had to do it twice, I forgot to reset 'reject_unknown_client' and restart postfix the first time :)