BJ wrote:

linux is different than Windows.
sure is :-)
It is looking in the host file for your localhost server, not DNS.
When I configure the nameserver explicitly in James, lookup of remote hosts succeeds but lookup of configured servernames fails - but these are also available via dns, so shouldn't this work identically for remote/local host lookup?

I just took a quick look at the code to see why/how it does the lookup, and found that the code producing the error uses InetAddress.getAllByName - shouldn't it be using org.apache.james.dnsserver.DNSServer.getAllByName which is used elsewhere successfully? isn't this effectively ignoring the configured dns server? is this a bug?

Incidentally, a comment in the same code answered my question #2 - it claims to use the resolved addresses to support delivery to <u...@address-literal> as required by the RFC. But I've never seen literal addresses used in practice, so I feel somewhat more comfortable using the workaround for now.
do a ifconfig to see if you have any DNs Server Assigned.
I don't see anything in ifconfig related to DNS - what should I be looking for?
if you have a firewall make sure that DNS can be received by the server.
you can also do a
netstat -an
and see if your sever is connection to port 53
As a dns client, nslookup works fine, as does the remote delivery in James when I manually configure the nameserver - so I don't think this is a firewall problem.

Or do u mean James does in fact try to act as a dns *server*?


Thanks for your help!

A. Rothman sent the following on 6/29/2009 4:41 AM:
Hi,


I'm migrating JAMES (2.3.1) from Windows to Ubuntu Jaunty, installed as
a daemon following the guidelines in the james wiki, and seem to have
some DNS problems. If started from the command line, everyting runs
fine. But when started by a reboot, the dnsserver* log show that no dns
server was auto-detected, as well as java.net.PortUnreachableExceptions
when trying to send a message, and the james* log shows the error:
"ERROR James: Cannot get IP address(es) for domain.name". I tried to
workaround this by explicitly specifying the dns server in the
configuration, and now sending messages works ok (no exception), but the
latter error remains. So -


1. What reasons might it have to fail at dns  autodiscovery only during
boot time?

2. Is the error "Cannot get IP address(es) for domain.name" really an
error? What implications might this have? Since with the explicitly
configured dns server, both sending and receiving messages seem to be ok
even with the error shown...

3. Is the dns component really a dns server (as the log name implies)?
or a dns client? Should I configure the firewall for a dns server?


Any help would be much appreciated :-)


Amichai





---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


Reply via email to