# Postfix Problem - SOLVED

## crkpipe

I am setting up a postfix relay for our   :Evil or Very Mad:  Exchange  :Evil or Very Mad:   server so SpamAssasin can work with it.  Before I moved onto dealing with spamassassin I wanted to make sure postfix works inbound and outbound.  

I can send test messages on the inside network without much problem.  When I try to send it out to the Internet, I get the following Errors:

Mar 14 11:26:11 filter postfix/smtp[6499]: connect to hrndva-02.mgw.rr.com[24.28.204.28]: server refused to talk to me: 554-hrndva-mx-09.mgw.rr.com  554 #5.5.4 Relaying denied. IP name lookup failed for x.x.x.x   (port 25)

Mar 14 11:26:12 filter postfix/smtp[6499]: connect to hrndva-02.mgw.rr.com[24.28.204.27]: server refused to talk to me: 554-hrndva-mx-08.mgw.rr.com  554 #5.5.4 Relaying denied. IP name lookup failed for x.x.x.x   (port 25)

Mar 14 11:26:12 filter postfix/smtp[6499]: connect to orngca-01.mgw.rr.com[66.75.160.139]: server refused to talk to me: 554-orngca-mx-05.mgw.rr.com  554 #5.5.4 Relaying denied. IP name lookup failed for x.x.x.x   (port 25)

Now I have configured the MX record to point to this server, I have the reverse lookup PTR record working as well.  I cannot figure out why the error of an IP look up failed or why the server is refusing to "talk to me". From the outside world I can resolve forward and reverse the external Address by name and IP that is NAT'd to this inside relay server.  The problem appears to be DNS related, but I cannot pinpoint exactly where.

Any suggestions or ideas to put me in the right direction would be greatly Appreciated.

Thanks.  :Very Happy: Last edited by crkpipe on Thu Mar 16, 2006 9:56 pm; edited 1 time in total

----------

## magic919

If your PTR is to the exact canonical name of your MTA then this makes no sense.  But then RR have changed from ignoring PTR to using it in the past I understand.

Did you do this DNS change recently?  Could still be propagating.

----------

## darkphader

main.cf should contain

```
smtp_helo_name = <the name that a reverse lookup on your ip address provides>
```

 if it is any different than $myhostname.

Chris

----------

## crkpipe

Thanks for the suggestions.

I have tried what you have mentioned and the results are bizaar.  I am still revieving the same messages concerning that my IP cannot be looked up.  I added the smtp_helo_name = parameter but that did not help the situation any.

Mar 16 10:46:56 filter postfix/smtp[10498]: connect to hrndva-01.mgw.rr.com[24.28.204.26]: server refused to talk to me: 554-hrndva-mx-07.mgw.rr.com  554 #5.5.4 Relaying denied. IP name lookup failed for 199.26.150.17   (port 25)

Mar 16 10:46:56 filter postfix/smtp[10499]: connect to clmboh-02.mgw.rr.com[65.24.7.62]: server refused to talk to me: 554-clmboh-mx-08.mgw.rr.com  554 #5.5.4 Relaying denied. IP name lookup failed for 199.26.150.17   (port 25)

Mar 16 10:46:56 filter postfix/smtp[10498]: connect to clmboh-01.mgw.rr.com[65.24.7.19]: server refused to talk to me: 554-clmboh-mx-05.mgw.rr.com  554 #5.5.4 Relaying denied. IP name lookup failed for 199.26.150.17   (port 25)

Mar 16 10:46:56 filter postfix/smtp[10499]: connect to orngca-01.mgw.rr.com[66.75.160.129]: server refused to talk to me: 554-orngca-mx-02.mgw.rr.com  554 #5.5.4 Relaying denied. IP name lookup failed for 199.26.150.17   (port 25)

The IP address in bold as you can see you can forward and reverse lookup . . . so I am still not figuring out why the IP name lookup is failing.  Could it be an inside DNS problem?  It appears from the logs as if the mx server for xxx.rr.com is bouncing back with the error, as if it cannot resolve the DNS.  Anyway, once again any Suggestions would be greatly welcomed!

Thanks for your help in Advance.

----------

## darkphader

So you are then using: 

```
smtp_helo_name = filter.eschoolsolutions.com
```

 Which would be needed if the variable $myhostname does not expand to that.

However, this is really strange...the first system I used to test the IP name lookup returns no answer! Yet, three other systems do.

On my desktop here, where I run a separate caching resolver I get no answer: 

```
$ dig -x 199.26.150.17

; <<>> DiG 9.3.2 <<>> -x 199.26.150.17

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7852

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;17.150.26.199.in-addr.arpa.    IN      PTR

;; Query time: 4 msec

```

 Yet other reverse lookups work just fine and the address lookup works fine as well. On some servers that I maintain remotely both the forward and reverse lookups work fine. And it's not an issue of not getting to a particular root server because I have another system on my personal network that does get an answer to the reverse lookup.

Whoahhh...another oddity: as a test I restarted the name service on my local system that did resolve the reverse lookup and now it no longer does! And on my desktop here I can resolve 199.26.150.15 and 199.26.150.16, but not 199.26.150.17, yet now on the system with the restarted name service I can resolve none of these. There's something strange going on. 

OK, now I'm getting lost answers from another (a remote) system. I think there is definitely some kind of DNS problem.

Chris

----------

## crkpipe

That is correct.  The helo value is filter.eschoolsolutions.com

I see you are seeing the same bizaar problems I am.  I too can resolve the address forward and backwards.  What I am wondering if is perhaps the DNS has not propogated properly for whatever reason and the server is bouncing it as a relay because like you are experiencing, it cannot resolve the reverse lookup.  

I am baffeled, as from my DNS servers all is pointing and resolving correctly.  If it is an issue with DNS propogation, I would be curious about how to get to the root of that problem.

As always, thanks for any help, ideas, suggestions in advance.

----------

## crkpipe

darkphader et al,

Thanks for your help.  After reading your post and thinking about the results you were revieving . .  I figured out what was going wrong.  It was definately DNS like you said.  what was happening was,  our DNS server replication was not working so the slave server did not have updated entries from the master for quite some time, and when we updated the entry for "filter" it was never propogated to the slave.  When doing the lookup, the query went to our 2ndary DNS server which did not have the correct record, which was why the IP LOOKUP was failing b/c for some reason it was only being directed to the incorrect server.  When I updated the records the mail went right on through.

Thanks to all who got me looking in the right direction.

 :Very Happy: 

----------

